Moving a website to a new hosting provider can sound risky, especially when the site is generating orders, leads or email every day. The process becomes much safer when you separate copying the website from changing DNS. This guide presents a practical migration workflow that lets you prepare the new server, test the site and switch traffic only when you are confident that everything is ready.
Plan the migration first
List everything that must move: website files, databases, email accounts, cron jobs, SSL certificates, DNS records, scheduled tasks, redirects and third-party integrations. Create a checklist before touching the live site.
Check the current environment as well as the new one. Confirm PHP versions, database versions, storage requirements, control-panel access and application compatibility. A migration is easier when you know exactly what is changing.
Lower DNS TTL in advance
If you control DNS, lowering the TTL before the migration can help changes propagate more quickly later. TTL is not an instant-switch guarantee because resolvers may cache records differently, but planning ahead can reduce the window of mixed traffic.
Do this well before the final cutover. Avoid changing multiple unrelated DNS records during the same window because it makes troubleshooting harder.
Create the new hosting account
Set up the new service and make sure the domain can be added without changing public DNS yet. Create the database, database user, email accounts and required application settings.
Install the correct PHP version and required extensions. If the website uses WordPress, check its PHP compatibility and ensure file permissions are sensible. Keep the new environment private or protected while you test it.
Copy files and database
Transfer the website files using a secure method. Export the database and import it into the new server, then update the application configuration with the new database credentials.
For larger sites, use a repeatable transfer method instead of manually uploading hundreds of files. Verify file counts and compare important directories after the transfer.
Test before changing DNS
Use a temporary hostname, hosts-file override or staging URL to test the new server. Check the homepage, forms, login, admin area, images, CSS, JavaScript, database content and important conversion paths.
For stores, test the cart, checkout, payment callbacks and order creation. For email-heavy sites, verify SMTP configuration and DNS requirements. A migration is not complete just because the homepage opens.
Plan the final data sync
If the site receives new orders, comments, registrations or uploads during the migration, the copy can become outdated. Perform a final database or file sync close to cutover, or temporarily put the application into maintenance mode during the final step if the business can tolerate it.
The goal is to avoid losing changes that occurred after the initial copy. For very busy applications, a more advanced migration strategy may be required.
Switch DNS carefully
When testing is complete, update the required DNS records or nameservers. Change only what is necessary. Keep the old hosting account active while DNS changes propagate.
Do not cancel the old service immediately. Some visitors may continue reaching the old server for a period. Monitoring both environments during the transition gives you a safety net.
Verify after cutover
Test from multiple networks and devices. Check HTTPS, redirects, images, forms, database writes, email sending and any API integrations. Watch server logs for errors and compare traffic with your normal pattern.
If you see an issue, identify whether it is DNS, SSL, application configuration or a missing file. Because the old host is still available, you can make a controlled rollback decision rather than reacting under pressure.
Move email with extra care
Website migration and email migration are related but not identical. If email is hosted separately, you may not need to move mailboxes at all. If email is moving, copy the mail data and recreate DNS records carefully.
Keep MX records correct and verify SPF, DKIM and DMARC after the change. Test both incoming and outgoing messages before announcing the migration complete.
Close the old server only after stability
Wait until the new environment has remained stable and you are confident that DNS has settled. Keep a final backup of the old environment before closing it.
Document the new server credentials, DNS configuration, backup schedule and renewal information. A clean migration ends with documentation so the next administrator can understand the setup without guessing.
Prepare a rollback plan
Before DNS cutover, decide what you will do if a critical problem appears. Keep the old hosting account available and record the original DNS values.
A rollback should be a controlled decision, not a panic reaction. If the new server has an application problem, you can temporarily return traffic while fixing the root cause.
Check third-party integrations
Payment gateways, analytics, email providers, webhooks and external APIs may restrict requests by domain or IP address. Update allowlists and callback URLs before the final switch.
For security-sensitive integrations, confirm that HTTPS is working and that secrets are stored correctly on the new server. A website can look perfect while a background webhook silently fails.
Verify cron jobs and scheduled tasks
Some applications rely on cron jobs for emails, backups, subscription renewals, queue processing and reports. These tasks do not always become obvious when you test the homepage.
List scheduled jobs from the old environment and recreate them on the new server. Then trigger or monitor a safe test so you know the job is actually running.
Document the finished migration
After the move, write down the new server, DNS setup, PHP version, database name, backup schedule and important integrations. Store this documentation somewhere secure and accessible to the team.
A migration is an opportunity to clean up old credentials and remove services that are no longer needed. Finish by rotating temporary passwords and confirming that the new environment is the single source of truth.
Check SSL and redirects
After DNS points to the new server, verify the certificate for the exact domain and common subdomains. Test HTTP-to-HTTPS redirects, www versus non-www behavior and important legacy URLs.
Redirect rules can accidentally create loops or send visitors to the wrong host. Test a selection of old URLs and confirm that search-engine-friendly redirects remain intact.
Watch server resources after launch
The new server may behave differently once real traffic arrives. Monitor CPU, memory, storage, database load and error logs during the first hours and days.
A test with one browser does not reproduce production traffic. Real visitors can reveal cache misses, resource limits or application code paths that were not triggered during testing.
Confirm backups on the new host
Do not assume the new hosting account has inherited the old backup schedule. Configure backups explicitly and confirm where they are stored and how restoration works.
Run a small restoration test if possible. Knowing the recovery process before an incident is much safer than discovering it while the site is already unavailable.
Clean up the old environment
Once the migration is stable, remove temporary accounts, migration files and old credentials. Keep a final archive if required for business or compliance reasons.
Only cancel the old service after you are satisfied that DNS has settled, email works, integrations are healthy and the new backup process is running.
Quick questions to ask before you act
Before making a change, ask what could be affected, whether you have a current backup, how you will test the result and how you will reverse the change if something goes wrong. This small habit makes technical work calmer and more predictable. Keep notes of important settings, renewal dates, credentials locations and successful procedures so the next update is easier than the last one.
Good hosting management is not about making every setting complicated. It is about understanding the few decisions that have the biggest effect on reliability, performance and security, then applying them consistently.