CTT is usually a recommended tool when the use case is to migrate AEM (On-prem/AMS) to AEM CaaS. But you should evaluate your migration strategy based on your business case as there are cases where CTT may not align with business needs or ways of working and become more complicated than usual. Some key topics to consider and check with clients before you finalize asset migration strategy via CTT are:-
· Run BPA on the source AEM — this will highlight any complications related to migration like node count size, node store size, etc, any content violations, etc.
· Paths to be migrated, their asset count, and repository size. It is recommended to do a dry run on lower env to get a rough estimate on time taken which in turn will help us estimate content freeze time and overall strategy — i.e. all asset migration in one go or split into batches. Please note multiple batches of migration need multiple downtimes on cloud destination env.
· Versions: Do you need asset versions to be migrated? CTT via prod clone doesn’t support this? Also, top-up migration can be a challenge with clone env.
· Other data like taxonomy, project information if in use, audit history any other information from legal & legacy points of view.
· Taxonomy :
If not required, you need a groovy script to remove existing tags on assets before migration (preferably on clone) else assets will get indexed with these tags on the cloud after migration and re-indexing & any manipulation will be heavy operation post-migration.
*If required, with CTT you first will have to plan tags migration ‘/content/cq: tags’ followed by asset migration else assets may not be tagged properly.
· Data Manipulation needs: Is there a need for metadata manipulation or node restructuring/folder renaming or movements as part of migration? Do you need any clean-ups before moving to the new system or in the new system? Evaluate changes and approaches to make those changes and approximate time.
Manipulation on clone: If yes, in most cases you will need a production clone for data manipulation as the client wouldn’t want to disturb or take risks on the existing Production system in use.
Manipulation on destination: Another option is to do metadata manipulation or assets restructuring on destination after final migration, validation & cutover when there is no more delta migration required. Not preferable as metadata manipulation will need reindexing which will be a heavy operation for large asset migrations.
· Top-up migration — Are there multiple iterations of migration expected? Track repository growth in a specific period. I’ve covered Top-up migration in detail in a separate blog here.
This may cause complexity when ‘Prod clone’ is used for migration and data manipulation is needed
Or Migration slowness with ‘wipe=false’ when a top-up is done directly on ‘Production’. Check on the Time gap from first-time migration on production to the final cutover when the old system gets decommissioned.
· Multi-tenant or Single tenant — All markets/teams/brands or sites to be migrated in one go or will the migration be planned in a phased manner with some teams/brands going live first on CaaS and the rest of the teams onboarding slowly? Check Cut over & onboarding plan for all markets & teams. This is critical to be determined as CTT may not work well in this case or introduce complications with top-up migrations.
· System in use — CTT may not be suitable when both source and destination systems are in use parallelly (both live) at the same time until cutover. May Cause complications in delta migration and asset data inconsistencies. Check data on the below aspects and think through the approach
How many new assets will be added in source and destinations during this period?
How many assets and their metadata will be modified during this period on old and new systems? (already migrated assets)
How many assets will be deleted on the source after the first migration is done?
How many assets will be moved on source after the first migration is done?
· Author Downtime on CaaS — Is downtime on AEMaaCS allowed? if allowed how long as CTT in the current state requires downtime on the destination author during ingestion? Note: Downtime is not there on the publish environment.
· User/group/membership/mapping — is it okay to migrate all their users, and groups into the cloud or do you need to clean up? I worked with a client who had an insane amount of user groups created ~75k as they were using AEM Projects actively.
Note: You can remove ‘rep:policy’ node on the prod clone via Groovy script /servlet to disable any default user group migration via CTT that happens even if user mapping is disabled in CTT.
