Migration · 9 min read
What actually breaks during a website migration
A migration rarely fails dramatically. It fails as a redirect nobody mapped, a noindex tag carried over from staging, and a form that silently stopped sending — found six weeks later.
Updated 29 August 2026 · GoDesign build team
The short version
- Migration, redesign and rebuild appear in 1,180 of the 27,169 briefs we hold.
- The four things that break most are URLs, crawl directives, forms and tracking — in that order of consequence.
- The dangerous failures are silent: nothing errors, traffic just declines and nobody connects it to the launch.
- Every migration needs a pre-launch inventory of the old site, because you cannot verify what you never wrote down.
Migrations do not usually fail loudly. The site goes live, it looks better than the old one, everybody is pleased, and then over the following two months enquiries fall by a third and nobody can say why. By the time the decline is obvious enough to investigate, the launch is far enough back that it is no longer the first suspect.
This category is large — 1,180 of the 27,169 project briefs we hold involve a migration, redesign or rebuild — and the failure modes are consistent enough to list. Almost all of them are cheap to prevent and expensive to discover late.
One: URLs that changed without a redirect
This is the big one and it is entirely avoidable. Every URL on the old site that had any value — ranked, linked to, bookmarked, printed on something — needs to either keep its address or redirect to the closest equivalent with a permanent redirect.
What goes wrong is rarely the main navigation, which everybody checks. It is the long tail: old blog posts, an offer page from three years ago that still gets links, the PDF someone linked from a forum, category pages under a URL structure the new platform does not use. Those pages are where a surprising amount of a site's traffic quietly lives.
Two: crawl directives carried over from staging
New sites are built somewhere private, and the standard way to keep a staging site out of search results is a noindex tag or a robots.txt disallow. Both of those live in the code or the configuration, and both travel with the site when it is deployed unless somebody deliberately removes them.
The result is a site that is faster, better structured and better written than the one it replaced, and completely absent from search. It is the single most common cause of a rebuilt site ranking worse, and it is a five-minute check that nobody thinks to run because the site looks perfect from the outside.
Three: forms that stopped sending
Contact forms fail silently by design. The visitor sees a thank-you message because that is a front-end behaviour, and the email never arrives because the sending configuration did not come across — a different mail service, an unverified sending domain, an API key that belonged to the old host.
Nobody notices, because the failure produces no error anywhere a human looks. The business simply receives fewer enquiries and attributes it to a quiet month. Test every form after launch by actually submitting it and confirming the message arrives at the real destination — not by looking at the success message.
Four: tracking that never came across
Analytics, tag manager containers, conversion pixels and call tracking all live in the page template, and a new template means a new place for them to be absent from. This one is doubly annoying: not only do you lose the measurement, you lose the ability to detect the other three failures, because the data that would show a traffic drop is itself missing.
Check tracking first after launch, before anything else, because it is the instrument you need in order to check everything else.
The inventory is the actual work
Everything above depends on one thing being done before the switch: a written record of what the old site was. Once the old site is gone, you cannot compare against it, and the questions you will want to answer are all comparative — did this page exist, what did it rank for, where did that form go, was that tracked.
- Every URL on the old site, exported, with its traffic and its inbound links if you can get them.
- Every form, where each one sends, and who receives it.
- Every tracking script and container ID present in the old template.
- Every integration — payment, booking, CRM, email — and the credentials or accounts each depends on.
- A crawl of the old site saved to a file, so structure can be compared rather than remembered.
Taken before launch, that list is an afternoon. Taken after, it is impossible, and every question becomes a guess.
The first week after
Migration risk is highest in the first fortnight and decays quickly after that. Watch four things daily for the first week: indexed page count, 404 errors in Search Console, form submissions arriving, and organic sessions against the same week last month. A problem that shows up in any of those in week one is cheap to fix. The same problem found in month three has already cost whatever it was going to cost.
Questions people ask
What is the biggest risk in a website migration?
Unredirected URLs. Every old address with traffic, rankings or inbound links needs a permanent redirect to its closest equivalent. The failures are almost never in the main navigation, which everyone checks, but in the long tail of old posts, offer pages and files that quietly carry a large share of a site's traffic.
Why did my new website's traffic drop after launch?
Check four things in this order: whether a staging noindex tag or robots.txt disallow came across with the deployment, whether old URLs redirect properly, whether tracking is still installed, and whether forms still deliver. A staging crawl directive is the most common single cause of a better site ranking worse.
Should I redirect old pages to the homepage?
No. It preserves the link signal poorly and serves the visitor badly — someone who wanted a specific page and lands on a homepage leaves. Map each old URL to its closest real equivalent, and accept a genuine 404 where no equivalent exists rather than sending everything to one page.
What should I record before migrating a website?
Every URL with its traffic and inbound links, every form and where it sends, every tracking script and container ID, every integration and its credentials, and a saved crawl of the old site. Taken before launch this is an afternoon's work; taken afterwards it is impossible, because the thing you would compare against is gone.
How long should I monitor a site after migrating it?
Daily for the first week, then weekly for a month. Watch indexed page count, 404s in Search Console, form submissions arriving, and organic sessions against the same period last month. Risk is concentrated in the first fortnight, and a problem found then is far cheaper than the same problem found in month three.
Built by GoDesign FZE, who build WhatsApp and CRM automation for UAE businesses.
Get in touch
Want someone to just do this part?
The tool is free and stays free. If you would rather hand the work over, tell us what you are dealing with and you get a straight answer on scope, cost and timeline.
- You own everythingRepository, hosting and domain credentials sit in your name from day one, not handed over at the end.
- A written timelineMilestone dates are agreed in writing before work starts, so you always know what ships next.
- One business dayEvery enquiry gets a reply from the person who would scope the work, not a sales sequence.
Media City, Dubai, UAE · DHA Phase 2, Islamabad, Pakistan
Would rather type than fill in a form?
Message on WhatsApp