This is an extension of my learning on CTT. Check this link ‘Key things to consider | CTT ‘ in case planning to use CTT for migration.
Approach 1: AEM query package manager
Use the AEM query package manager from ACS Commons to create a delta content package on source AEM (AMS/On-prem).
Query-based on content updated based on created date and modified date.
Fixed list of paths that client can track when using review approval workflow.
Important considerations :
· The size of each package is limited. Refer to the link here
· The history or versions of the content will be lost
· To install a package into publishing, it must be uploaded to the author and then distributed to publishers.
· User group and permissions to be handled separately unlike CTT.
· These delta packages should be deleted from both repos to avoid unwanted repo increase.
· No downtime on cloud destination in this case
Steps to do: -
When migrating directly from production, create delta content using ACL package manager on the source. Install this package on the production instance.
OR
When using a production clone(in case you have metadata manipulation or folder restructuring requirements), install the package on the clone first, and do metadata updates or restructuring. Rebuild the package using ACL package manager with the same query or list from the clone and install this on the cloud production instance.
Approach2 : Use CTT top-up migration with wipe=”false”
Extraction:
Ingestion :
Important considerations :
This only works if CTT migration happens directly from the Production instance. Does not work for use cases where you will need a prod clone first.
The same migration set needs to be used for the top-up with which the initial migration was done.
Downtime on cloud destination every time delta migration happens.
During extraction → Existing migration set → Edit and Overwrite staging container ->false . Extract again.
During ingestion → use wipe=”false”
Expected outcome :->
· Anything new in the source (folder or asset) but not exiting on target will come over post top-up.
· Any asset updated or deleted in the source will be respected. Updates will come post top-up. Asset deleted in the source will also be deleted in the target.
· Anything deleted in target but present in the source will be respected and remain deleted on target post top-up.
· Any metadata updates on the target instance for the asset will be respected.
· While comments are migrated but related assets did not migrate.
· Collections need to be handled separately.
· Versions and user group permissions can be migrated based on the configurations you choose.
· Custom Renditions — To be checked.
Note: In case of direct ingestion which is not top-up , wipe=”false” will still completely override and replace the path in your destination. Any content changes in the destination path will be lost unless it is a top-up ingestion. So, plan your ingestions carefully. In case you have some content on the destination cloud before running migration, package that content and reinstall it post migration after updating the package filter mode file to ‘merge’ to avoid losing any content.
Note: Ensure that the content structure does not change between migrations/delta. Do not move around the assets or modify the assets on destinations (for asset versions history migration) as it can lead to conflict of uuid and ingestion fail. Refer to the link below to understand this in detail.
