A safe 2026 CMS migration depends on verified compatibility, tested access controls, stable URLs, and measurable performance. A CMS migration moves a website's content, templates, data, or functions to a new platform, version, host, or architecture. No single standard covers every migration. Teams need acceptance criteria based on the exact CMS, runtime, database, extensions, hosting environment, audience, and business workflows.
Official resources:
- Plan and test CMS migration URL redirects — Use Google’s step-by-step guidance to map old URLs, test permanent redirects, submit sitemaps, and monitor the move.
- Review access-control risks after migration — Use OWASP’s guidance to verify that roles, permissions, and API authorization remain enforced server-side.
Table of Contents
- What must be compatible before migration?
- How should URLs and browser support be handled?
- What security checks must be repeated?
- What performance and accessibility targets apply?
- Which questions belong in the migration plan?
What must be compatible before migration?
Start with an inventory of components and their dependencies. Record the CMS version, server runtime, database, themes, modules, plugins, APIs, scheduled jobs, analytics tags, forms, payment tools, and deployment process. Do not treat a platform's minimum requirements as a desirable target. WordPress currently recommends PHP 8.3 or later, MariaDB 10.11 or later or MySQL 8.0 or later, and HTTPS.
Its legacy PHP 7.4 and MySQL 5.5.5 baseline uses end-of-life software that may expose a site to vulnerabilities. Drupal requires equally careful dependency checks. Drupal's August 4, 2026 guidance warns that upstream dependencies may raise the required PHP version before a Drupal major version reaches end of life. Drupal 9 and later also require PDO and an enabled database connector. Test the proposed production combination, not each component in isolation:.
- Confirm the CMS supports the selected runtime and database versions.
- Check every extension against the target CMS version.
- Exercise integrations with realistic data and permissions.
- Verify background jobs, email delivery, forms, and file handling.
- Document unsupported components and decide whether to replace, rebuild, or remove them.
How should URLs and browser support be handled?
Build an old-to-new URL map before launch when paths or domains will change. Include articles, landing pages, media, campaign destinations, translated pages, and URLs that receive external traffic. Configure server-side permanent redirects and test each important route. Google advises keeping migration redirects for at least one year and says permanent 301 redirects do not lose PageRank. Avoid redirecting many unrelated pages to the new homepage because Google may interpret that pattern as a soft 404.
Expect temporary ranking fluctuations after a significant move. Google says medium-sized sites may need weeks or longer before new URLs appear consistently, so launch-day checks cannot establish whether the move has fully settled. Define browser support from audience needs rather than a generic compatibility badge. MDN Baseline covers Safari, Chrome, Edge, and Firefox, but excludes older versions, web views, and assistive technology. Use it as a development reference, then test the devices and browsing contexts your visitors actually use.
What security checks must be repeated?
A successful content import does not prove that authorization survived the move. Revalidate every role, permission, administrative route, file restriction, and API operation on the migrated system. OWASP's 2025 Top 10 places broken access control first.
Likely consequences include unauthorized disclosure, modification, or destruction of information. Hiding buttons or menu links is insufficient because the server must reject unauthorized requests. Run permission tests with distinct accounts: Also review imported accounts, API credentials, service users, and temporary migration access. Remove unnecessary privileges and confirm that error responses do not reveal protected data.
- An anonymous visitor attempts to reach private pages and files.
- A basic user tries administrative URLs and privileged API calls.
- An editor attempts actions reserved for administrators.
- A former or disabled user tries existing sessions and saved links.
- Authorized users confirm that legitimate workflows still work.
What performance and accessibility targets apply?
Turn "fast" into measurable acceptance criteria. Google's Core Web Vitals targets are LCP within 2.5 seconds, INP below 200 milliseconds, and CLS below 0.1. LCP reflects loading, INP reflects interaction responsiveness, and CLS reflects unexpected layout movement. Test representative page types, including the homepage, long articles, listings, forms, and media-heavy landing pages.
Compare results before and after migration under similar conditions. Continue monitoring production because laboratory and staging tests cannot reproduce every visitor, device, cache state, or third-party delay. Accessibility belongs in templates, content workflows, and acceptance tests. W3C recommends WCAG 2.2 as the current conformance target; meeting WCAG 2.2 also satisfies WCAG 2.0 and 2.1 requirements. Check navigation, keyboard operation, focus visibility, headings, forms, error messages, images, captions, and contrast.
Which questions belong in the migration plan?
Ask questions that produce evidence, owners, and pass-or-fail decisions: Record the answer, responsible owner, test method, and required evidence for each question. A statement such as "redirects tested against the complete URL inventory" is actionable; "migration looks good" is not.
- Which exact platform, runtime, database, and extension versions will run in production?
- Which components lack confirmed support, and what is the fallback?
- Which URLs change, who owns the redirect map, and how will it be tested?
- Which roles can read, create, edit, publish, delete, or administer each resource?
- Which page types must meet the performance thresholds?
You Might Also Like
- Website Maintenance 2026 Guide: compatibility, security, and performance; Key Facts and Questions to Ask
- What Is New With CMS Migration and Web Development in August 2026? Latest release notes and search documentation and Key Takeaways
- CMS Migration and Web Development August 2026 Update: What Changed, Why It Matters, and What to Watch Next
