Will My Site Go Down During Migration? How to Get Zero Downtime
Most people asking this have a specific picture in mind. A site that disappeared for a day. An online store still taking orders on a server that had already been emptied. A phone that started ringing at 9am.
The worry is fair. The outcome is avoidable, and not by being lucky.
Downtime during a host migration is nearly always a scheduling mistake rather than a technical one, which is good news, because scheduling is something you control.
Short answer: Usually not. A migration done in the right order has no visible downtime, because the site is complete and working on the new server before anything points at it. Downtime happens when the order is reversed: the domain is switched first and the copying happens afterwards, with visitors arriving in between.
Will my site go down during a migration?
Not if both copies are alive at the same time. During a staged move the old site keeps serving visitors while the new one is built and tested, and when the nameservers change, people are simply routed to a second working site. There is no moment when neither exists.
The exception is content. Anything published, ordered or submitted on the old site after you took the database copy exists on one server and not the other. That is not downtime, but it does the real damage, which is why the timing of the database export matters more than anything else on the day.
What actually causes website migration downtime?
Four things, in roughly this order of frequency: changing DNS before the new site is ready, cancelling the old account too early, an SSL certificate that was never issued on the new server, and a database export taken hours before the switch. None of them are hard to avoid once you know to look.
| Cause | What visitors see | How to avoid it |
|---|---|---|
| DNS changed before the site is ready | An error page or a default host page | Copy and test first, change nameservers last |
| Old account cancelled straight away | Nothing loads for anyone still cached | Keep it running a week or two |
| No certificate on the new server | A full-screen security warning | Issue the SSL before the switch, not after |
| Stale database copy | Site loads, recent orders missing | Freeze changes, re-export at the last moment |
| Missing redirect rules | Old URLs return 404s | Copy server config across and read it |
How do you move a site with no visible downtime?
By making the switch the last thing you do, not the first. Build the complete site on the new server, view it privately using your computer’s hosts file, fix everything you find, and only when it passes do you touch DNS. Both servers are then serving the same site.
The timing runs like this.
| When | What you do | Why |
|---|---|---|
| Two days before | Lower the TTL on your DNS records to 300 seconds | Resolvers stop holding old answers for long |
| Day before | Copy files and database, issue SSL, test privately | All mistakes happen where nobody can see them |
| Switch hour | Freeze changes, re-export the database, import it | The two servers hold identical content |
| Immediately after | Change nameservers at the registrar | Traffic starts moving to a site already proven to work |
| Following two weeks | Leave the old account running | Anyone still cached lands on a working site |
The step by step walkthrough covers the mechanics behind each row, and the pre-migration checklist is what you tick off during the testing window. A managed migration follows the same timeline, with the host doing the middle three rows.
What is a content freeze, and how long does it need to be?
A content freeze is a short period where nobody publishes, edits or takes an order, so the database you copy is the final one. For a brochure site it can be minutes. For a busy store it needs planning, because every order placed during the gap has to land on the right server.
Tell whoever touches the site that it is happening, and pick an hour when traffic is genuinely low rather than one that suits your calendar. Check analytics instead of guessing. Most Australian business sites have an obvious overnight trough, and using it turns a nervous switch into a dull one. Time zones matter as well: if you have customers in Perth as well as on the east coast, the hour that is quiet for everyone is narrower than it first looks.
Do visitors see the old site or the new one while DNS updates?
Some see one, some see the other, and for a few hours that is completely normal. Each resolver holds its cached answer until the TTL expires, then asks again and gets the new address. Because both servers are running the same site, nobody can tell which one they reached.
This is the strongest reason to keep the old account paid for a fortnight. Cancel on the day and every resolver still holding the old address sends real people to a server that no longer answers. That is the exact scenario people picture when they ask whether their site will go down, and the cancellation caused it, not the migration. More on the caching in the guide to changing nameservers.
What happens to email while the domain moves?
Email follows the MX records in your DNS zone, which are separate from the website. If you move hosts and rebuild the zone without carrying those records across exactly, mail stops arriving even though the website looks perfect. Check the MX records before the switch, then again straight after.
If your mail sits with Microsoft 365, Google Workspace or another provider, nothing needs to change: the records simply have to be identical in the new zone. If your mail lives at the old web host, decide where it is going before you move the site, because mailboxes and message history are a separate job with their own risks. GoodHost’s email hosting has not launched yet, so have that conversation early.
What do you do if something does break?
Do not start editing live. Work out first whether the problem is the site or the routing: if the old server still has the previous version and the old account is still running, reverting the nameservers puts everything back the way it was while you diagnose in peace.
Then work through it in order, because each symptom points at one thing.
- A certificate warning means the SSL was not issued for that hostname.
- A blank page means database credentials or the PHP version.
- Old URLs returning 404s means the redirect rules did not travel.
- Missing mail means the MX records were not carried across.
The rest of the switching hosts guides take these one at a time.
Frequently asked questions
How long does a website migration take from start to finish?
The copying is the short part and the waiting is the long part. A small site can be copied and tested inside a day, and the TTL you set beforehand decides how quickly the switch reaches everyone. Larger sites take longer to copy and much longer to test, which is the step people compress when rushed.
Can I migrate a busy online store without losing orders?
Yes, with a short content freeze and careful timing. Copy the site, test it thoroughly, then stop the store taking orders for a brief window while you re-export the database and switch. Pick the quietest hour you have, warn staff, and confirm the last few orders exist on both servers before you finish.
What is a maintenance page and do I need one?
It is a temporary page saying the site is briefly unavailable, and it is the honest alternative to a broken one if you do need a gap. A properly staged migration should not need it. Have it ready anyway: a maintenance page you can switch on in seconds beats improvising while something is wrong.
Why does my site look fine but my colleague still sees the old one?
Because their resolver is still holding the previous answer until its TTL expires. Nothing is broken. Both sites are live and the two of you are being sent to different servers for a few hours. This is also why the old account stays running: everybody still landing there gets a working site rather than an error.
Should I migrate at night or on the weekend?
Pick the quietest hour your traffic actually has, then check people are available. Those two often conflict. A 2am switch means nobody is buying, but it also means your host and your developer are asleep. GoodHost’s phone support runs Monday to Friday, 9am to 5pm AEST, so an early weekday morning is usually the better compromise.
If the anxiety is really about being the person holding the nameserver settings at 6am, hand that part over: a managed migration means the copy, the certificate and the testing are done before you are asked to approve anything, and you pick the hour the switch actually happens.