Migration & Rebuild
Years of content by different writers, a sitemap that drifted, and a platform nobody chose on purpose. Bring the mess. Keep what is worth keeping. Rebuild the rest properly.
Keep the traffic. Lose the debt.
Most of a rebuild is deciding what not to keep
The expensive part of an old site is rarely the code. It is the four hundred pages nobody has read since 2019, the three competing versions of the same explanation, and the navigation that grew by accretion. That gets inventoried and cut before a single screen is designed, because rebuilding the confusion faithfully is the one outcome worth avoiding.
Deliverables
- Content inventory of the existing site, page by page
- UX and technical audit naming what is broken and why
- An explicit kill list, with the reasoning for each removal
- Information architecture for the rebuilt site
- A rebuilt front end you own outright, with no platform lock-in
- Redirect map from every retired URL, so nothing 404s
- Handover of domain, repository and hosting in your name
Audit, inventory, kill list, rebuild
In that order, and the third step is the one that saves the money.
- 01Audit. What the current site does, what it costs to run, where it loses people, and which of its problems are structural rather than cosmetic.
- 02Content inventory. Every page listed with its traffic, its purpose and its owner. Usually the first time anyone has seen the whole thing at once.
- 03Kill list. What goes, what merges, what stays, and the reasoning for each. You approve it before anything is removed.
- 04Rebuild. A front end built on what survived, with redirects from every retired URL and the accounts in your name.
Common questions
No, and that is a deliberate boundary rather than a shortage of skill. Inherited code carries decisions nobody can explain, dependencies nobody has audited, and defects that become yours the moment you touch them. What comes across instead is your content, your traffic and your URLs. Bring the mess. Keep what is worth keeping. The rest gets rebuilt properly, on a stack you own.
Nothing is deleted quietly. The content inventory lists every page with its traffic, its purpose and a recommendation, and the kill list records why each removal was proposed. You approve it before anything goes. Every retired URL gets a redirect to its closest living equivalent, so the search ranking you already earned moves with you instead of evaporating.
That is what the redirect map is for. Rankings attach to URLs, so the risk in any migration is retired addresses returning a 404 and the accumulated authority going with them. The map is built before launch, tested against the old sitemap, and checked again afterwards. Titles, descriptions and structured data are carried across or improved, never dropped.
Both work. A staged migration moves a section at a time, which suits large sites and teams that need to keep publishing throughout. A single switch is cheaper and faster, and suits sites under roughly forty pages. The audit says which one your site is, and the recommendation comes with the reasoning rather than a preference.
Then you get told that, and the engagement stops at the audit. It happens. A site that loads quickly, converts adequately and is not fighting its own structure does not need replacing, and selling you a rebuild anyway would cost more credibility than the project is worth. You keep the inventory and the audit, which are useful on their own.
The engagement
The same four steps apply to every service. There is no hourly billing and no open-ended scope.
- 01You reach out with the problem, not the solution. A brief description of what is not working is more useful than a specification.
- 02A 30-minute discovery call covers goals, constraints and timelines.
- 03A fixed-price, line-item proposal follows within 48 hours. Every line is something you can question or remove.
- 04A deposit starts the work, and the schedule is agreed in writing before anything begins.