Site migrations

The planning usually takes longer than the move itself. Four to eight weeks of preparation for a large site, then one carefully rehearsed night with everyone clear on their part. A smaller site compresses that considerably. What does not compress is the checking afterwards. We stay on the case for weeks after launch, because that is when the forgotten URLs surface and the cheap fixes are still cheap to make. The timeline is agreed before anything starts, and it is written down so nobody is guessing on the night. That document is what turns a scary evening into a boring one, and boring evenings are the ones that protect your revenue.

Redirect maps that cover 90% of URLs, forgotten parameter URLs and nobody watching on launch day. All three are avoidable, and all three turn up regularly. The fourth failure is the quiet one. Visibility that dips for a fortnight, panic sets in, and the new site is rolled back before it ever had a chance to settle into its new structure. Patience and measurement save more launches than heroics do, which is not the answer most teams want to hear at midnight. Almost every rescue we have done started with one of these four.

Some fluctuation after a migration is normal, even a well-planned one. The goal is to protect the pages that carry your traffic and to keep any dip shallow and brief. Anyone promising a move with literally zero impact is either lucky or not telling you what the monitoring found last time. We plan so that recovery is measured in days rather than in months, and we say what we would protect first if the plan has to be cut. The pages that pay the bills get mapped first, and the rest follows. If a dip goes deeper or longer than we planned, we treat it as a defect and chase the cause rather than waiting for it to improve on its own.

It scales with the number of URLs, the platforms involved and how much of the implementation we carry ourselves. The more useful question is what an unplanned migration costs, and for most businesses that figure is a quarter of lost organic revenue. We scope after the audit, quote it as a fixed project and tell you plainly if the move can wait until the budget is there to do it properly. Migrations are quoted as projects because the work has an end date. No open-ended retainer is needed to finish a job with a finish line.

If you can separate them, separate them. One big change is far easier to diagnose than two happening at once. When the business insists on both, we protect the SEO-critical parts first and sequence the work so any drop in visibility has an obvious cause. Changing everything at once and then guessing at the reason is how migrations quietly turn into expensive rescues. The separated kind is calmer every single time. Where both must happen together, we treat it as two projects with one launch window and two sets of checks. It costs a little more upfront and saves a great deal of guessing later.

Often they can, given a proper map and a test plan to work to. We work alongside in-house teams, writing the redirect rules, the acceptance criteria and the launch checklist, then reviewing what actually ships before it goes live. The failure is rarely the code. It is the missing inventory of URLs and the absence of anyone watching the numbers on the day. That is the part we insist on keeping. You can build the whole thing yourself and still need someone whose only job is the launch window.