If you are migrating a Tomcat application on a UK hosting account, the best time to change DNS is usually after the new application has been installed, tested, and confirmed on the destination platform, but before you lower the DNS TTL too late. In practice, this means preparing the DNS change in advance, validating the Tomcat service in Plesk or My App Server, and then switching the domain only when the new environment is ready to serve real traffic.
The main goal is to minimise downtime and avoid sending users to a half-configured application. For most Tomcat migrations, the safest approach is to keep the old site live while you test the new host using a temporary URL, hosts-file override, or a staging subdomain. Once the new Tomcat instance is working correctly, you can update the domain’s A or AAAA record, or move nameservers if that is part of the migration plan.
When should you change DNS for a Tomcat migration?
Change DNS only when the new Tomcat environment is ready to receive live traffic. That usually means the following is already in place:
- Your application files, WAR package, or deployed JSP/Servlet resources are uploaded.
- The correct Java version is selected and the Tomcat service is running.
- Database connection details, environment variables, and any external integrations are updated.
- SSL is prepared if the site will use HTTPS.
- You have tested login, forms, uploads, API calls, and any scheduled tasks that matter to the application.
If you change DNS before these checks are complete, users may reach the new server and encounter errors. If you wait too long after everything is ready, you simply extend the migration window and keep the old environment live longer than necessary.
Best practice: prepare first, cut over last
The most reliable cutover pattern for Tomcat hosting is:
- Set up the new hosting environment.
- Install or select the required Tomcat version in My App Server or Plesk.
- Deploy the application and test it privately.
- Reduce DNS TTL ahead of time.
- Switch DNS during a low-traffic period.
- Monitor logs and application behaviour closely after the change.
This approach is especially useful for Java hosting, JSP hosting, servlet hosting, and private JVM setups where the application may depend on specific Java or Tomcat versions. It lets you verify the runtime before exposing it to public traffic.
What to check before changing DNS
1. Tomcat and Java are running correctly
In a managed hosting environment with My App Server, confirm that the correct service is enabled and started. If you are using a custom Apache Tomcat installation, make sure the service starts cleanly and stays running without restart loops. Check that the selected Java version matches your application requirements.
Typical checks include:
- Tomcat starts without errors.
- The application context loads.
- JSP pages compile successfully.
- Servlets respond correctly.
- No missing library or classpath errors appear in the logs.
2. The site works on the new host before DNS change
Test the application using a temporary hostname, staging URL, or local hosts-file override. This is important because DNS should not be your first test method. If you only test after the domain resolves to the new server, any problem becomes visible to end users.
Check key user journeys such as:
- Homepage and main landing pages
- Authentication and session handling
- Database reads and writes
- File upload and download features
- Search, checkout, booking, or other core functions
3. SSL and HTTP settings are ready
If the application uses HTTPS, install or prepare the SSL certificate before the DNS cutover. This matters because users expect the site to load securely immediately after the switch. For Tomcat applications behind Apache or a proxy layer, confirm that redirects and proxy headers are configured properly so that the application sees the correct scheme and host.
Pay attention to:
- Certificate installation and validity
- Redirects from HTTP to HTTPS
- Mixed content issues
- Forwarded host and protocol headers
4. External services have been updated
Many Tomcat applications depend on SMTP, payment gateways, API endpoints, analytics, or webhook callbacks. If the new server has a different IP address or hostname, confirm that any allowlists, callback URLs, or integrations have been updated.
Examples include:
- Mail relay settings
- Firewall allowlists for third-party services
- OAuth redirect URLs
- Webhook destination URLs
Should you change A records or nameservers?
In most Tomcat migrations, changing the A record is the simpler option. It lets you point the existing domain to the new hosting platform without changing the rest of the DNS setup. This is often the preferred method when only the web application is moving.
Move the nameservers only if you are also transferring DNS management to a new provider. That can be useful in a broader migration, but it adds more variables and can increase the risk of propagation confusion if records are not recreated accurately.
Use an A record change when:
- You are moving only the Tomcat application.
- You want minimal DNS changes.
- You need to keep existing MX, SPF, DKIM, or other records intact.
- You are already managing DNS in a panel and just need the web traffic to move.
Use a nameserver change when:
- The entire DNS zone is moving to the new host or provider.
- You need all DNS records managed in one place.
- You are also changing where other services are hosted.
How TTL affects the cutover time
TTL, or Time To Live, controls how long DNS resolvers cache a record before checking again. If the TTL is high, some users may continue to reach the old host for longer after you change DNS. If the TTL is lower, propagation is usually faster.
For a Tomcat migration, lowering the TTL in advance is a practical way to reduce the transition window. A common approach is to reduce TTL 24 to 48 hours before the planned switch, then change DNS once the value has had time to propagate.
Useful guidance:
- Lower TTL before the cutover, not at the last minute.
- Keep the old server available until DNS propagation has settled.
- Remember that cache behaviour varies by ISP, device, and browser.
Recommended DNS cutover process for Tomcat hosting
- Prepare the destination environment. Install Tomcat, choose the required Java version, and set up the application in My App Server or Plesk.
- Test on a non-public address. Use a temporary URL or hosts-file mapping to verify the app before public traffic moves.
- Lower the TTL. Give DNS caches enough time to honour the shorter value.
- Schedule the cutover. Pick a low-traffic period if possible, especially for business-critical applications.
- Update DNS. Change the A/AAAA record or nameservers as planned.
- Monitor closely. Watch application logs, Tomcat logs, and error reports during the first hours after the switch.
- Keep the old host active temporarily. Leave it online until you are confident all traffic has moved.
How to test a new Tomcat host before changing DNS
Testing before DNS is one of the most important parts of a clean migration. If your hosting platform supports My App Server, you can often prepare the Tomcat environment and validate it before the public domain points to it.
Testing methods
- Temporary hostname: Use a preview or staging hostname on the new account.
- Hosts-file override: Map the domain locally to the new server IP for testing.
- Direct server access: Use the temporary address provided by the hosting platform if available.
During testing, compare the old and new environments carefully. Differences in Java version, file permissions, session handling, or proxy configuration can change application behaviour even when the pages appear to load.
Common Tomcat migration mistakes that affect DNS timing
Changing DNS before the application is fully deployed
This is the most common mistake. If DNS moves early, some visitors will reach an incomplete deployment and see errors. Make sure the application is fully functional first.
Forgetting to reduce TTL
If TTL stays high, the cutover may take much longer than expected. Users will continue to visit the old host, and debugging becomes harder because different people see different versions of the site.
Not checking SSL before the switch
If HTTPS is not ready, browsers may show warnings or block access. Always verify certificates and redirect rules before pointing the domain at the new Tomcat instance.
Overlooking database or session issues
A Tomcat migration is not just a DNS change. The application may depend on database migrations, session storage, file paths, or environment variables. If these are not aligned, the site may fail after DNS is updated.
Shutting down the old server too soon
Even after DNS is changed, some users may still resolve the old IP for a while. Keep the old environment available during the transition period to avoid intermittent failures.
Example migration timeline
Here is a simple example of how to plan DNS cutover for a Tomcat migration:
- Day 1: Prepare the new hosting account, install Tomcat, and deploy the app.
- Day 2: Test the application using a private URL or hosts-file override.
- Day 2 or 3: Lower TTL on the live DNS records.
- Day 3: Confirm SSL, redirects, and integrations.
- Day 3 evening or another low-traffic period: Change the DNS record.
- Next 24 to 48 hours: Monitor logs and keep the old server active.
This timeline can be shorter for a simple site or longer for a busy application with more dependencies. The right moment to change DNS is not determined by the calendar alone, but by whether the destination Tomcat environment is ready and tested.
How My App Server helps with a smoother cutover
In a managed hosting setup, My App Server makes it easier to prepare a Tomcat application before DNS changes. You can select a Tomcat version, manage the service, and deploy a private JVM or application runtime within the hosting account. That means the new environment can be configured and checked before the domain is pointed at it.
This is especially useful if you need:
- A specific Java version for compatibility
- A private Tomcat instance for one application
- Simple service control from the control panel
- WAR deployment without building a complex server stack
For smaller and medium-sized Java applications, that control is often enough to make DNS cutover straightforward and low risk.
FAQ
How long before migration should I lower DNS TTL?
Usually 24 to 48 hours before the planned cutover. This gives resolvers time to cache the shorter value before you switch the record.
Can I change DNS while Tomcat is still being tested?
It is possible, but not recommended. Test first on a temporary address, then change DNS only when the new host is ready for live traffic.
Is it better to change the A record or nameservers for a Tomcat migration?
Changing the A record is usually simpler if only the application is moving. Use nameserver changes only if you also want to move DNS management.
Will DNS change stop all traffic immediately?
No. DNS propagation and caching mean some users may still reach the old server for a period of time after the change.
Should I keep the old Tomcat server online after cutover?
Yes, at least for a short period. This helps handle cached DNS, late traffic, and any issues you may need to compare between the old and new environments.
What should I monitor after changing DNS?
Watch Tomcat logs, application errors, HTTP status codes, SSL behaviour, database connectivity, and any integration failures. Check both user reports and technical logs.
Conclusion
The best time to change DNS for a Tomcat migration in the UK is after the new application has been deployed, tested, and verified, and after you have lowered TTL in advance. For most hosting migrations, the safest method is to prepare the new Tomcat environment first, validate it privately, and then switch the domain once you are confident that it can serve live traffic correctly.
If you use managed hosting with Plesk and My App Server, that process is often simpler because you can install Tomcat, choose the required Java version, and control the service before the public DNS cutover. That gives you a cleaner migration and less downtime for users.