Switching hosting providers is one of those tasks that gets postponed for months. The fear is always the same: the site going down, emails getting lost, customers landing on a blank page. The good news is that a well-planned migration is invisible to your visitors. The bad news is that an improvised one can cost you two days of sales. The difference is not technical skill, it is the order in which things are done.
This is the checklist we follow on every migration, in exactly the order it should be executed.
Two days before: preparing the ground
The first step does not touch the server, it touches DNS. Every DNS record has a TTL, a number in seconds that tells the Internet how long it may remember that record before asking again. If your TTL is 24 hours, any change can take a full day to propagate worldwide.
Lower it to 300 seconds at least 48 hours before the migration. That way, when the real switch happens, propagation completes in minutes. This step costs one click and it is what turns a multi-day migration into a matter of minutes.
The second step is an honest inventory of what you have. Files, database, mailboxes with their passwords, scheduled tasks, SSL certificates, custom DNS records, and any external integration that points at your server by IP address. That last one causes the most surprises: payment gateways, billing systems or mobile apps talking straight to an IP that is about to change.
The backup that actually works
Take a full backup and, above all, verify that it restores. A backup that has never been tested is an assumption. Restoring the database into a test environment and checking that the site boots takes twenty minutes and prevents the worst possible outcome.
The day before: build and test in parallel
Here is the trick most people do not know. You can have your site running on the new server and test it thoroughly before changing DNS, using your computer’s hosts file. Add a line with the new IP and your domain, and your browser will go to the new server while the rest of the world still sees the old one.
With that you can walk the whole site, place a test order, submit a form, check that images load and file permissions are right. All without a single customer noticing. If something breaks, you fix it calmly and without pressure.
Take the chance to review the PHP version too. Many migrations fail not because of data, but because the new server ships a newer version that breaks an old plugin. Better to find out now.
Switchover day: the short window
Pick the quietest hour, usually overnight or early Sunday. The sequence is:
- Freeze changes on the site. No publishing, no manual orders, no touching the database.
- Sync one final time whatever changed since the initial backup: mainly the database and uploaded files.
- Point DNS at the new server.
- Check from several different networks, including your phone on mobile data, that the site answers at the new location.
With the low TTL you set two days ago, this part resolves in minutes.
Email deserves its own attention
The website is the visible part, but email is what generates angry phone calls. During propagation, some messages may reach the old server and others the new one. Keep the mailboxes alive in both places for a few days, and check the old inbox before shutting it down. Never delete mailboxes on migration day.
The week after: safety net
Do not cancel the old server immediately. Keep it for at least a week, off DNS but with data intact. If a problem nobody spotted appears, you have the original at hand.
During those days review the error logs on the new server, which usually reveal misconfigured paths or wrong permissions that normal browsing never shows. Raise the TTL back to a high value once everything is stable, to ease the load on your DNS servers.
The three mistakes we have seen most often
Migrating on Friday afternoon. If anything gets complicated, it eats your weekend. The best day is Tuesday or Wednesday, with a full week ahead.
Forgetting scheduled tasks. The cron jobs that generate reports, send reminders or sync stock do not migrate themselves. This is the failure discovered three weeks later, when someone asks about a report that never arrived.
Telling nobody. Even if the migration is invisible, your team should know when it happens. If someone spots an anomaly, they need to connect it to the change instead of losing a morning investigating.
When you would rather not do it yourself
A standard migration of a website with its email is a few hours’ work for someone who does it often, and a whole weekend for someone doing it for the first time. In our web hosting plans in Andorra migration is included: we handle the entire process, parallel testing phase included, and confirm everything works before touching your DNS.
And if your worry is what would happen if something went wrong at any moment, not just during a migration, take a look at our backup services: two data centres of our own in Andorra and a real, documented restore test every year.