Replatforming

CMS replatforming is the move of a website or content estate from one content management system to another, together with the work that change forces: a content model designed for the new system, templates and integrations rebuilt on it, content transformed into the new structure, and every URL accounted for.

If you are scoping one rather than defining one: how WAYF runs a CMS replatforming covers the fixed written scope, the redirect map, and a reference cutover that ran with zero downtime.

The word names different work in two adjacent fields. In cloud migration it is one of the seven strategies AWS documents for moving applications, which AWS also calls lift, tinker and shift: moving an application to the cloud and introducing some level of optimisation on the way, sitting between a straight rehost and a full refactor. In ecommerce it usually means changing the storefront platform, where the catalogue, checkout and order history carry the risk that the content archive carries here. This entry covers the content-management sense.

Replatforming contains a migration; the others can happen on their own

Five words are used loosely for work with five different scopes. The table below sets out what each one changes and what it leaves alone.

Term	What changes	What carries over	Usually triggered by	Risk profile
Replatforming	The CMS itself, plus the model, templates and integrations built on it	Content, as transformed data. URLs, where the mapping is deliberate. The design, where the scope excludes a redesign	Vendor end of life, licence economics at your volumes, a content model the current system cannot express, an editorial bottleneck no plugin fixes	Highest of the five. Data, URLs, editorial process and front-end code all move in one project
Migration	Where content lives and the shape it is stored in	The content and its meaning	Named as a phase inside a replatform. On its own, a move between instances, spaces or environments of the same product	Concentrated in data fidelity: silent field loss, broken references, rich text degraded on the way through
Rebuild	Templates, components, front-end code, integration wiring	The CMS, the content model, the URLs, usually the design	A front end that has become slow to change, a framework past support, performance or accessibility work the current codebase cannot carry	Contained to code. Content and editorial process stay where they are
Redesign	Visual design, layout, navigation, often some copy	The CMS, the content, mostly the URL structure	Brand work, a positioning change, conversion or accessibility problems traced to the interface	Moderate. The exposure is navigation and internal linking, which change how pages are found
Re-hosting (lift and shift)	The infrastructure under an unchanged CMS	Everything above it: CMS version, content, model, templates, URLs	Data-centre exit, hosting cost, an operating system or database version out of support	Lowest for content. The exposure is operational: DNS, certificates, environment parity

Content transforms and templates are rebuilt

The hope behind many CMS moves is a lift and shift: pick the content up from the old platform and set it down on the new one unchanged. Exports rarely come out in a shape the new system can take without transformation.

Content transforms because systems store it in different shapes. A proprietary rich-text format has to be parsed and re-emitted. Page layouts assembled from one system’s blocks have to be mapped onto another’s. References between entries point at identifiers that will not exist in the target until the import creates them. Metadata organised one way is remapped to another. The field-level mapping tables in the Contentful, Contentstack and Strapi guides show how granular that gets, and where the hours actually go.

Templates do not port. The code rendering the old site is written for that platform and its templating language. Even where the design is kept identical to the pixel, the code producing it is new. The design system underneath is portable: tokens, component definitions and content structure can be carried into the new build and reused there.

Both the transform and the template rebuild belong in the scope before the quote. A replatform scoped as a copy operation gets re-scoped partway through, and the difference lands on the budget after the work has started.

The eight phases, and where each one fails

The sequence below is the shape most CMS moves take. Teams label the phases differently, but taking any of them out of order raises the cost of everything after it.

1. Discovery and inventory

Someone writes down what exists, starting with every URL, reconciled from a full crawl of the current site and from Search Console, which reports URLs still taking organic traffic after the site stopped linking to them internally. The list also covers every content type and the fields on it, every integration wired into the CMS (forms, search, analytics, CRM, marketing automation, translation, digital asset management, single sign-on), every editor role, and every destination content is consumed by beyond the website. The output is an inventory with a keep, merge or drop decision recorded against each item.

Where it fails: the inventory covers pages and misses everything else. Microsites on a second installation, PDFs linked from body copy, forms embedded from a third-party tool, campaign landing pages built by a marketing team outside the main publishing workflow. The other failure is that the keep-or-drop decision has no named owner, so the whole archive migrates by default, at cost, and arrives cluttering the new system. A pre-migration checklist for non-technical teams covers the parts of this only the client side can supply.

2. Content modelling

The types, fields and relationships of the new system get designed. This is where the decisions with the longest life are made: what becomes a typed field and what stays as free rich text, how pages are composed from blocks, how localisation is keyed, how references between entries work, which fields drive navigation and which drive search. Content model and structured content cover the underlying ideas.

Where it fails: the new model is drawn as a copy of the old one, carrying the previous system’s accumulated compromises into a platform that had no need of them. The opposite failure is a model with a separate type for every page variant an org chart implies, which editors route around as soon as they are working to a deadline. Both are usually caused by the same thing, which is finalising the model before the people who publish daily have seen it. A third failure is a model that describes the pages that exist today and has no field for what the content team has been asking for since the last platform.

3. Build

Templates, components, the front end, integrations, roles and permissions, preview, editorial workflow, search, and the deployment pipeline. The choice of architecture belongs here too, and the trade-offs are covered under headless vs traditional CMS and composable architecture.

Where it fails: front-end work starts before the model has settled, so component interfaces keep changing under the people building against them. Integrations get treated as a late line item, and the ones that break the schedule are always the ones with an owner outside the project team, where a change request queues behind someone else’s roadmap. Preview and editorial workflow are usually scheduled last, so they are the first things cut when time runs short. Editors work with the result from day one.

4. Content and asset transfer

A scripted pipeline exports from the source, transforms, and imports into the target, run repeatedly against real content. Order matters: assets move first so that entries can reference them, then entries, then a resolution pass to fix cross-references, because those references point at identifiers that only exist once the import has run. Rich text is where the effort concentrates, particularly embedded components, inline links to internal pages that need re-pointing, and markup accumulated across years of editors and plugin versions.

Where it fails: the transform is validated against a handful of hand-picked pages. A real archive holds content authored across years of changing editorial habits, several rich-text editors and a great deal of pasting from Word, and most of the transform effort sits in that long tail. The other failure is procedural. A one-shot manual migration loses or re-keys by hand anything published after the snapshot. A re-runnable script means the final run repeats a process already executed several times.

5. Redirects

Every old URL is mapped to a new address or to a deliberate removal, in a table built before anything moves and validated on staging. Permanent redirects (301, or 308 where the request method must be preserved) tell a crawler the target is canonical. Temporary redirects (302, 307) are not used by Google’s indexing pipeline as a signal that the target should be canonical, which is why staging leftovers do real damage. Chains get collapsed so that each old address points directly at its final destination. Google’s guidance is to keep the redirects in place for as long as possible, generally at least a year.

Where it fails: the categories nobody inventoried. Paginated archive pages, faceted and parameterised URLs, RSS feeds, XML sitemaps, and non-HTML assets such as PDFs that have accumulated inbound links. Staging validation catches loops, chains and rules that were written but never deployed. It is also the step most often dropped under deadline pressure. Why we track redirects from day one goes through the audit and the post-launch monitoring in detail.

6. Editor training and handover

The people who publish need the new model explained in their vocabulary, documentation of the decisions behind it, and a sandbox holding real content. Governance moves with the platform: roles, review steps and approval chains have to be rebuilt as configuration in the new system, which content governance in a headless CMS works through. The operating practice around all of it is covered under content operations.

Where it fails: training arrives as a recorded walkthrough in launch week. Knowledge concentrates in the one person who configured the system, which is the exposure the bus factor audit is designed to surface. Without documented intent behind the model, editors rebuild their old habits inside the new system, pasting styled markup into rich-text fields and using one flexible type for everything, and the structure that justified the project stops holding.

7. Cutover

Traffic switches, redirects go live, the old system is frozen and kept readable, monitoring is already running. The plan names a content freeze window, who signs off on the switch, how quickly the old system can be restored, and who is authorised to call for that. Google’s site-move guidance is explicit about sequencing: “Change only one thing at a time.” Moving platform, changing domain and launching a redesign in the same week makes any traffic movement afterwards impossible to attribute. Where a replatform keeps every URL identical, a different set of steps applies: lower the DNS TTL ahead of the switch, confirm Googlebot can reach the new infrastructure with the URL Inspection tool, and expect a temporary drop in crawl rate immediately after launch, followed by a steady increase over the days after it.

Where it fails: the date is chosen for the project team’s convenience and lands beside a campaign, a quarter close or a seasonal peak. Verification before the switch is treated as a formality, and no one is assigned ownership of the first week after it.

8. Post-launch

The project runs on past the launch date. Search Console is watched for crawl errors, index coverage and organic traffic by URL group, the last of which localises problems that a total-traffic chart hides: a homepage recovering while the archive stays flat points at a specific gap in the redirect map. Editors file snags. Content published during the freeze is reconciled. Google notes that a medium-sized site can take a few weeks for most pages to move in the index, and that larger sites take longer, so a verdict reached two weeks after launch is premature.

Where it fails: the team disbands at cutover and no one owns the monitoring. Regressions get attributed to an algorithm update, and by the time the pattern is recognised the redirect gap has been in place for months.

When replatforming is the wrong answer

A platform move is the most expensive response available to a content problem, and it matches only some of them. Locating the constraint comes first: it sits in the software’s capabilities, in the content model, or in the way the organisation works.

Some problems persist after the move. Approval chains belong to how the organisation is arranged, so a queue of four sign-offs is still four sign-offs once the content lands on a new platform. A page built as a bespoke template needs a developer on any system, and a model that keeps every page bespoke keeps the developer in the loop on a newer stack.

Option	What it changes	What stays	Where it fits
Stay and fix the process	Roles, review steps, the templates editors can reach, governance	Platform, model, code	The complaints are about waiting, approvals and duplicated effort, and the current system already supports what is being asked of it
Upgrade in place	The CMS version, and whatever that upgrade forces	Content, model, URLs, most integrations	The product still fits, the installation has fallen behind, and a supported version exists to move to
Re-host	Infrastructure, hosting contract, deployment pipeline	CMS, version, content, model, URLs	Cost, data residency or an out-of-support operating system is the problem, and the CMS itself is fine
Replace the front end, keep the CMS	Templates, delivery, performance, the presentation layer	The CMS as the editing and storage system	Editors are satisfied with the admin, and the limit is what the rendered site can do. See headless CMS
Phased replatform	One section or one team at a time, both systems live in parallel	Everything not yet moved	The estate is large, several teams publish into it, and a freeze would cost more than running two systems side by side
Full replatform	The CMS and everything built on it	Content, as transformed data	The platform is at or near end of life, the licence economics have stopped working at your volumes, or the model it can express has become the binding limit

Two things shorten the deliberation. A vendor end-of-support date turns an open-ended decision into a dated one, and the CMS end-of-life matrix lists the published dates for the major platforms. A renewal does something similar by putting a number on the alternative, which is what the pre-negotiation checklist is for.

Staying has a cost over the same horizon, and it is the one most often left out of the comparison. CMS TCO sets out the five lines a full comparison needs and a three-year structure to put them in, the real 5-year TCO of staying on your current stack works a longer horizon through with named inputs, and the hidden costs of staying on a legacy CMS covers the spending that never reaches an invoice. How much of the eventual exit cost is already fixed by decisions made years ago is the subject of vendor lock-in.

Where a move is warranted but a freeze is unaffordable, the phased route is a real engineering pattern with a literature behind it, described in moving 40 product teams off a legacy stack without a freeze. For reading the signals in the first place, five signs you’ve outgrown your CMS covers general-purpose platforms and when to migrate from Framer covers the visual-builder version of the same question.

Where the platform-specific detail sits

Most of the difficulty in any given replatform is specific to the system being left, because that is what determines the export format, the rich-text structure and how much of the model is recoverable programmatically. The guides below are organised by source platform and carry field-level mapping tables. Payload is the destination in each of them.

Structured and headless sources, with field-level mapping tables and the export pipeline: Contentful, Contentstack, Strapi, Wagtail and Oracle Content Management.

Traditional platforms and suites: WordPress, Drupal, Adobe Experience Manager, Sitecore, Optimizely, Kentico, Sitefinity, TYPO3, Umbraco, Joomla and Webflow. What a suite bundles, and why leaving one is a larger exercise than leaving a single-purpose CMS, is covered under DXP. A second Wagtail piece, when Django teams should move to a JavaScript-native platform, takes the stack-alignment question and weighs Payload, Strapi and Sanity as destinations.

For the two decisions that sit either side of the project, what to ask before choosing a new CMS or a migration partner covers the questions worth asking, the dos and don’ts of a CMS migration covers what to insist on once work starts, and how to write a transformation brief covers getting the scope into a form that can be priced. Where the shortlist is between specific products, Contentful vs Payload and Sanity vs Payload set them side by side, both written from the Payload side, and self-hosted vs SaaS CMS covers the operating model underneath the choice.