Moving to faster NVMe hosting is a good opportunity to clean up an old website, but migration and optimisation should not be mixed into one unrepeatable experiment. First reproduce the working site. Then improve it. That order makes problems easier to understand.
Before you touch DNS, make an inventory
List the domain, DNS provider, files, databases, email accounts, scheduled tasks, SSL certificate, redirects and third-party integrations. Include less obvious items such as payment callbacks, form delivery and licence restrictions tied to an IP address.
Record the current software versions. A migration from an old PHP or database version may need application changes. Discovering that during the cutover is avoidable.
Create backups you can actually open
Take a complete file and database backup, then inspect it. Confirm the archive contains recent uploads and that the database export is not empty. Store a copy somewhere independent from both the old and new hosts.
If email is part of the same hosting account, back it up or plan a separate mailbox migration. Websites often move successfully while an overlooked mailbox loses history.
Lower DNS TTL ahead of time
DNS records are cached. Lowering the time-to-live a day or two before the move allows clients to learn the new address sooner. This does not eliminate propagation, but it reduces the period in which visitors may reach different servers.
Build and test the new copy privately
Transfer the files and database without changing public DNS. Use a temporary hostname or local hosts-file entry to test the real domain against the new server. Browse important pages and complete actual workflows.
- Submit every contact and checkout form.
- Log in as an administrator and ordinary user.
- Check images, downloads and redirects.
- Run scheduled jobs manually where possible.
- Inspect browser and server error logs.
- Test from mobile as well as desktop.
Synchronise dynamic data
A brochure site can often be copied once. A shop, forum or booking system changes continuously. Plan a short content freeze, maintenance window or final database synchronisation so new orders and messages are not left on the old host.
Communicate the window to people who publish content. A quiet migration can fail because one colleague updates a page on the old server after the final copy.
Switch DNS and watch both sides
Update only the records that need to change. Keep the old server online while DNS propagates and monitor logs on both environments. Verify HTTPS, form delivery and external callbacks from a normal internet connection.
Do not cancel the previous service immediately. A few days of overlap buys time to find low-frequency jobs and gives you a straightforward rollback path.
Measure the result
Compare the same pages and transactions you measured before. NVMe can improve database and file operations, but caching, image size and application code still influence page speed. Use the migration as a baseline for the next optimisation, not as proof that every problem is solved.
A rollback plan is part of the plan
Decide in advance what failure would trigger a return to the old host, who makes the decision and how DNS will be restored. Rollback is not defeat; it is a controlled response that protects customers while you diagnose the issue.
If you would rather have help with the move, the NetCloud24 team can help assess the target environment and plan a supported migration to modern infrastructure.
← Back to all articles