Moving hosting often seems simple: copy files, export the database, then point the domain to the new server. In reality, many issues arise after the DNS changes—websites display errors, emails stop coming in, SSL certificates are not yet active, or the PHP version on the new server is incompatible with the application.
Therefore, migration should be treated like moving a store, not just moving boxes. The old store must continue serving customers until the new store is fully ready. The same principle applies to websites: prepare the new server, conduct testing, then change the public access path.
Why does hosting migration need to be planned?
Every website has a different combination of components. WordPress requires files, databases, configurations, plugins, and sometimes specific rules in .htaccess. An online store may have ongoing transactions. Websites with domain emails also depend on DNS configurations such as MX, SPF, DKIM, and DMARC.
This means that a single checklist is not always sufficient for all websites. However, there is a general sequence that can reduce risks: inventory, preparation, copying, testing, DNS changes, and then monitoring.
1. Create an inventory before touching the server
Before purchasing a new package or deleting the old account, note what is currently running. This information serves as a map when issues arise.
- Main domain name and subdomains.
- Location of website files and their usage size.
- Database name, database version, and database size.
- PHP version, framework, CMS, or applications used.
- Domain-based email addresses and active accounts.
- Important DNS records, including A, CNAME, MX, TXT, SPF, DKIM, and DMARC.
- SSL version and how the certificate is renewed.
- Cron jobs, scheduled tasks, webhooks, API keys, and third-party integrations.
Do not rely solely on memory. Keep the results in a simple document. If using cPanel, you can check menus like Domains, Email Accounts, MySQL Databases, Cron Jobs, and Zone Editor.
2. Lower DNS TTL before migration
TTL, or time to live, determines how long a DNS resolver caches information before fetching new data. A shorter TTL can help DNS changes propagate faster, although it does not guarantee that all users will immediately see the new server.
A few days before migration, lower the TTL of the records that will be changed, such as the A or CNAME records, from a long value to a shorter one. After the migration stabilizes, the TTL can be increased again to avoid frequent DNS requests.
This is not a substitute for a migration plan. DNS resolvers and certain networks may still behave differently. However, as a preparatory step, a shorter TTL gives you room to make corrections more quickly.
3. Set up the new server without changing DNS
Build the new hosting environment first. Ensure the domain has been added to the server, but do not rush to change the nameserver or public records.
Check the following:
- PHP version and extensions required by the application.
- Memory limits, upload size, and execution time.
- Database version as well as character set and collation.
- Folder structure and file permissions.
- Web server configuration, redirects, and URL rules.
- SSL availability for the domain and subdomains.
- Disk capacity, CPU, RAM, and process limits if using shared hosting.
Differences in PHP versions often become a source of errors that are not visible during the copying process. The old application may still rely on functions that are no longer available in the new version. Conversely, copying the old environment without updates can also retain outdated configurations.
4. Copy files and databases in a safe order
Create separate backups for files and databases. Do not assume that backups from the hosting panel are sufficient until you verify that the backup files can be downloaded and opened.
For dynamic websites, the database usually continues to change. If you copy the database too early and then take a long time for testing, new data on the old server will not be included. A safer approach is to make an initial copy for testing, then create a final copy just before the switch.
At the final stage, temporarily halt activities that write data if possible. For example, enable maintenance mode for the online store or stop certain forms for a few minutes. The goal is not to take the old website offline but to avoid transactions going to two different places.
5. Test the website through a temporary address
Do not test just by opening the homepage. Access several sections that represent the website's important functions:
- Homepage, article pages, and pages with images.
- Login, logout, password reset, and admin pages.
- Contact forms or ordering processes.
- Search, pagination, filters, and URLs with parameters.
- File uploads and email submissions.
- Redirects from old URLs to new URLs.
- 404 pages and basic security rules.
If the domain has not been pointed to the new server, you can still test using a preview URL, temporary hostname, or the hosts file on your local computer. This method is useful for viewing the website as if the domain were already pointing to the new server without changing access for all visitors.
Keep in mind that local testing does not always represent actual user conditions. DNS caching, CDN, SSL, and security software configurations can produce different behaviors once the website is made public.
6. Check email before changing nameservers
Websites and emails can use the same domain, but their paths are determined by different DNS records. If you change the nameservers and forget to copy the MX records, emails may stop coming in.
Note and copy all email records. If using third-party email services, do not change MX records arbitrarily. Also check TXT records for SPF, DKIM, and DMARC as all three help the receiving server assess whether the email comes from a legitimate source.
After the DNS changes, send test emails from and to several addresses. Ensure messages are received, replies are accepted, and do not fail immediately due to authentication issues.
7. Change DNS, but do not immediately delete the old hosting
After testing is complete, make DNS changes at a time that is easiest to monitor. For business websites, avoid times with peak transactions or visits.
After that, monitor the website from several networks. Check the homepage, login, forms, transactions, emails, SSL, and error logs. Some users may still be directed to the old server while others have already seen the new server. This transition period is normal as long as the data remains consistent.
The old hosting should be retained for several days or more, depending on traffic patterns and the website's risk level. Deleting it immediately after the DNS appears to have changed can cause you to lose a comparison source when issues arise.
Short checklist after migration
- The website can be accessed via HTTPS without certificate warnings.
- HTTP to HTTPS redirects work as needed.
- Important pages do not generate 404 or 500 errors.
- Forms and emails function properly.
- The database can read and write data.
- Cron jobs and external integrations are running.
- Automatic backups are active on the new server.
- Uptime monitoring and error logs are set up.
- Important DNS records match the initial records.
What does this mean for us?
Safe hosting migration is not a race to move files as quickly as possible. The biggest risks usually arise from forgotten components: emails, cron jobs, webhooks, DNS records, or new data coming in during the process.
The most practical step is to create a one-page migration document. Write down the initial conditions, list components, the time of DNS changes, testing results, and decisions on when the old hosting can be stopped. This document may seem excessive for small websites, but it is very helpful when issues arise at inconvenient times.
If the website generates transactions, stores customer data, or is a crucial part of business operations, consider conducting a trial migration first. The new server should be considered not ready until essential functions are thoroughly tested, not just until the homepage successfully loads.
– Rio Yotto @rioyotto