CMS Migration checklist: What actually survives the move, your content or your templates and code?

AI has made fast, automated, sometimes free CMS migration offers easy to find. The pitch is simple: point a tool at your website, and a few days later your entire site, custom code and integrations included, is running in the new CMS.

Before comparing timelines and prices, ask a more useful question: what exactly arrives on the other side? An enterprise website is built in layers, and they don't migrate the same way. Some layers move well with automation. Others depend on how the site was built, which no tool can see by reading your published pages.

This guide breaks a CMS migration down into five layers, explains what automated tools can do with each one, and ends with a CMS migration checklist you can use to check, layer by layer, what your migration really covers.

The five layers of a CMS migration

1. Content

Text, images, documents, video, SEO metadata, internal links and navigation. This is the most visible layer and the easiest to extract, either from a CMS export or from the published pages. It is also where AI performs best: it can recognize a headline, an intro, an image and its caption, even in poorly structured HTML.

2. Content model

Your content types (news, product page, job posting, office location), their fields, the relationships between them and the taxonomies that classify them. A content model isn't visible on a page; it has to be inferred. A tool that only reads the rendered output has to guess the structure behind it. The risk is a flattened model where every content type becomes a title, an image, a date and one large rich text field. The content is there, but it has lost the structure that let you reuse it, translate it field by field, personalize it or deliver it headless.

3. Components

The reusable blocks editors assemble pages from: hero banners, carousels, calls to action, forms, comparison tables. Migrated well, they arrive as a component library your team can reuse. Migrated poorly, they become frozen HTML that only a developer can change.

4. Templates

Page templates and layout rules: which components are allowed where, how a page inherits from its section, which variants exist per site or per language. Templates encode years of editorial and design decisions. They are hard to identify from the outside, because two similar-looking pages can come from two different templates, and the reverse.

5. Custom code and integrations

Custom development, business logic, roles and permissions, approval workflows, and connections to your CRM, ERP, SSO, search engine or commerce platform. This is the most expensive layer of a CMS migration project, and it is completely invisible in the published pages.

What automated CMS migration tools do well, and what they leave out

Most automated migration tools start from what they can reach: the published website or an export from the old CMS. For content migration, the results can be very good. Content is extracted, cleaned up and loaded into the new CMS with its metadata.

The further down the layers you go, the more the tool has to guess. The target content model is inferred from the pages and is often simpler than the original. Templates are grouped by visual similarity, with mistakes. Custom code and integrations usually aren't migrated at all: the tool moves the content and leaves the logic behind.

That is a limit of the approach, and it is fine as long as the offer says so. The problem starts when a migration sold as “complete” only covers content. The hardest work then shows up after the contract is signed, once the budget and the timeline are fixed.

Watch for these warning signs:

• the offer talks about “migrated pages” and never mentions the content model, templates or integrations
• nobody asks to see your code, workflows or list of integrations before quoting
• the target content model is delivered after the migration instead of being approved before it
• the timeline is set before anyone has looked at your site, and is the same for a brochure site as for a portal with a customer area

Why templates and custom code are the hardest part

Content is data: you can extract it, transform it and load it again. Code and templates are decisions. They reflect how your organization publishes, approves, translates and personalizes content, and how your website talks to the rest of your stack.

Those decisions don't copy over from one CMS to another, because the two platforms work differently. A business rule hard-coded in the old CMS may be a configuration setting in the new one, or it may require custom development. A CRM connector may exist out of the box, or it may need to be built. This is where CMS migration budgets and schedules slip, and where you need people who know both platforms.

A good migration plan doesn't try to automate everything. It automates what can be automated (content and most components), and it identifies and scopes up front the work that needs experts.

The CMS migration checklist, layer by layer

Use this checklist in two passes: what to inventory before the migration, and what to verify once your content is in the new CMS.

Your CMS migration plan, step by step

Before the migration

• Audit your content and decide what to keep, merge or retire
• Document your content model, components and templates
• List every integration, custom development and workflow, with an owner for each
• Record your SEO baseline: indexed URLs, top pages, rankings
• Get a written scope from your vendor that covers all five layers

During the migration

• Approve the target content model before any content is moved
• Run a pilot on a small batch of pages to check field mapping, media and permissions before moving everything
• Keep your current site in production until the new one is validated
• Compare the old and new sites side by side, page type by page type
• Test integrations and workflows end to end, with real users
• Freeze content on the old site before the final cutover, so no edits are lost
• Keep a rollback plan ready: a full backup of the old site and a tested way to switch back

After go-live

• Check redirects, crawl errors and indexing in Search Console
• Monitor traffic and conversions on your top pages
• Train editors on the new components and templates

For the SEO side of a migration in more detail, see our guide to website CMS migration and SEO. For project phases and governance, see our article on CMS replatforming.

How Jahia approaches CMS migration

Jahia's free AI-powered CMS migration rebuilds your content, components and metadata in Jahia. Content is rebuilt in content models you approve, and components are grouped into a reusable library.

Before the project starts, a free assessment inventories your site: content, components, metadata, integrations and custom development. It separates what AI rebuilds from what Jahia experts handle with you (custom development, business logic and integrations) and scopes that work before kickoff. Your current site stays live and is never modified, you see the migrated result before you commit, and your team validates every step.

To see how it works on a specific platform, read our AEM to Jahia migration walkthrough, or the overview of our free AI CMS migration.