"Free migration" appears on almost every hosting provider's page in Kuwait and almost none of them describe what it involves. That matters, because the difference between a migration nobody notices and a migration that takes a site offline for half a day is not skill or tooling. It is the order of four steps, one of which has to happen days before anything visibly moves. Here is the sequence, and why each step sits where it does.
Why does a website go down during a host migration?
Because DNS changes do not take effect everywhere at once. When you point a domain at a new server, resolvers around the world keep serving the old address until their cached copy expires. How long they cache it is set by the record's TTL — time to live — and a typical default is 4, 12 or 24 hours.
So during propagation some visitors reach the new server and some reach the old one, and there is no way to control which. If the old site has already been shut down or its database has been moved, everyone still resolving to it gets an error. That is the downtime, and it is not caused by the switch itself but by the cache lifetime configured long before.
Lowering the TTL is the only step that has to happen days early, and it is the one that decides whether the cutover is invisible.
What is the correct order for a website migration?
- 1
Lower the DNS TTL, days ahead
Drop it to five minutes. The change itself takes one old TTL period to reach every resolver, which is exactly why it cannot be done on cutover day. Do this before anything else, including before building the new server.
- 2
Take a full backup, and verify it opens
Files and database, before anything moves. A backup nobody has opened is an assumption; restoring it somewhere is what turns it into a fact.
- 3
Build the new server in parallel and test it on a temporary URL
The old site keeps serving visitors throughout. Nothing is offline during the largest phase of the work, because the new environment is proven before it receives any real traffic.
- 4
Switch DNS, once the new environment is verified
With a five-minute TTL, propagation is minutes rather than a day. Both servers are answering correctly for the same site, so a visitor caught mid-propagation is served either way.
- 5
Keep the old host live for 48 to 72 hours
Do not cancel the old plan on cutover day. It is the rollback, and it costs one month of hosting to keep.
The reordering that matters is the first step. Most migration guides mention TTL somewhere in the cutover section, which is too late to be useful — by then the old value is already cached everywhere.
What should you check before switching DNS?
Everything below is verifiable on the temporary URL, while the live site is still untouched. A failure found here costs nothing.
- The site loads, and so do the pages that are not the homepage
- Forms submit and the submissions arrive somewhere you can see
- The database connection works under something more than a single request
- File uploads write to a directory the new server can actually reach
- Scheduled tasks and cron jobs exist on the new server — these are the most commonly forgotten item
- Email sending works, and SPF records name the new server if it sends directly
- SSL is issued and valid for the real domain, not just the temporary one
- Redirects and rewrite rules came across intact
Two of these deserve emphasis. Cron jobs live outside the files and database, so a file-and-database copy leaves them behind entirely and nothing appears wrong until a nightly report fails to arrive. And an SSL certificate issued for the temporary URL is not a certificate for the domain, so it has to be reissued after the switch or requested in advance by other means.
When is moving hosts the wrong fix?
Often. A slow site is usually not a slow server, and moving it to a faster one is an expensive way to find that out. Before migrating, it is worth establishing what is actually slow — an unoptimised database query, an oversized image set, or a plugin doing work on every page load will all follow the site to its new home.
The genuine signals for outgrowing shared hosting are more specific: frequent 503 errors, load times that climb as traffic rises rather than staying flat, and traffic somewhere past 25,000 monthly visitors. There is also the noisy-neighbour effect, where another site on the same shared server has a traffic spike or a bad query and your site slows down with nothing changed on your end — that one is real, and it is the most common honest reason to move.
Most sites on shared hosting do not need a VPS yet. If load times are constant rather than rising with traffic, the problem is in the site and a migration will move it unchanged.