Verifying a Migration

Run through this checklist after a migration completes and before updating DNS records. Verifying everything works on the new server before cutting over means customers experience zero downtime and you have a clear rollback path if something is wrong.

Test before DNS cutover using /etc/hosts#

You can test the migrated site on the new server without touching DNS by overriding name resolution locally on your machine:

Linux / macOS — edit /etc/hosts:

# Add this line, using the Opterius server's IP
203.0.113.10    domain.com www.domain.com

Windows — edit C:\Windows\System32\drivers\etc\hosts as Administrator:

203.0.113.10    domain.com www.domain.com

With this in place, your browser sends requests for domain.com directly to the new server. Remove the line when you are done testing.

Verification checklist#

Website#

• Site loads over HTTP and HTTPS — open https://domain.com in the browser with the hosts file override active. Confirm the site displays correctly.
• No mixed content warnings — check browser console for insecure resource errors.
• Admin login works — log in to WordPress, the CMS, or the application backend.
• Key pages load — check a few representative pages, not just the homepage.

Database connections#

• Application connects to the database — if the site uses WordPress or a similar CMS, a working site confirms the DB connection works.

• Check regenerated credentials — database passwords were regenerated during migration. Confirm the application config file has the new password:

  WordPress:

  grep DB_PASSWORD /home/username/domain.com/public_html/wp-config.php
  

  The correct password is shown in Server Mode → Accounts → [account] → Databases.

• No database errors in logs — check /home/username/logs/ or the application's own error log.

Email#

• Sending works — send a test email from the account's mailbox to an external address (Gmail, etc.).

• Receiving works — send an email to the account's mailbox from an external address and confirm it arrives.

• MX records are correct — confirm MX records point to the new server (or are unchanged if you manage your own DNS):

  dig MX domain.com +short
  

• Email client connects — test IMAP/SMTP from a mail client using the new server credentials.

DNS#

• DNS zone exists — Server Mode → DNS → Zones → confirm the zone is present and all records look correct.

• A record points to new server IP:

  dig A domain.com +short
  

  Note: DNS changes propagate — this check is only relevant after you have updated nameservers or the zone's A record.

• No stale old-server IPs — the importer rewrites IP addresses in the zone to the new server's IP. Verify there are no remaining references to the old server's IP:

  dig ANY domain.com +short
  

SSL#

• HTTPS works and certificate is valid — browser shows a padlock with no warnings.

• Certificate expiry is acceptable — if the imported cert expires within 30 days, issue a new Let's Encrypt cert now rather than waiting for auto-renewal:

  Server Mode → Accounts → [account] → SSL → Issue Let's Encrypt Certificate.

Cron jobs#

• Cron jobs present:

  crontab -l -u username
  

• Paths are correct — if the username changed during migration, verify the rewritten paths point to locations that exist on the new server.

• Schedule looks right — confirm timing matches what was set on the cPanel server.

File permissions#

• No permission errors — if the site returns file permission errors (403 or PHP fatal errors about unreadable files):

  ls -la /home/username/domain.com/public_html/
  

  Files should be owned by the account user. The agent resets ownership after restore. If ownership is wrong, fix with:

  chown -R username:username /home/username/
  

Cutting over DNS#

Once all checks pass:

1. Update nameservers at the domain registrar to point to the new server (see Pointing Nameservers), or update the A record if you are keeping the same nameservers.
2. Remove the /etc/hosts override on your test machine.
3. Wait for TTL expiry. If you lowered the TTL before migration (recommended: set to 300s a day ahead), propagation is fast.
4. Test again from a machine that is NOT using the hosts file override to confirm live DNS resolves correctly.

[!TIP] Leave the old cPanel account intact for at least 7 days after cutover. Do not delete it until you are certain everything is working on the new server and no email was lost in transit.