How to Run a Platform Migration That Does Not Slip

The short answer

A platform migration slips when decisions are taken out of order, not because the build is hard. The way to protect the date is to put a gate at the end of every stage and refuse to move on until it is passed. Five gates matter most: acceptance criteria agreed in writing, a validated migration roadmap, a signed off redirect map and content model, a full migration rehearsal in staging, and a rollback plan that has been tested rather than only written.

Download the one-page summary (PDF)

Why platform migrations slip

In our experience, three things account for most late migrations. None of them is an engineering problem.

The data is worse than the documentation says it is

Every organisation believes its content and product data are cleaner than they are. Legacy systems accumulate half-populated fields, duplicate records, orphaned assets and local exceptions that nobody documented because everybody knew about them at the time. That complexity is a multiplier on everything downstream: it extends timelines, creates rework, and surfaces decisions that should have been made months earlier.

The integration architecture is mapped after the estimate is given

A platform gets chosen on capability. What often does not get stress-tested before the contract is signed is how it will connect to the systems that actually run the business. When the team finally maps the real data flows and dependencies, it becomes clear the estimate was built on assumptions rather than analysis. The scope has not changed. The understanding of it has. That is when dates start moving.

The governance cannot flex once something moves

On a fixed contract with pre-agreed deliverables, the mechanisms you would normally use to reset, such as replanning, rescoping or adding a workstream, require contractual change. Contractual change requires negotiation. Negotiation takes time you no longer have. Governance built for a delivery that no longer matches reality stops being a safeguard and becomes a constraint.

The five stages, and the gate at the end of each

Our method is deliberately proportionate. The same lifecycle governs a single site rebuild and a multi market platform programme, scaled to fit, and it applies whatever the source platform, whether Drupal, Umbraco, WordPress or a bespoke build. What does not change is the gate at the end of each stage. Nothing moves forward until its gate is passed, and a gate is evidence rather than an opinion.

1. Initiation and scoping

We confirm objectives, scope, stakeholders, constraints, deliverables and acceptance criteria in writing, and agree the reporting rhythm and the escalation path. Risks, assumptions, issues and dependencies go into a RAID log on day one.

Gate: written acceptance criteria and a baselined plan, agreed before substantive work begins.

2. Discovery and assessment

We review the current estate: applications, integrations, data flows and hosting. Requirements workshops cover functional and non-functional needs. In parallel we run a full pre-migration audit of the source platform, covering content inventory, URL structure and a performance baseline.

Gate: a prioritised backlog, a validated migration roadmap, and every integration dependency identified and owned. No build starts on an assumption.

3. Design and mapping

Solution and integration architecture is defined. Content is modelled once and mapped to the target. We define a clean target URL structure with 1:1 redirect mapping, and map metadata and structured data across. Accessibility to WCAG 2.2 AA is embedded from the wireframe stage rather than tested for at the end.

Gate: redirect map and content model signed off. This is the most common cause of a late slip, and we close it before build rather than during it.

4. Build and iterate

Delivery runs in short time-boxed sprints with continuous integration and testing, and a show and tell at the end of each so the client can steer throughout rather than only at milestones. Functional, regression, cross-browser, cross-device, accessibility and load testing run throughout rather than being banked for the end. Migration tooling is built and dry run against real data.

Gate: a full migration rehearsal completed in a staging environment that mirrors production, with defects closed to agreed severity thresholds.

5. Deploy and transition

Releases go through version-controlled pipelines against a deployment validation checklist. Redirects and rankings are validated in staging before go live. Cutover is phased or simultaneous as agreed. Documentation, role-based training and knowledge transfer are treated as part of delivery, not as an afterthought.

Gate: a rollback plan that has been tested rather than only written, and a hypercare period with agreed response and fix times before handover to steady state.

The five controls that run underneath

Gates protect the sequence. Controls protect the schedule between them.

The RAID log is opened on day one and worked every week, not written once and filed.
Activity-based estimation against the agreed backlog, with burn rate monitored against baseline, so drift becomes visible in weeks rather than months.
Formal change control. Every change carries a transparent cost and schedule impact before it is accepted, so scope cannot arrive quietly.
Independent review. On larger engagements deliverables are reviewed from outside the delivery team, so quality is never signed off by its author.
Weekly written progress reporting and a monthly governance review, with a defined escalation path and one named UK point of contact.

What the client has to bring

This is the part most suppliers leave out of the pitch, and it is the part that decides as much as anything on our side.

One named decision maker and a single approval chain. Two approval chains is the most reliable way we know to lose a fortnight.
Content authoring stays with your team. We provide the structure, the tooling and the quality assurance. You own the words, because nobody else can write them properly.
Early access to the source systems, and to the person who actually knows the data rather than the documentation describing it.

Frequently asked questions

How long does a platform migration take?

Anyone who quotes you a duration before the pre-migration audit is guessing. Timelines are driven by content volume, the number of integrations, how many markets or brands are in scope, and how clean the source data turns out to be. The honest answer is that discovery sets the date, which is exactly why we gate it.

What is a redirect map and why does it matter so much?

A redirect map records where every existing URL will point after the migration. Without a complete 1:1 map, search engines and inbound links land on missing pages, and organic traffic that took years to build disappears in a fortnight. It is the least glamorous document on the project and the one most likely to protect both the date and the revenue.

Will we lose search rankings when we migrate?

Not if migration is treated as a dedicated workstream rather than a task at the end. That means a full URL and performance audit before anything moves, complete redirect mapping, migration of metadata and structured data, a clean internal linking structure, and validation in staging before go live. Increasingly it also means being readable by AI answer engines, not only by traditional search.

Who owns content migration, us or the supplier?

Both, and the split should be written down before you start. We own the structure, the tooling, the mapping and the quality assurance. The client owns the words. Migrations go wrong when that boundary is assumed rather than agreed.

What is hypercare?

A defined period immediately after go live with agreed response and fix times, before the platform hands over to normal support. It exists because the first fortnight on a live platform surfaces things no staging environment can. Skipping it is how a successful launch becomes a difficult month.

Working with us

Ore Technologies is a London IT and AI consultancy. We have advised on and delivered platform and CMS migrations, eCommerce replatforms and multi market rollouts since 2013, for public sector bodies and private organisations. We are Cyber Essentials certified, we work to UK public sector digital and security standards, and we are methodology agnostic and vendor independent, which means the recommendation is shaped by your context rather than by a partner agreement.

Migration sits within our broader IT strategy and transformation and web and eCommerce development work, backed by independent programme assurance on larger engagements. We remain the single accountable party from first workshop to steady state, whether the work is delivered by our own consultants or by our named delivery partner under our direction.

If you have a platform move on the roadmap and want a second opinion on the plan before you commit to a date, we are easy to reach.