You've been working on this site for weeks. The code is clean, the staging is validated, the client is hot. It's time to put it into production. And then... you rush headlong into it, forgetting basic things that will cost you hours of debugging at 10pm.
At LRob, we regularly welcome sites undergoing migration - WordPress, PrestaShop, PHP of all kinds - and we always see the same mistakes coming back. Here's the checklist we wish we'd given you before.
Contents
1. DNS TTLs: you should have thought of that 48 hours ago
If you migrate to a new server, DNS propagation is not instantaneous. By default, a TTL is often 3600 seconds (1 hour), sometimes even 86400 (24h). During this time, some of your visitors will still land on the old server.
What to do 48 to 72 hours before For migration, you lower your TTL to between 60 and 300 seconds (5 minutes). That way, once you change your DNS, propagation is almost immediate all over the world.
Is it too late? It's too late. Plan your next migration.
2. SSL certificate: generate it as soon as DNS points to
It makes sense, but it's constantly being zapped: as soon as your DNS points to the new server, generate your SSL certificate immediately. Not tomorrow. Not in an hour. Now.
Why? Because HTTPS is forced. Because HTTPS is forced - so without a valid certificate on the new server, visitors land on a nice certificate error page. The kind of thing that makes you call the customer in a hurry for a problem that would have taken 30 seconds to avoid.
On our Plesk servers, it's literally three clicks with Let's Encrypt. No excuses.
3. E-mails: the silent carnage
This is the final boss. And he's vicious because it doesn't crash the site - It just crashes the e-mails, and nobody notices until the customer asks why his store hasn't sent any order confirmations for 3 days.
Checklist to be completed:
- The sender address belongs to the site domain - not to
contact@agence-du-dev.fr, not to a Gmail, not to the dev's personal address. If WooCommerce or PrestaShop sends fromnoreply@monsite.comismonsite.comwhich must be configured on the server. - SPF is up to date - the new server must be authorized to send mail on behalf of the domain. You change server = you update your SPF record. Not afterwards. Now. Find out in advance, at LRob your SPF rule must contain :
include:_spf.lrob.net. - DKIM is configured and active - if your DNS are managed by LRob, it's automatic. If your DNS are elsewhere (OVH, Cloudflare, whatever), you need to retrieve the DKIM key from Plesk, possibly generate a new selector to avoid conflicts with the old server, then manually paste the record into your DNS zone. This doesn't happen by itself.
- Where are emails managed? This is the question to ask first. Two cases:
- Emails are hosted by LRob everything is configured, nothing special to do.
- Emails are elsewhere (Outlook 365, Google Workspace, etc.): you need to configure the domain in Plesk in «Disabled for incoming mail».» («This domain can only send e-mails and only with Sendmail».»). Without this, Plesk looks for the local recipient when the site sends an e-mail to an address on the same domain - and the e-mail disappears into nothingness instead of arriving in your Outlook inbox. Classic.
To test : mail-tester.com or mxtoolbox.com. No reason not to do so before delivery.
4. Data synchronization: have you thought about what changed during the migration?
For static sites, good news: no problem. For everything else - WordPress with articles, PrestaShop with orders, any site with a moving base - there's no problem. there must have been data created on the old server while you were preparing the new one.
Two golden rules:
- Plan a final synchronization just before the DNS switch - database, uploaded files, everything.
- Switches the old site to maintenance (or suspends it altogether) during the switchover window - otherwise you run the risk of having orders placed on the old server that don't exist on the new one. This is unmanageable.
Maintenance takes two minutes. Data desynchronization takes hours to repair - if it's still fixable.
5. The hosts file: your best friend for testing before anyone else
You haven't changed the public DNS yet, but you want to test the site on the new server in real conditions? Modify your file hosts on your workstation to point the domain to the new IP.
- Windows :
C:\Windows\System32\drivers\etc\hosts - Mac/Linux :
/etc/hosts
Adds a line like :
1.2.3.4 monsite.com www.monsite.comYou access the new server with the real domain name, test the forms, the order tunnel, the redirects... in short, you validate everything under real conditions. The SSL certificate may display an alert if it hasn't yet been generated - you can usually override it to access anyway.
It's not luxury, it's the basics.
6. Logs: read them. No, really.
This is the most underrated tip on this list. Read the logs after production startup. Not in three days. In the next 30 minutes.
The logs tell you everything: PHP errors, resources not found (404 on assets), requests that timeout, WordPress plugins that choke on the new config... Problems that don't crash the site visually, but that degrade the experience or performance. They can also trigger security features at LRob that you can't find elsewhere. So test first.
On our Plesk servers, logs can be accessed directly from the interface. No need for SSH, no need for special rights. It's right there in front of you, and takes just two minutes to browse.
If you've set up an error monitoring tool (Sentry, etc.), check the dashboard as well.
In a nutshell
| # | Critical point | When |
|---|---|---|
| 1 | Lower DNS TTLs | 48-72h before |
| 2 | Generate SSL certificate | As soon as DNS points |
| 3 | Check SPF, DKIM and sender | Before the switch |
| 4 | Synchronize data + maintenance mode | During the switchover |
| 5 | Test via hosts file | Before DNS switch |
| 6 | Read logs | Within 30 minutes |
By following these 6 points, you'll avoid 90% of the post-deployment incidents we see.
And if you don't want to deal with all this yourself: at LRob, migration is included in standard hosting packages. For resellers (Web Agency offers), it is available as an option. And when it's paid for, it starts at just €120 - with options for overnight migrations, multiple mailboxes or multi-subdomains.
All the points on this checklist? We'll check them for you. 👉 Discover the LRob migration offer
Laisser un commentaire