Don't Lift and Shift: 12 Questions UK Web Teams Should Answer Before a CMS Migration

A CMS migration is rarely undone by the database. It is undone by a URL that nobody redirected, a form that stopped sending enquiries, or a page owner who did not know their content was moving. The technical work matters, but the questions below are the ones that keep a live UK site running while you replatform in 2026.

1. Who owns each page, and who signs it off?

Not the web team. Every page needs a business owner who can say whether it still belongs, whether it is accurate, and who approves the move. Build a list before migration starts. Orphan pages are the ones that cause the most argument after launch.

2. What is the full URL inventory?

Export every URL, including PDFs, campaign pages, old microsites and anything with a query string that matters. You cannot plan redirects from a sitemap alone. Check analytics, search console and the CMS itself. If you find pages nobody knew about, deal with them now.

3. Which content is actually worth migrating?

A migration is a rare chance to retire content. Decide what to keep, merge, rewrite or bin. Do not lift and shift a decade of duplicates because it feels safer. Fewer, better pages are easier to redirect and easier to maintain.

4. What is the redirect rule, and who tests it?

Agree the principle: one-to-one redirects where possible, no chains, no redirecting everything to the homepage. Build a redirect map with owners, test it on staging, and check the live site after DNS changes. A 301 that points to a 404 is worse than a clear retirement page.

5. How will taxonomy and navigation change?

If the old site had a messy section structure, the new CMS will happily recreate it. Decide the content model, categories and navigation before editors start moving pages. Otherwise you will spend launch week renaming sections and breaking menus.

6. What happens to media, alt text and documents?

Images, PDFs and video are easy to forget. Check where files are stored, whether filenames and alt text survive, and who owns the DAM. If you are moving documents, decide whether they should become HTML pages instead. That is better for accessibility and search.

7. Which integrations are in scope?

Forms, CRM, payments, SSO, search, analytics and marketing tags all need an owner. Make a list with a named contact for each. Test them on staging with real data, not just a click-through. A broken enquiry form is a business problem, not a CMS bug.

8. What are the accessibility acceptance criteria?

Put WCAG 2.2 AA in the acceptance criteria, not in a wish list. Test templates with keyboard navigation, screen readers and zoom. Check that the new CMS does not strip heading levels or table headers. If accessibility is only checked after launch, it will be expensive.

9. Who signs off templates and content types?

Design sign-off is not enough. Get content, marketing, legal and accessibility to approve the templates and content types before build finishes. A beautiful template that editors cannot use without breaking the layout is not ready.

10. What is the go-live and rollback plan?

Choose a quiet window, freeze content, lower DNS TTL in advance, and agree who can pull the trigger on rollback. Have a status page and a comms plan. Do not migrate on the Friday before a bank holiday unless you enjoy adrenaline.

11. How will you keep the live site running during the migration?

Assume the old site stays live while the new one is built. Decide how content changes are synced, who can publish, and when the final freeze happens. If editors keep updating the old CMS after the freeze, you will lose work.

12. What does 'done' mean after launch?

Launch is not done. Plan hypercare, redirect monitoring, 404 checks, analytics validation and training. Agree the support window and the exit plan from the old vendor. Then book a review for a month later, when the real problems have surfaced.

If you can answer these twelve questions in writing, with names and dates, you are in better shape than most. If you cannot, do not touch a single URL yet.