Producing: the 6 critical points you've (still) forgotten

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.

---

1. DNS TTLs: you should have thought of that 48 hours ago

If you migrate to a new server, DNS propagation doesn't happen instantly. By default, a TTL is often 3600 seconds (1 hour), sometimes even 86400 (24 hours). During this time, some of your visitors will still land on the old server.

What you need to do 48 to 72 hours before At migration, you lower your TTL to between 60 and 300 seconds (5 minutes). That way, once you change your DNS, propagation is almost immediate throughout the world.

Is it too late? It is too late. Plan your next migration.

---

2. The SSL certificate: generate it as soon as the 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 are presented with a nice certificate error page. The kind of thing that makes you call the customer urgently 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. Email: the silent carnage

This is the final boss. And he's vicious because it doesn't crash the site - It just crashes the emails, and nobody notices until the customer asks why their shop hasn't sent any order confirmations for 3 days.

Checklist to be completed:

• The sender address belongs to the domain of the site - not to contact@agence-du-dev.fr, not to a Gmail, not to the dev's personal address. If WooCommerce or PrestaShop sends from noreply@monsite.com, is monsite.com which must be configured on the server.
• The SPF is up to date - the new server must be authorised 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 first question to ask. Two cases:
  • Emails are hosted by LRob everything is configured, nothing special needs to be done.
  • 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 emails and only with Sendmail».»). Without this, Plesk looks for the recipient locally when the site sends an email to an address in the same domain - and the email 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 synchronisation: 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:

1. Plan a final synchronisation just before the DNS switch - database, uploaded files, everything.
2. Switches the old site to maintenance (or suspends it altogether) during the switchover window - otherwise you risk having orders placed on the old server that don't exist on the new one. It's unmanageable.

Maintenance takes two minutes to set up. Data out of sync takes hours to fix - if it can be fixed.

---

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.com

You access the new server with the real domain name, you test the forms, the order tunnel, the redirects... in short, you validate everything in real conditions. The SSL certificate may display an alert if it hasn't been generated yet - 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 start-up. 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 won'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-72 hours before
2	Generate the SSL certificate	As soon as DNS points to
3	Check SPF, DKIM and the sender	Before the switch
4	Synchronise data + maintenance mode	During the switchover
5	Test via the hosts file	Before the DNS switch
6	Read the logs	Within 30 minutes of

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 night-time migrations, multiple mailboxes or multi-subdomains.

All the points on this checklist? We'll check them for you. 👉 Discover the LRob migration offer