If you are planning a Java migration, the best time to change DNS is usually after your new Tomcat or Java application has been fully tested on the target hosting platform, but before you need all visitors to use the new environment. In practice, that means lowering the DNS TTL in advance, preparing the new My App Server instance in Plesk, and switching the domain only when you are confident the application, database, and HTTPS configuration are ready.
For UK websites, the goal is simple: minimise downtime, avoid broken sessions, and make sure the new Java stack is live when DNS starts sending traffic to it. If your application is running on an Apache Tomcat setup with a private JVM in a shared hosting account, the migration is usually smoother than a full server move, but DNS timing still matters.
When should you change DNS during a Java migration?
The safest answer is: change DNS at cutover time, not during development. More specifically, update DNS only after the following are in place:
- the new Java application is deployed and accessible on the target hosting account;
- Tomcat or the private JVM is running correctly in My App Server;
- database connections are confirmed;
- SSL/TLS is issued and working for the domain;
- you have completed testing on a temporary URL, preview host, or hosts file override;
- you have reduced DNS TTL ahead of the migration window.
If you change DNS too early, visitors may reach a half-configured application. If you change it too late, you may end up running two versions of the site longer than planned, which creates data sync and session issues.
What DNS cutover means for Java and Tomcat hosting
DNS cutover is the point where your domain begins resolving to the new hosting environment. For a Java application, that usually means moving the public domain from the old server to the new hosting platform where My App Server is configured.
In a Plesk-based hosting environment, you may be using:
- a new Apache virtual host for the domain;
- a Java/Tomcat instance managed through a Plesk extension such as My App Server;
- a separate port, proxy, or internal service setup behind Apache;
- the same domain name with new DNS A/AAAA records or a changed nameserver setup.
DNS does not move your application by itself. It only changes where browsers and clients look for the site. That is why the application must already be live and stable before the cutover.
Best practice: lower TTL before the migration
One of the most important steps is to lower the TTL on the relevant DNS records before the migration window. TTL controls how long resolvers cache your DNS answer. If your TTL is too high, users may continue going to the old environment for hours after you switch.
Recommended timing for TTL changes
- 24 to 48 hours before cutover: lower the TTL for the domain’s A and AAAA records, and any relevant CNAME records.
- During the cutover window: change the DNS destination to the new hosting endpoint.
- After migration: keep the old environment available until the old TTL has expired everywhere.
A shorter TTL such as 300 seconds or 600 seconds is often used for planned migrations. This does not guarantee instant updates everywhere, but it reduces the waiting time significantly.
What to test before changing DNS
Before you switch traffic, make sure the Java application works correctly on the new platform. With My App Server, this usually includes checking the Tomcat instance, Java version, and deploy path inside the hosting account.
Application checks
- Open the application on the temporary address or internal test URL.
- Confirm that the correct WAR, JSP, or servlet code is deployed.
- Check login, form submission, file upload, and any API calls.
- Verify that the application uses the correct database host, username, and password.
- Make sure session handling works as expected.
Server and hosting checks
- Confirm that the Tomcat service is running in the control panel.
- Check that the selected Java version matches your application requirements.
- Review any custom JVM settings if your app needs them.
- Ensure file permissions are correct for deployment and log access.
- Verify that Apache is proxying or forwarding requests correctly to the Java service.
DNS and SSL checks
- Prepare the final DNS record values in advance.
- Issue or reissue the SSL certificate for the target domain.
- Confirm that HTTPS works after cutover.
- Check whether any subdomains need separate records.
How to plan the cutover window
The best time to change DNS is usually during a low-traffic period for your audience, while your team is available to monitor the result. For many UK businesses, this means evening hours or a planned maintenance window, depending on customer behaviour.
Choose a time when you can:
- make the DNS change;
- monitor both the old and new environments;
- respond quickly if the application needs a rollback;
- check logs and service status during the first hour after the switch.
If the site has user logins, shopping baskets, or form submissions, avoid switching during active usage peaks. Even a technically successful DNS move can still cause user confusion if people are in the middle of transactions.
Step-by-step DNS change process for a Java migration
1. Prepare the new Java hosting environment
Install or select the required Java or Tomcat version in My App Server. If your app needs a specific JVM release, verify it before you deploy. In a Plesk-managed environment, this gives you a practical way to control the application runtime without needing a full enterprise application server setup.
2. Deploy and test the application
Upload the WAR file or application files, configure the context path, and test the app on a temporary hostname or preview endpoint. Confirm that static assets, JSP pages, servlet mappings, and backend connections are working.
3. Reduce the DNS TTL
Set the TTL lower on the records that will change. Do this in advance so the old cached values expire before cutover.
4. Prepare the SSL certificate
Make sure the certificate covers the live domain and any required subdomains. If you are moving from one hosting platform to another, the certificate may need to be reissued or reinstalled in the new control panel.
5. Change the DNS record or nameserver
Update the relevant DNS A or AAAA record, or switch nameservers if that is how your domain is managed. For most migrations, changing the A record is simpler and faster than moving the full nameserver setup.
6. Verify propagation and service health
Check DNS resolution from different networks and confirm that the domain now points to the new environment. Then test the site over HTTP and HTTPS, and review Tomcat and Apache logs for errors.
7. Keep the old environment available temporarily
Do not shut down the old application immediately. Keep it online until you are sure cached DNS entries have expired and traffic has moved across. This helps you handle stragglers still using cached records.
Should you change A records, AAAA records, or nameservers?
For a Java migration, the right option depends on how your DNS is managed.
Change A and AAAA records when you want a simple cutover
This is often the easiest approach. Keep the domain hosted where it is, and only update the record to point to the new server address. It gives you more control and usually makes rollback easier.
Change nameservers when moving DNS management too
If the DNS zone itself is moving to a new provider, you may need to change nameservers. This is a broader change and can take longer to fully propagate. It is useful when you are also changing where the DNS is managed, not only where the app is hosted.
Do not forget AAAA if IPv6 is in use
If your domain has an AAAA record and you only update the A record, some users may still reach the old platform over IPv6. During cutover, review all active records for the domain and subdomains that matter.
Common risks if you change DNS too early
Changing DNS before the new Java environment is ready can cause several issues:
- visitors land on a default page or error page;
- HTTPS fails because the certificate is not in place yet;
- the Tomcat service is not started or not bound correctly;
- database connections fail because credentials were not updated;
- users see mixed content or broken assets;
- sessions are lost if old and new environments both receive traffic.
For Java applications, this risk is especially important if the app stores session state locally. In that case, you should complete the migration in a controlled window and keep the old system online until the DNS switchover is stable.
How My App Server helps with a smoother DNS cutover
In a managed hosting environment with Plesk and My App Server, the migration process is easier to coordinate because the Java service is controlled from the same panel used for the domain and web server configuration. That helps reduce the gap between application readiness and DNS cutover.
Typical practical benefits include:
- installing a supported Tomcat version with a button;
- running a private JVM inside the hosting account;
- switching or testing Java versions before public cutover;
- starting, stopping, or checking the service from the control panel;
- deploying WAR or JSP-based applications with less manual server work;
- keeping the domain, Apache, and Java configuration aligned during migration.
This is useful for small and medium Java hosting workloads, especially when you want predictable control without managing a full standalone application server stack.
Practical migration checklist
Use this checklist before you change DNS:
- Application deployed and tested on the new hosting platform
- Correct Java or Tomcat version selected
- My App Server service running
- Database migrated and verified
- SSL certificate installed and working
- TTL lowered ahead of time
- Old hosting still available for fallback
- Monitoring prepared for the first hour after cutover
- Emails, cron jobs, and external integrations reviewed
- All DNS records for the domain checked, including AAAA and subdomains
How long should you wait after changing DNS?
Propagation is not instant. Some users may see the new destination within minutes, while others may keep using cached records until the TTL expires. For a planned migration, it is sensible to keep both environments available for at least the old TTL period, and often a little longer.
As a rule, monitor traffic and logs for several hours after the change. If your audience is spread across different networks, some visitors may reach the old environment even after your own tests show the new records are live.
What if the migration goes wrong?
If the new Java application has a serious issue after DNS changes, the rollback path should already be planned. In most cases, you can restore the previous DNS record to point back to the old hosting environment. This is one reason why lowering TTL before the migration is so important.
Rollback is easier when:
- the old system is still running;
- database changes were backward compatible;
- the DNS record was changed rather than the entire nameserver setup;
- you documented the previous values before the cutover.
Always treat DNS cutover as a controlled change, not a one-way switch without a fallback.
FAQ
Should I change DNS before or after deploying the Java application?
After deploying and testing the Java application. DNS should only be changed when the new Tomcat or My App Server setup is ready to serve real traffic.
How far in advance should I lower TTL?
Usually 24 to 48 hours before the cutover. This gives cached records time to expire before you switch the live DNS destination.
Is changing an A record better than changing nameservers?
For a Java migration, changing the A or AAAA record is often simpler and easier to roll back. Nameserver changes are more suitable when you are also moving DNS management.
Do I need to test HTTPS before changing DNS?
Yes. If the site uses HTTPS, confirm that the certificate works on the new hosting platform before the DNS switch.
Can I change DNS while Tomcat is still being configured?
That is not recommended. The domain may start pointing to an incomplete environment, which can lead to errors or downtime.
What should I monitor after the cutover?
Check DNS resolution, Apache and Tomcat logs, application error pages, database connectivity, login flows, and SSL behaviour. Also watch for traffic still arriving at the old host because of cached DNS.
Conclusion
For a Java migration in the UK, the right time to change DNS is when the new hosting environment is fully prepared, tested, and ready to accept live traffic. In a Plesk-based setup with My App Server, that means your Java version, Tomcat service, application deploy, database connectivity, and SSL should all be verified before cutover.
The most reliable approach is to lower TTL in advance, test the new environment on a temporary endpoint, switch DNS during a low-traffic window, and keep the old setup available until propagation finishes. That gives you a controlled migration with less downtime and fewer surprises for users.