During a website migration, you should change DNS only after the new hosting environment is ready to serve the site correctly and you have verified that the application, database, mail, and SSL/TLS settings are working as expected. In most cases, the safest approach is to lower the DNS TTL in advance, test the site on the new server using a temporary URL or hosts file, and then update the DNS records during the final cutover window. This reduces downtime and helps avoid broken pages, email loss, or cache-related issues after the switch.
When to change DNS during a migration
The right time to change DNS is usually at the final cutover stage, after you have completed the migration and confirmed that the destination hosting platform is ready. If you change DNS too early, visitors may be sent to a site that is not fully synchronized yet. If you change it too late, users will continue reaching the old server and may see outdated content or experience write issues after launch.
For most managed hosting and Plesk-based migrations, the recommended sequence is:
- Prepare the new hosting account and create the destination site.
- Copy website files, database, and mail settings if needed.
- Test the site on the new server before the DNS change.
- Lower the TTL on important DNS records before go-live.
- Update DNS when you are confident the new environment is stable.
- Monitor traffic, logs, and mail delivery after the switch.
What DNS change means during a migration
Changing DNS during a migration usually means updating one or more records so that your domain starts pointing to the new hosting platform. The most common records are:
- A record for IPv4 addresses
- AAAA record for IPv6 addresses
- CNAME record for subdomains that point to another hostname
- MX record for email routing
- TXT records for SPF, DKIM, DMARC, verification, and other services
In a website migration, the main change is often the A record for the root domain and possibly www. However, DNS is broader than just web traffic. If your site also uses email or third-party verification services, those records must be checked as part of the cutover.
Best time to lower TTL before the DNS switch
TTL, or Time To Live, controls how long DNS responses are cached by resolvers and clients. If TTL is high, the DNS change may take longer to propagate. If TTL is reduced in advance, the final switch becomes faster and more predictable.
A practical rule is to lower TTL 24 to 48 hours before migration. Common values during the pre-migration phase are:
- 300 seconds
- 600 seconds
- 900 seconds
Lowering TTL shortly before the cutover helps when you need a faster rollback or when you want users to start reaching the new server sooner. Keep in mind that some resolvers may still cache older values until the previous TTL expires, so DNS propagation is never fully instant.
How to decide whether the site is ready for DNS change
You should change DNS only after the following checks are complete. These checks help avoid common migration problems that can affect a live site.
1. Website files are fully copied
Make sure the latest version of the website files is present on the new server. This includes themes, plugins, media files, uploads, application code, and any custom configuration files. Missing files can cause broken layouts, 404 errors, or unavailable features after the switch.
2. Database content is synchronized
If the site uses a database, confirm that it is copied and up to date. For dynamic sites, content may change during the migration window, so you should perform a final database sync before pointing DNS to the new host. This is especially important for ecommerce, membership portals, booking systems, and websites with active user submissions.
3. Application settings are correct
Check PHP version, extension availability, file permissions, caching settings, and any environment variables required by the application. In a Plesk environment, also verify the domain subscription, hosting type, document root, and PHP handler. A site can appear migrated but still fail if the runtime configuration does not match the old server.
4. SSL/TLS is installed and valid
Before changing DNS, install or renew the SSL certificate on the new server. Confirm that HTTPS works without warnings. If visitors land on the new host before the certificate is ready, they may see security errors or redirects that break the user experience.
5. Email routing is planned
If the domain uses mail services, decide whether email will stay on the old platform temporarily or move together with the website. Do not assume that web migration automatically moves email. Check MX records, mailboxes, aliases, and DNS authentication records to avoid lost messages or delivery failures.
6. The site is tested on the new server
Use a temporary URL, preview link, or local hosts file override to test the site on the new hosting platform without changing DNS yet. Verify:
- Homepage and key pages load correctly
- Forms submit successfully
- Login and checkout flows work
- Images and media files display properly
- Canonical URLs, redirects, and caching behave as expected
Recommended DNS switch workflow
The safest approach is to treat DNS change as the final step in a controlled go-live process. The exact procedure may vary by hosting stack, but the following workflow is widely used in managed hosting environments.
Step 1: Inventory the current DNS zone
Document the existing DNS records before making any changes. Include the root domain, www, mail-related records, subdomains, verification TXT records, and any custom entries used by SaaS services. This gives you a clean reference and makes rollback easier if needed.
Step 2: Reduce TTL in advance
Lower the TTL for the records that will change. If you manage DNS through a control panel, update the TTL values in the zone editor and wait for the old TTL to expire before proceeding. This improves the speed of the eventual cutover.
Step 3: Prepare the new hosting environment
On the destination server, confirm the site is configured correctly. In Plesk, this may include:
- Adding the domain or subscription
- Assigning the correct PHP version
- Importing the database
- Installing SSL/TLS
- Checking file ownership and permissions
- Setting the proper document root
Step 4: Test without changing DNS
Before the public switch, test the site on the new server using a hosts file entry or a temporary hostname. This helps confirm that the migrated site behaves correctly in the new environment and allows you to catch issues early.
Step 5: Make the DNS update
When testing is complete, update the necessary records. Usually this means changing the A record for the apex domain and perhaps the CNAME or A record for www. If email is also moving, update MX and related TXT records only after confirming the mail service is ready.
Step 6: Monitor propagation and traffic
After the DNS change, some visitors may still reach the old server while others start seeing the new one. This is normal during propagation. Keep both environments available for a short overlap period if possible, especially for sites with active users or ongoing transactions.
How to avoid downtime during DNS propagation
DNS propagation is one of the main reasons migrations feel risky. You can reduce the impact by planning for the overlap period and by avoiding content changes during the final sync window.
- Freeze content on the old site shortly before cutover if the site is highly dynamic.
- Run a final database sync just before the DNS update.
- Keep the old server online long enough for cached DNS to expire.
- Use a maintenance message only if the site cannot safely handle writes on two servers.
- Check redirect rules so users are not looped between old and new endpoints.
For ecommerce or membership sites, even a short inconsistency between servers can affect orders, sessions, or profile updates. In those cases, plan the cutover during a low-traffic window and make sure the migration strategy includes either a final sync or a brief write freeze.
What to check after the DNS change
Once the DNS records point to the new platform, do not assume the migration is complete. Use a post-cutover checklist to verify that the site is working from the user’s perspective.
Web checks
- Open the domain in a browser using HTTPS
- Check the homepage, category pages, and key landing pages
- Verify the correct version of the site is displayed
- Look for mixed content warnings or certificate issues
- Test forms, search, login, and checkout
DNS and network checks
- Confirm the domain resolves to the expected IP address
- Check both root domain and www
- Inspect subdomains used by apps, APIs, or mail
- Validate TXT records for SPF, DKIM, and DMARC
Server-side checks
- Review web server and application logs for errors
- Confirm PHP, Apache, or proxy settings are correct
- Check resource usage on the new host
- Verify backups are enabled and scheduled
Email checks
- Send and receive test emails
- Check spam folder placement
- Verify MX records if mail moved with the site
- Confirm autoresponders and mailbox rules still work
Common mistakes when changing DNS during migration
Several issues come up repeatedly during site moves. Knowing them in advance can save time and prevent emergency rollback.
Changing DNS before the new site is tested
This is one of the most common mistakes. If DNS is updated before validation, users may reach a partially configured site and see errors immediately.
Forgetting to lower TTL
If TTL remains high, the switch can take much longer than expected. This can create a false impression that the migration failed when in reality caches are simply still holding old values.
Overlooking mail records
Website DNS and email DNS are often managed together, but they may not move at the same time. A wrong MX, SPF, or DKIM setup can interrupt mail delivery even when the site itself is working.
Missing subdomains
Subdomains such as shop, api, staging, or mail are sometimes forgotten. Make sure every active hostname is included in the migration plan.
Not keeping the old host active long enough
Because propagation happens gradually, some users may still be served by the old IP for hours. If the old server is shut down too quickly, those users may encounter failed requests or missing updates.
DNS change timing examples
Here are a few practical scenarios to help decide when DNS should be changed.
Small brochure website
For a simple static or lightly dynamic website, you can usually test the new server, lower TTL a day in advance, and switch DNS during a low-traffic period. The overlap requirement is usually short.
WordPress site with regular content updates
For a WordPress site, change DNS after files and database are copied and a final content sync is completed. If editors continue publishing content, plan a short write freeze before the cutover.
Ecommerce store
For an online store, do not change DNS until you have tested product pages, cart flow, payment steps, and order processing. Consider scheduling the switch during a quiet period and keep the old environment available until you are sure no pending orders are left behind.
Site with separate email hosting
If email stays on a different service, only the web-related DNS records should change. Keep MX and related TXT records pointed to the mail provider so email continues without interruption.
How Plesk and managed hosting help during live cutover
In a managed hosting environment, the control panel can simplify many steps of the migration. With Plesk, for example, you can manage DNS zone records, SSL certificates, PHP settings, and domain configuration in one place. This reduces the chance of a missing record or mismatched setting during go-live.
Managed hosting also helps with:
- Fast provisioning of the destination domain
- Consistent PHP and Apache/Nginx settings
- Backup and restore options before the switch
- Support for DNS updates and post-migration checks
Even with managed tools, the core principle remains the same: verify the destination first, change DNS last, and monitor closely after the switch.
FAQ
Should I change DNS before or after moving the website files?
After. First move and test the website files, database, and server configuration on the new host. Change DNS only when the new environment is ready for live traffic.
How long before migration should I lower TTL?
Usually 24 to 48 hours before the final cutover. This gives old DNS caches time to expire and makes the switch faster.
Will DNS change happen instantly?
No. Some visitors will see the new server quickly, but others may continue using cached DNS data for a while. The exact timing depends on TTL, resolver caching, and local network behavior.
Do I need to change MX records when moving a website?
Only if email is also moving. If your mail service stays on the existing provider, leave MX and related DNS records unchanged.
Can I test the new site without changing DNS?
Yes. You can use a hosts file override, temporary hostname, or preview URL to test the new server privately before the public DNS switch.
What should I do if the site breaks after DNS change?
Check whether the issue is caused by propagation, wrong DNS records, missing SSL, or configuration differences on the new host. If needed, you can temporarily roll back the DNS record to the old server while you fix the problem.
Conclusion
You should change DNS during a migration only after the new hosting environment has been fully tested and is ready to handle live traffic. The best practice is to lower TTL in advance, complete a final content sync, verify web and email services, and then update the DNS records during the cutover window. With a careful plan and post-switch checks, you can reduce downtime, avoid lost data, and make the migration much smoother for users across Europe.