vishal patel
← Case studies
Solution architect · enterprise migrations

Enterprise CMS migration: consolidating AEM and MySQL into one content model

A US retailer's content was split between AEM and tables written directly in MySQL. I owned the solution architecture that brought both into a single content model on Contentstack, and built the accelerators that made migrations like it repeatable.

migrationcontent-modelingaemmysqlsolution-architectureaccelerators
Content split across AEM and direct MySQL tables consolidated into one content model
Typical migration engagement effort cut from about a month to a week
Discovery work that took weeks reduced to days with an AI migration tool

Context

Enterprise customers moving to a headless CMS rarely arrive from one clean system. Across engagements I owned solution architecture for migrations from AEM, Sitecore, WordPress and Contentful to Contentstack.

The most architecturally complex was a US retailer whose content lived in two places: pages and components in AEM, and product-adjacent content written straight into MySQL tables outside any CMS. The same concepts existed in both, in different shapes.

Constraints

  • Two sources of truth with different structures had to become one model, not two models side by side.
  • The target model had to work for authors day to day, not just mirror the legacy storage.
  • Migration paths needed a rollback story, agreed before any content moved.
  • The approach had to be repeatable, because every engagement starts with the same discovery work.

Approach

diagram
  1. Discover. Audit both sources and find where they describe the same thing. An AI migration tool I built scrapes the legacy site, extracts content and proposes a content model, so discovery takes days instead of weeks.
  2. Model once. Design a single content model that owns each concept once, instead of carrying the AEM/MySQL split into the new platform.
  3. Map and transform each source into that model with reusable accelerators, rather than one-off scripts per customer.
  4. Validate before import. Deterministic checks against the target schema, so the fuzzy work (AI-proposed models) never skips correctness checks.
  5. Document the path. HLD and LLD covering trade-offs, the data model, migration and rollback paths, reviewed across teams before build.

What made it repeatable

  • Migration accelerators: reusable extract, map and import building blocks instead of per-project scripts.
  • Integration frameworks for connecting the content platform to the systems around it.
  • Reference architectures that give each new engagement a proven starting design.

Together these took typical migration engagement effort from roughly a month to a week.

Key takeaways

The hard part of a migration isn't moving data. It's deciding the one model that replaces several, and making the path validated and reversible. The AI side of this work (proposing a content model from a legacy site) is covered in AI-augmented engineering.