How to migrate from another headful CMS to AEM Headless

There isn't any OOTB solution for such a migration. I would treat this as a standard ETL process and follow below steps-

• Prepare data model in AEM
• Create mapping from old data model to the new one.
• Write custom utility to migrate data.
• Transform data either during migration or after migration. I would prefer to transform the data at the destination to make sure the migration performance is not impacted.

I hope it helps. Thanks!

​@JunyTana if this is still unsolved, I would add the below checkpoints to the previous answer:

1. If there is any export API provided by your current CMS, I would try to fully utilize that.
2. Use CFs as your destiny in AEM as you want to use Graph.
3. Make all fields optional during migration so that the process doesn’t break in the middle.
4. Also do things in batches so that we dont overuse the resources.

Once we migrated some stuff from Django to Bloomreach and we used this sort of approach.

Thanks!

Hi ​@JunyTana 

There's no Adobe tool that will "lift‑and‑shift" a third‑party CMS into AEM Headless. The recommended pattern is to treat this as a classic ETL project into Content Fragments, then expose everything via GraphQL.

1. Design the AEM headless model first
   • Use AEM Content Fragment Models to express your future JSON schema (for apps/IoT), not your old page templates.
   • See: https://experienceleague.adobe.com/en/docs/experience-manager-65/content/headless/architect/basics https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/headless/journeys/developer/model-your-content
2. Export from the legacy CMS using its APIs or DB
   • From PostgreSQL/templates, produce a neutral format (JSON or CSV) that already matches or can be mapped to your new Content Fragment Models.
   • If your old CMS has an export API, use that instead of reading tables directly; it usually encodes business rules for you.
3. Map old schema -> Content Fragment Models
   • Create a clear mapping (field‑by‑field) from legacy entities to CF models and fields, including references, tags, and locales.
   • This mapping becomes the contract for your migration scripts and your GraphQL schema.
   • AEM's GraphQL exposes exactly what you define in those models: https://experienceleague.adobe.com/en/docs/experience-manager-65/content/assets/content-fragments/content-fragments-graphql
4. Import as Content Fragments via APIs or scripts
   • Use AEM Assets HTTP APIs or a small migration tool (Java / Node / Groovy) that:
     • Creates Content Fragments in the right folders and
     • Sets fields + references according to your mapping.
   • This is the "transform + load" step; test on a small subset, then run in batches.
5. Expose everything via GraphQL and persisted queries
   • Define GraphQL queries (and persisted queries) that match your consuming apps' needs (mobile, IoT, etc.): https://experienceleague.adobe.com/en/docs/experience-manager-learn/getting-started-with-aem-headless/graphql/multi-step/overview
   • Your clients then consume AEM strictly through these APIs, completely decoupled from how the content was originally stored.
6. CTT is only AEM->AEM
   • You're right: Content Transfer Tool is meant for migrating between AEM instances, not from third‑party CMSs. Best practice from Adobe is exactly this ETL‑into‑Content‑Fragments approach, sometimes complemented by a professional services engagement to help with modeling and migration strategy https://experienceleague.adobe.com/en/docs/experience-manager-65-lts/content/headless/architect/introduction