cypher
there is no spoon.

How long does a CMS migration take?

It depends less on the platform than on four things: how much content you have and how clean it is, how many templates and components must be rebuilt, how many systems connect to the site, and how quickly decisions get made. In many migrations, more calendar time goes to content clean-up and approvals than to building.

Updated

What drives the timeline

  • Content volume and quality: duplicate, outdated and orphaned pages all have to be found and dealt with.
  • Templates and components: every distinct page layout and building block has to be rebuilt on the new platform.
  • Integrations: forms, search, CRM, commerce, sign-in and analytics each need connecting and testing.
  • Sites and languages: every extra site or language multiplies the content work.
  • Redirects and SEO: every old URL needs a new home before launch.
  • Decisions and sign-off: a question that waits a week for an answer adds a week.

Where the time goes

  1. InventoryFind every page, template, component, file and integration on the current site.
  2. PlanDecide what moves, what merges and what retires, and how the new site will be built.
  3. BuildRebuild templates and components on the new platform, once, so they can be reused.
  4. Move contentCarry pages, media and metadata into the new templates.
  5. CheckCompare old and new page by page, and test accessibility, performance and every integration.
  6. LaunchSwitch over with redirects in place, then watch closely for the following weeks.

How to shorten it without cutting corners

  • Retire outdated pages before you move them, not after.
  • Decide early which system is the source of truth for each kind of content.
  • Agree what “done” means before anyone starts: content parity, accessibility, performance.
  • Give one person the authority to make decisions, with a deadline on each question.
  • Check as you go instead of saving every check for the end.
  • Plan a short content freeze, or a re-sync, for the final move.

How Cypher handles this

Cypher runs a migration from a playbook. It inventories every page before anyone builds, writes the plan you approve once, then moves and checks content page by page as it goes. You make about three decisions; everything else is settled and logged.

Content parity of 98% or better and every redirect kept are part of what “done” means, and anything not done is listed in writing at handover.

Questions people ask

Should we redesign and migrate at the same time?

You can, but it adds decisions and risk. Some teams move content and structure first and redesign once the new platform is stable; others combine them when the old design can’t be rebuilt anyway.

What slows migrations down most?

Unclear content ownership and late decisions. Once the plan is agreed, the technical work is often not the slowest part.

Can we keep publishing during a migration?

Yes. Plan a short content freeze for the final move, or re-sync anything published after the first content move.

Does the platform we’re moving to change the timeline?

Less than you’d expect. The amount and state of your content, and the number of integrations, matter more than which enterprise platform you choose.

See it on your site. Thirty minutes, no slides.Book a demo