Legacy platform migration
Off Sitecore, SharePoint, Optimizely or a bespoke CMS, without losing what it quietly does.
Older platforms rarely fail all at once. Licences get harder to justify, the people who built them move on, and every change takes longer than the last. We map what yours actually does, including the parts nobody wrote down, and move it to a platform your team can run.
Which situation are you in?
On a commercial DXP
Sitecore, Optimizely and similar platforms carry licence and specialist costs that are hard to defend once most of their features go unused. The question is which features you rely on, and what replaces each one.
Publishing on SharePoint
SharePoint is often doing two jobs: document management that belongs there, and public or member publishing that doesn't. We separate the two so each can be run properly.
A system built in-house
A custom CMS that only one person understands is a risk even when it works. We document how it behaves today, then rebuild that behaviour on a supported platform.
The risks we manage
The risk in a legacy migration is rarely the content you can see. It is the workflow, permission or integration that lives in custom code, and only shows up when it stops working.
Hidden behaviour
Scheduled jobs, custom workflows and permission rules found and documented before build, not after launch.
Content model
Unstructured pages turned into structured content, with each content owner signing off the mapping.
URLs and SEO
Every old URL mapped to its nearest new page, tested before cutover and monitored afterwards.
Integrations
Every connection to CRM, finance, identity and analytics listed and decided on: keep, rebuild or retire.
Licence timing
Cutover planned around your renewal date, so you are not paying for two platforms for longer than necessary.
Support after launch
Parallel running, a rollback plan, then ongoing care through WebsiteSupport.io if you want it.
How a legacy migration runs
Typically six to nine monthsWorkshops, a feature and integration inventory, decision log.
New content model, data mapping, redirect plan, integrations.
Staged releases and repeated test migrations of real data.
Freeze, final migration, redirects, parallel running, rollback.
Training, documentation, support through WebsiteSupport.io.
Replacements we've delivered
All case studies →
Services for Schools
Ordering and reporting for schools buying services from the borough of Hounslow, simple at the front and serious behind it.
Chevening
Replaced a scholarship application system handling thousands of applications a year, with design partner Webb & Webb.
Questions we get asked
If yours isn't here, it's usually quicker to ask on the phone.
The one that fits your content, integrations and team. Discovery compares the options against what you actually use, and the recommendation comes with its reasoning.
Often, if discovery starts early enough. We plan the cutover date around the renewal and tell you on the first call whether the timing is realistic.
It is normal. Part of discovery is finding the behaviour that isn't documented, from the code, the logs and the people who use it every day.
Not if the redirects are planned. Every old URL is mapped during architecture, tested before cutover and monitored in Search Console afterwards.
Most run six to nine months including discovery. We will tell you which end of that range yours is likely to be after the first call.
Book a migration readiness review
A free 30-minute call with a technical lead, then a short written summary: what to move to, roughly what it involves, and what to do first.
020 3608 2525