Loading…
Loading…Operational Platforms · Build
Platform Migration
Off the tool you have outgrown, onto a stack you own, without losing a single URL.
A rebuild of your website or application from a page builder, a legacy CMS or an ageing framework onto a modern stack you own, with every existing URL preserved, content migrated, and analytics reconnected. Two to six weeks depending on scale, phased so you can see progress.
Discuss this engagementWho this is for
- Businesses on page builders that have hit a wall
- Teams inheriting a legacy application from a previous developer
- Marketing leads who cannot ship a change without a ticket
The situation
The tool that got the business started is now the thing holding it back. A page builder that made the first version fast to launch now fights every request that is slightly out of the ordinary: a booking flow, a members' area, a page layout the template was never built to hold. Every small change becomes a workaround, and the workarounds are starting to show.
Sometimes the barrier is a person rather than a tool. A developer built something bespoke, then left, and nobody on the current team can safely open the code without fear of breaking it. The site keeps running because nobody dares touch it, which is its own kind of debt: every good idea for the business now waits behind a fear of the thing that carries it.
What changes
You end the engagement holding a codebase your own team can read, run and change, on infrastructure billed to you directly and inspectable end to end. Nothing about how visitors find you moves: every URL that ranked before still ranks, still resolves, still leads where it always led. The only difference they notice is a site that loads faster than it used to.
A migration should be invisible to the people who use the site and completely legible to the people who run it.
For your team, the change is in what a request now costs. A layout change that used to need a ticket and a wait becomes a pull request reviewed the same day. Content changes ship in minutes because the person making them can see exactly what will happen before they publish it, on a stack built to be read clearly.
How it runs
- 01
Audit pages, assets, forms and integrations
- 02
Build the redirect map and agree it
- 03
Rebuild on staging in phases
- 04
Reconnect analytics, forms and bookings and test
- 05
Cut over the domain and monitor for a week
We rebuild in phases you can see, instead of running one long build that reappears at the end as a surprise. Each phase lands on the staging domain first, where you review it against the live site before the next phase starts, so drift gets caught early, while it is still cheap to fix.
The cutover itself is the smallest step in the project, precisely because everything before it was designed to make it small. The domain points at the new site, the redirect map takes over, and we watch traffic, forms and error rates for a full week afterward, so the calm cutover is a result of the work, not luck.
What you receive
The repository, handed over with the access and the history intact, so the site or application is yours to run whether or not you continue working with us. Alongside it, the redirect map itself, kept as a living reference in case a page ever needs to move again.
You also get a content guide written for the person who will actually use it, covering how to add a page, swap an image or update a price without needing to understand the underlying framework. A monitoring report closes out the engagement, showing traffic, errors and redirect performance across the week after cutover, so you start on the new stack with evidence that it held rather than a promise that it would.
At least twenty websites and platforms rebuilt on a modern stack
Five platform migrations with full data and domain cutover
The engagement
- Format
- Content and asset audit, redirect map, phased rebuild on a staging domain, cutover with monitoring
- Duration
- Two to six weeks
- Typical range
- Engagements in this shape typically run two to six weeks and $5,000 to $20,000.
- What we need from you
- Access to the current site or application and its hosting
- Brand assets and any content changes you want made during the move
- A named person to approve the redirect map and the cutover window
More in Operational Platforms
- BuildProduct and Platform BuildFrom a scoped idea to a working product in phases you can see and stop between.Four to twelve weeks
- BuildGrowth Observability SetupEvery source of growth data flowing into one place, daily, before you decide anything.Two weeks
- BuildIntelligence Features in ProductThe feature your users expect now: matching, summarising, classifying, answering, built to be trusted.Two to four weeks
- BuildOperations Platform for OperatorsA back office built around how you actually work, live in days, run with you for years.One to eight weeks
Questions
Will we lose search rankings?
No, every legacy URL is mapped and redirected before cutover and verified after. We build the redirect map from your current sitemap and analytics, so pages that already rank keep the traffic they earned. You approve the map before anything goes live.
Can we edit content ourselves afterwards?
Yes, content lives in files or a light admin your team can use directly. We choose the editing model during scoping, based on how often you change content and who on your team will do it. Either way, you keep access to your own site going forward.
What about our existing integrations?
Forms, bookings, payments and analytics are reconnected and tested on staging first, before the domain moves. We treat each integration as its own checklist item, because a silently broken booking form is the failure mode that matters most. Nothing goes live until every one of them has been exercised.
How long is the site down?
It is not, cutover is a domain change with the old site live until the new one answers. We build and test the new site on a staging domain for the full length of the project, so the switch itself takes minutes and carries no outage window for your visitors to notice.
A conversation first, then a written scope.
Discuss this engagement