How to Migrate a Website Without Downtime
Downtime is the thing clients ask about and it is rarely the thing that hurts them. A site briefly unavailable is visible, alarming and largely recoverable. A site that goes live telling crawlers to stay away is none of those things. It looks completely normal to everybody who checks it.
Downtime Is The Fear, Not The Risk
Every migration conversation includes somebody asking how long the site will be down. It is a fair question and it is almost never the question that decides the outcome.
Why it dominates the conversation. It is the only failure people can picture.
A site being unavailable is easy to imagine, easy to explain to a board and easy to be blamed for. Everything else in this subject is abstract by comparison, so this absorbs the available worry.
What makes it recoverable. It announces itself.
Somebody notices within minutes, because customers report it and everybody internally can see it. A problem discovered immediately gets fixed immediately, which is the definition of a manageable failure.
What the damaging failures have in common. Silence.
They produce no error, no complaint and nothing visible. Nobody reports them, because from every angle a person can look at, the site is working perfectly.
What this page does. Answers the question, then reorders the worry.
Blocks two to five cover interruption properly, because it is a real consideration. Block eight explains what should have been worrying you instead.
What Actually Happens During A Short Outage
A site that is temporarily unavailable, saying so correctly, is understood as temporarily unavailable. The response the server gives is what communicates that. It is the part that matters.
The distinction that does the work. Gone against back shortly.
A server can answer in a way that means this no longer exists, else in a way that means this is unavailable right now and will return. Those are different statements with different consequences. Only one is appropriate during planned work.
Why the wrong answer is worse than the outage. It says something untrue.
A site answering as though its pages have ceased to exist is making a permanent claim during a temporary situation. That is a considerably larger problem than being unreachable for a while.
What we will not tell you. A safe period.
There is no duration we can state after which harm begins, because it depends on the site, how often it is visited and what is happening at the time. Anybody offering you a threshold is inventing one.
What to ask instead. One question for whoever runs the server.
What the site will answer with while the work is happening. If they can describe it clearly, that is a good sign in itself.
Planning For Minimal Interruption
Three decisions reduce interruption more than any technical arrangement does. None is about hosting. All are agreed before launch day.
Have the new environment fully ready first. Complete, not nearly.
The switch should be the last thing that happens rather than the start of a period of finishing off. A site being completed after it goes live is the most common cause of a long, messy launch.
Test before switching, not after. On the real build.
Everything checkable in advance should have been checked in advance. What remains for launch day is confirming the switch itself worked, which is a short list rather than a project.
Switch when it costs least. Per the timing guidance.
The quietest period for that business, with people available. Both halves matter. The second is the one most projects get backwards.
What we will not cover. How any of it is arranged.
Hosting and domain configuration belong to whoever provides them. The planning framework sits in how to plan a site migration.
The Switch Is Not Instant For Everybody
When a domain moves, the change spreads outward over a period rather than happening everywhere at once. During that window some visitors reach the old site and some reach the new one.
Why it works that way. The answer is held in many places.
Information about where a domain points is stored across the internet rather than in one location, with each copy updating on its own schedule. Nobody controls that centrally, which is why the switch cannot be instantaneous.
What that means during a launch. Two versions are live.
For a period, both the old site and the new one are being served to real people. Both are correct behaviour and neither is a fault.
Why it affects testing. You may be checking the wrong one.
Somebody testing during the window may reach the old site and conclude the launch failed, else reach the new one and conclude everything is fine everywhere. Both conclusions are unreliable until the window has passed.
What follows practically. Confirm which you are seeing.
Before reporting a problem or declaring success, establish which version you actually reached. That single check prevents most launch day confusion.
Keep The Old Environment Alive
Shutting the old site down on launch day removes the ability to check anything against it. It is the last thing that should happen and it is routinely one of the first.
Why it gets switched off quickly. Tidiness and cost.
The old hosting is an expense with no apparent purpose. Cancelling it feels like completing the project. Somebody closes the account within days, entirely reasonably.
What that costs you. The comparison.
Every diagnostic question afterwards involves the old site. Did this page say more before. Did this section exist. Was this already broken. All of them become unanswerable at once.
What it also removes. Any reversal.
Whatever limited ability existed to go back disappears with the environment, which is worth understanding before somebody cancels anything.
What to do instead. Keep it, quietly.
Retain it, unreachable to the public, until the site has settled. The record you should also have taken beforehand is in site audit before migration.
Ecommerce Has A Harder Problem
A store cannot simply pause. Orders, baskets and customer accounts are live state that exists in one system and has to end up in another, which makes the switch considerably harder than for a content site.
What makes it different. Things are in progress.
At any moment somebody has items in a basket, an order is being processed and somebody is logged in. A content site has no equivalent. Nobody is halfway through reading an article in a way that breaks.
What that does to the window. It narrows sharply.
The quiet trading period matters far more here, because the cost of interruption is measurable in a way it is not for a brochure site. Every hour has a number attached to it.
What has to be decided in advance. What happens to in-flight activity.
Orders placed during the switch, baskets that were open and accounts that existed on the old system. These are commercial decisions rather than technical ones and they belong in the plan.
Where the store-specific material sits. Its own clusters.
Our ecommerce material covers the trading side of a replatform. The migration mechanics for stores are covered separately in this cluster.
What To Watch In The First Hours
Four things. The order matters, because the second is the one that cannot wait.
Is the site reachable. The obvious one.
Answered quickly and usually by somebody else before you check, since visible failures report themselves.
What is it telling crawlers. The one that matters most.
Whether access is blocked and whether the site is asking not to be indexed. Both are checked in seconds and both are catastrophic if wrong, which is why this outranks everything else on the list.
Are the redirects behaving. Against the map.
On the live site rather than the staging one, because environments differ.
Is anything critical broken. The functional sweep.
Forms, checkout, search and contact routes. The full treatment of the crawler question is in crawling and indexing during a site migration.
The Failure That Looks Like Nothing
A site can be up, fast, beautiful and entirely invisible to search. That is the failure worth planning against. It is the exact opposite of the one everybody prepares for.
What it looks like from inside. A successful launch.
The site loads. The design is better. Nothing is broken. Everybody involved is pleased, the project is signed off and attention moves elsewhere, because there is nothing to investigate.
What is actually happening. An instruction, left in place.
Something added during the build to keep the unfinished site private is still there. It is one line, it travelled with the build and nobody removed it.
How long it can persist. Until somebody notices the numbers.
Weeks, typically, because the only symptom is a decline in performance and declines after a migration are expected. The thing that would prompt investigation is the thing everybody was told was normal.
Why this is the whole argument. Effort follows fear.
A project terrified of downtime and unbothered by this has allocated its attention exactly backwards. What to watch afterwards is in monitoring after migration. The full series is on the website migration guide.
Up, fast,
beautiful,
invisible.
The new environment finished before the switch rather than after it, what the server answers with agreed in advance, the old environment kept until things settle because every later question needs it, the crawler check done within the hour, with attention allocated to the failure that produces no symptom.
What a migration engagement covers:
A migration is a one-off project rather than a monthly service, so it is scoped and quoted against the size of the site and how much is changing at once.
Every guide.
One practice.
What a migration is, the types, when to do it, planning, the checklist, auditing, mapping, redirects, internal links, tags, downtime, crawling, structured data, performance, notifying, monitoring, recovery and the mistakes.
