Now booking enterprise content platform builds for 2026. Contact us
The CMS changes, and the content model, templates, integrations, and every URL move with it. WAYF plans that move in writing, prices it fixed, and has run it at enterprise scale: Ingersoll Rand's China platform left Oracle Content Manager in five months, with zero downtime at cutover.
Exports never drop cleanly into a new system. Page types, blocks, references, and localization get modelled for the platform you are moving to, approved in writing before the first entry moves.
Rich text is parsed and re-emitted, references are resolved against new identifiers, and the import is validated against the source so silent field loss shows up in a report instead of in production.
Every address the old site answered gets a destination and a permanent redirect. Google documents that 301s preserve the signals a URL has earned; losses come from gaps in coverage, so the map is built from a full inventory.
The switch is planned, rehearsed against a staging copy, and reversible. On Ingersoll Rand's China platform the cutover ran with zero downtime.
For the definitional version — the eight phases a replatform runs through and the failure modes of each — see the replatforming glossary entry. For a specific source system, the per-platform migration pages cover what maps cleanly and where the budget goes.
The full replatform. Right when the current CMS has an end-of-life date, its licence economics stopped making sense at your volumes, or its content model cannot express what your team publishes. Our CMS end-of-life tracker lists the dated deadlines.
When the constraint is a slow or ageing front end and the CMS still earns its keep, the rebuild happens on top of what you have. Content, editorial process, and URLs stay put; the code that renders them is replaced.
If your setup is already well optimised, we say so. Plenty of engagements scope improvements to a platform the client keeps: performance work, editorial workflows, integrations, and the maintenance that keeps it secure.
AI assistants cite what they can retrieve, parse, and attribute, and all three are properties of how a platform is built. Every replatform we deliver ships them as defaults. The reasoning, and the six checks you can run against your current site today, are in Your CMS is a GEO decision.
Before delivery starts, we walk the client through how cooperation will work, what scope sign-off means, how new requests enter the plan, and what happens when scope changes. The cooperation model is written down and accessible to both sides later.
A dedicated discovery team sits on every inquiry from day one. We refuse to start building from a vague request. For every request we agree on the problem being solved, why it matters, who it affects, the expected outcome, the known constraints, the known risks, and what is still unclear.
Scope is approved in writing by the right decision-maker, with a date, before delivery planning starts. Out-of-scope items are named explicitly. Acceptance criteria are written before the first commit. A scope change after sign-off is handled as a planning event, with its own estimate and sign-off.
Approved scope becomes a visible plan with tasks, owners, priorities, dependencies, risks, and a target delivery window. Technical review happens during planning, so feasibility is settled before build starts. Active scope and future ideas live in different places.
Code is reviewed before it gets merged. QA runs through the whole of delivery. Implementation gets continuously checked against signed-off scope. Release readiness is decided on test evidence both sides can see.
A release is a communication event as much as a deployment. The release outcome is verified after the deploy. Release notes spell out what was released, what changed for the user, what limitations remain, and what follow-up exists. Releases never introduce new scope.
Live projects do not decay into an unmanaged stream of urgent Slack messages. Defects, support requests, and new ideas are separated and routed differently. Support work does not silently consume the development capacity committed to planned scope.
China was still on the legacy build with Oracle Content Manager because Contentstack was not available in the region. When OCM announced its end-of-life, we delivered the replacement CMS, the content architecture, and the provider contract the rebuilt frontend now runs on globally — a replatform with a hard external deadline.
The consultation is free, and a fixed quote follows discovery. Price is set by measurable inputs rather than the platform name: the volume and variety of content, how many content types the new model carries, how much of the archive is rich text with embedded components, the integration list, and how many URLs need mapping. We put the number in writing before work starts, and it holds.
The same inputs that set the price set the calendar, so we give a date after discovery rather than before it. For scale: the build phase of a scoped migration usually runs four to eight weeks once scope is signed off, and Ingersoll Rand's full China replatform ran five months from kickoff to a zero-downtime launch.
The risk concentrates in URLs, and it is manageable. Google's site-move documentation states that permanent redirects do not cause a loss in PageRank, so a move where every changed URL 301s to a genuine equivalent preserves what the old address earned. Our scope includes the full URL inventory, the redirect map, and parity checks against the legacy site before launch.
Often the right answer is smaller than a full replatform. If the constraint is the front end, we rebuild it on the system you keep. If your setup is already well optimised, we say so and scope the improvements instead. A replatform is the answer when the system itself is the limit: an end-of-life date, licence economics at your volumes, or a content model it cannot express.
Most often Payload, where we are a partner agency and a top contributor, because it gives the client structured collections defined in code, full control of rendering, and an open-source system they can self-host and own. Where a different target fits your stack or your team better, that is the recommendation we give.
Your team. Handover includes editor training and documentation, the first weeks after launch run as a stabilisation window with the delivery team on hand, and ongoing maintenance is available as a separate, clearly-priced engagement rather than a dependency.
Whether or not you end up working with us, you will leave the first conversation with a clearer read on what a move off your current system involves, what it would preserve, and what a reasonable first step looks like.
Twenty-five minutes to walk through the work and decide if we're the right team for it. Scoping and a fixed price come after.