What to check after migrating a hosting account

A migration is not over when the files have been copied or the DNS changed. Before cancelling the previous provider, you need to check that the website, data, email and external services actually work from the new hosting.

Use this list after migrating a hosting account to Hostsuar and repeat it once propagation has finished.

Confirm which server is responding

Before interpreting any test, check that the domain and its subdomains resolve to the destination:

• Authoritative DNS servers.
• A and AAAA records for the website.
• MX records for email.
• Domain with and without www.

During propagation, your computer may still see the previous provider while another user already reaches the new one. Use the DNS and IP propagation check and do not cancel the source based on a single connection.

Check the website

Do not check only the home page. Test:

• Domain with and without www.
• Inner pages and permalinks.
• The application's admin area.
• Login and password recovery.
• Contact forms.
• Search, filters and dynamic content.
• File uploads and downloads.
• Redirects and error pages.
• Shop, basket, orders and payment gateways.

Run the tests in a private window to reduce the influence of previous cookies and sessions. This does not clear the DNS cache or change the hosts file. If you edited it to preview the site, remove those entries and also check from another network.

Use the gateways' test mode to check payments and avoid triggering real charges or notifications without coordination.

Check the database and the latest changes

Check that orders, forms, comments or changes created shortly before the move appear. If recent information is missing, it may have been created at the previous provider after the first copy.

Before repeating a full import, identify which data is missing and where it was created. Overwriting the destination database can delete changes made after the migration.

Also check:

• The connection and credentials configured in the application.
• Prefixes, encoding and expected tables.
• Absolute paths that still mention the previous server.
• Database users and permissions.

Check PHP and the application

A correctly copied website can fail if the environment is different. Compare:

• PHP version.
• Required extensions.
• Memory, upload and execution limits.
• MySQL or MariaDB version.
• Scheduled tasks.
• Background processes or queues.
• Licences tied to the domain or the previous IP address.

Check the application's error log if a particular feature fails even though the home page loads.

Check scheduled tasks

Check that cron jobs have been copied and that their paths match the new server. Pay particular attention to tasks that:

• Import or export data.
• Send reminders and notifications.
• Run backups.
• Process orders, payments or subscriptions.
• Synchronise external services.

Check that tasks on the source are not still running the same charges, emails or synchronisations. Coordinate when they stop there and start on the destination.

You can review their configuration from Cron Jobs in cPanel.

Check HTTPS

Test the certificate on:

• The main domain.
• The www version.
• Subdomains in use.
• Webmail and service names, where applicable.

Our SSL checker shows, from the outside, the certificate each name serves: names covered, issuer, validity dates and whether the chain is trusted. Also confirm that the browser shows no warnings.

Check that the application redirects correctly from HTTP to HTTPS and does not load images, scripts or styles from insecure addresses.

If the domain already points to the new hosting and the certificate has not been issued, see the SSL status of domains.

Test email

Send messages in both directions with an external account and check:

• Delivery to the migrated mailboxes.
• Authenticated sending from webmail and devices.
• The website's forms and notifications.
• Folders, sent messages and older content.
• Forwarders, filters and autoresponders.
• Space available in each account.

Check that the MX, SPF, DKIM and DMARC records match the final provider. If email stays with Google Workspace or Microsoft 365, also confirm their CNAME and SRV records.

Run a final synchronisation to pick up messages delivered to the source during propagation, following the guide to migrating email without losing messages.

Check subdomains and external services

Check every item noted in the earlier inventory:

• Subdomains and addon domains.
• APIs and webhooks.
• Phone systems and telephony services.
• Google Search Console and TXT verifications.
• Payment platforms.
• CDN, storage and image services.
• Microsoft 365, Google Workspace and calendars.

An external service can stop working even though the website loads if its DNS record was not recreated in the new zone.

Keep the source until you finish

Keep the previous provider active while:

• There are resolvers still showing the old configuration.
• There are messages or data left to synchronise.
• Critical features have not been tested.
• You need a way back.

If you find a serious fault, follow the procedure for changing DNS with minimal downtime before restoring the previous records. Remember that going back also needs to propagate.

Close the migration

When every check is correct:

1. Make a final recoverable backup.
2. Confirm that no recent messages or data exist only on the source.
3. Revoke temporary users, app passwords and support access.
4. Change any regular password that you had no choice but to use.
5. Remove temporary tasks, synchronisations and test files. Check again that no local hosts entries are forcing the IP address.
6. Cancel the previous provider.
7. Keep the inventory and the date of the move for future reviews.

The migration is complete when the service works from the destination and no longer depends on content, email, DNS or access from the previous provider.