Content transfer from AEM on-prem to 3rd party tool like azure

[ASP_Corp]

Folks, need some suggestions, we are looking to migrate around 500GB of content from on-prem AEM to 3rd party tool preferably azure, the content is about 500GB and we want to preserve all our versions of our assets and documents. what is the best way to approach this?, when we migrate to 3rd party tool or azure, we want the content to be available for atleast 10Yrs.

[Karishma_begumSh · Accepted solution]

Hi @ASP_Corp 

To migrate 500GB of versioned AEM content to Azure for long-term (10+ years) retention, first export the assets, metadata, and all versions using AEM’s JCR APIs or ACS Commons tools. Structure the exported content with metadata and manifest files (e.g., JSON/XML) to maintain traceability and version history. Upload this data to Azure Blob Storage, preferably using the Cool or Archive tiers for cost-effective, long-term storage. Apply immutability policies (WORM) and lifecycle management to ensure data remains unaltered and is automatically transitioned between storage tiers based on access. Tools like AzCopy or Azure SDKs can facilitate efficient uploads. This approach ensures scalable, secure, and compliant archival of AEM content outside the AEM ecosystem.

[AmitVishwakarma]

Hi @ASP_Corp ,

Try below solution:

Step 1: Extract Versioned Content from AEM

You want all versions of assets, not just the latest.

Option A: Use JCR API (Recommended for control and automation)

Write a custom service or Groovy script using JCR APIs:

Session session = resourceResolver.adaptTo(Session.class);
VersionManager vm = session.getWorkspace().getVersionManager();

VersionHistory history = vm.getVersionHistory("/content/dam/myfolder/myasset.jpg");
VersionIterator versions = history.getAllVersions();

while (versions.hasNext()) {
    Version version = versions.nextVersion();
    Node frozen = version.getFrozenNode();
    InputStream assetStream = frozen.getNode("jcr:content/renditions/original/jcr:content").getProperty("jcr:data").getBinary().getStream();
    // Save assetStream as file
}

Save version metadata as version.json alongside the file.

Option B: Use ACS Commons – Asset Backup Tool

It creates packages of assets, versions, and metadata.

http://localhost:4502/etc/acs-commons/packagers/asset-packager.html

Set to include:

  - All renditions

  - All versions

  - XMP/metadata

  - Export ZIPs and extract locally.

Step 2: Structure Your Content for Azure

Organize like:

/exported-assets/
├── asset-001/
│   ├── original-v1.jpg
│   ├── original-v2.jpg
│   └── version.json
├── asset-002/
│   ├── original.jpg
│   └── version.json
└── manifest.json

This ensures traceability and helps future tools understand asset lineage.

Step 3: Upload to Azure Blob Storage

Use AzCopy or Azure Storage Explorer for bulk uploads.

Option A: AzCopy CLI (fastest, scriptable)

azcopy login
azcopy copy "C:\exported-assets" "https://<account>.blob.core.windows.net/<container>?<SAS>" --recursive

Step 4: Enable Long-Term Archival with Azure Features

Choose the right Access Tier

Enable Immutability & Retention Policies (WORM):

az storage container immutability-policy set \
  --account-name <account> \
  --container-name <container> \
  --period 3650 \
  --allow-protected-append-writes false

This ensures data can’t be altered required for 10-year storage compliance.

Regards,
Amit

[ASP_Corp]

hi @AmitVishwakarma , thank you for the reply, I don't see the ACS Commons – Asset Backup Tool  in the acs commons package, can you throw some light on this?, we are in 6.4 (acs-aem-commons) and 1.0.2 in acs-aem-tools. 

thank you.

[kautuk_sahni]

@ASP_Corp Just checking in — were you able to resolve your issue?
We’d love to hear how things worked out. If the suggestions above helped, marking a response as correct can guide others with similar questions. And if you found another solution, feel free to share it — your insights could really benefit the community. Thanks again for being part of the conversation!