For a Tomcat migration, the best time to change DNS is usually after the new application is fully tested and ready to serve live traffic, but before the old environment is decommissioned. In most hosting and control panel setups, including managed Tomcat hosting with Plesk, the safest approach is to lower the DNS TTL in advance, switch the record only when the new Tomcat instance is stable, and keep the old server available long enough to catch any cached DNS traffic.
If your migration includes a new Apache Tomcat instance, a private JVM, or a Java hosting service such as My App Server, DNS cutover should be treated as the final go-live step. The DNS change itself is simple; the planning around it is what prevents downtime, broken sessions, and missed requests during propagation.
When to change DNS during a Tomcat migration
Change DNS only when the new Tomcat environment is ready to receive production traffic. That means your WAR deployment, application configuration, database connectivity, SSL certificate, and service start-up must already be working on the target platform.
In practice, the correct time is usually one of these:
- At the end of testing, when the new Tomcat server has passed functional and smoke tests.
- During a planned maintenance window, if the application is sensitive to session loss or write activity.
- After DNS TTL has been lowered for at least one full TTL period, so the change propagates faster.
- Once the old and new environments are both ready, so rollback is still possible if needed.
For most small and medium Java applications hosted in Plesk with My App Server, this means preparing the new service first, confirming that Tomcat starts correctly, and only then updating the A or CNAME record that points users to the application.
What should be ready before the DNS cutover
A DNS change should never be the first step of a Tomcat migration. Before switching traffic, make sure the new host can already run the application independently.
Application deployment is complete
Upload and deploy the WAR file, JSP files, or other Java web application components on the new Tomcat service. Confirm that the context path is correct and that the application opens without deployment errors.
Java version and Tomcat version are verified
Check that the target server uses the required Java runtime and compatible Tomcat version. In a hosting platform with My App Server, you may have a choice of ready-made Java/Tomcat versions or a manually configured custom service. Match the application requirements before switching DNS.
Configuration files are updated
Review environment variables, database URLs, external API endpoints, mail settings, file paths, and any hardcoded hostnames. A migration often fails not because Tomcat is unavailable, but because the application still points to the old infrastructure.
SSL and public domain access work on the new server
Make sure the certificate is installed and the application responds correctly over HTTPS. If the domain will remain the same after migration, the new Tomcat instance should already be able to serve that hostname before DNS changes.
Smoke testing is completed
Test the home page, login, forms, uploads, and key transaction flows. If possible, use a temporary hostname, hosts file entry, or a preview URL to test the new Tomcat instance before you touch live DNS.
Why DNS timing matters in a Tomcat migration
DNS is not instant for every visitor. Even after you update a record, some users and recursive resolvers may continue to reach the old server until cached values expire. This is why the timing of the DNS switch matters so much in Tomcat hosting.
If you change DNS too early, traffic may move to an untested or incomplete environment. If you change it too late, users may keep reaching the old server while you think the migration is already live.
Common risks include:
- Propagation delays causing split traffic between old and new servers.
- Session loss if Tomcat sessions are stored locally and users move between servers.
- Database mismatch if the new environment is not fully aligned with production data.
- SSL hostname issues if the certificate is not installed on the new host before cutover.
- Broken callbacks or integrations if external services still call the old IP address or hostname.
For this reason, a DNS cutover is best treated as a controlled switchover, not as a simple point-and-click change.
Recommended DNS cutover process for Tomcat hosting
The safest approach is to reduce TTL in advance, validate the new service, and then switch the public record.
1. Lower the TTL before the migration
At least 24 to 48 hours before the cutover, reduce the TTL on the relevant DNS record. A lower TTL helps caches expire sooner, which reduces the time users may continue seeing the old server after the DNS change.
Typical values used during migration are 300 seconds or 600 seconds, depending on your DNS provider and operational needs. If your current TTL is very high, lower it in advance and wait for the old TTL to expire before making the final switch.
2. Prepare the new Tomcat service
In your hosting control panel, confirm that the new Tomcat or private JVM service is running correctly. With My App Server, that usually means verifying service status, startup parameters, and application deployment settings. Ensure the application responds on the target host or preview endpoint.
3. Test the new environment before public traffic
Use a temporary hostname, hosts file override, or restricted preview URL to test the application. Check login, database writes, upload paths, scheduled jobs, and any page that depends on Tomcat session handling or backend services.
4. Update the DNS record
Change the public DNS record to the new IP address or hostname only after the new Tomcat service is ready. In many cases, this is an A record for the domain or a CNAME for a subdomain. Keep the old service online during propagation.
5. Monitor traffic on both systems
After the change, watch access logs, error logs, and application metrics on both the old and new environments. A clean cutover should show traffic moving to the new server while the old one gradually becomes quiet.
6. Keep the old server available for rollback
Do not remove the old Tomcat service immediately. Keep it active until you are confident that DNS has propagated and no important traffic is still arriving there. This makes rollback much faster if a configuration issue appears after go-live.
Best practice for Tomcat cutover with a shared hosting control panel
In a managed hosting environment with Plesk and My App Server, the DNS change is only one part of the process. Because the Java application runs inside a controlled service, you should also consider service-level checks before and after the DNS update.
- Verify that the Tomcat service starts automatically after a restart.
- Check that the correct Java version is selected for the application.
- Confirm that the context path and public URL match the live domain.
- Review file permissions for uploads, logs, and temporary folders.
- Make sure the Apache or proxy layer, if used, forwards requests correctly to Tomcat.
These checks are especially useful when migrating from a different Java host, from another Tomcat installation, or from a local development environment into hosted Java hosting.
Should you change DNS before or after testing?
Always after testing. DNS should be changed only when you are ready for production traffic. If you point the live domain to the new Tomcat server too early, real users become part of the test, which is risky even for simple web apps.
A good sequence is:
- Deploy the application on the new Tomcat environment.
- Test using a temporary hostname or hosts file entry.
- Lower DNS TTL in advance.
- Validate SSL, database connectivity, and important user journeys.
- Switch DNS during the planned go-live window.
- Monitor logs and keep rollback ready.
This approach works well for JSP hosting, servlet hosting, and small to medium Java applications that use a dedicated Tomcat service inside a shared hosting account.
What to do if the application uses sessions or logins
If your Tomcat application relies on user sessions, changing DNS can affect active users. Since sessions are often stored locally in memory, any user moved to a different server may need to log in again.
To reduce impact:
- Schedule the cutover during low traffic hours.
- Warn users about possible session interruption if needed.
- Keep the old environment available temporarily.
- Avoid deploying a breaking application change at the same time as the DNS switch.
If your application uses shared database-backed session storage or another session strategy, test that behavior carefully before go-live. For many standard hosting migrations, the simplest assumption is that sessions may be lost during the cutover.
How long should you keep the old DNS target active?
Keep the old server active until you are sure the majority of cached DNS lookups have expired and the new site is stable. In many cases, a few hours is enough for low-risk services, but a full day is a safer default for important applications.
The right retention period depends on:
- the TTL you used before the switch,
- how aggressively resolvers cache DNS,
- how critical the application is,
- whether users access it globally, and
- whether the app has stateful sessions or active uploads.
For business-critical sites, it is sensible to keep the old Tomcat instance online until you have reviewed logs and confirmed that traffic has stabilized on the new host.
Examples of good and bad DNS timing
Good timing
You deploy the application to the new My App Server Tomcat instance, test it with a temporary hostname, lower the TTL two days before cutover, then update the public DNS record during a maintenance window. The old server stays online for the next day. This reduces user impact and gives you a rollback path.
Bad timing
You change DNS before the database connection is fixed, or before Tomcat has been verified on the new server. Users start hitting errors as soon as some resolvers pick up the new IP. Because the old host is already removed, rollback becomes slower and more disruptive.
Common DNS records used in a Tomcat migration
The exact record depends on how your application is published, but these are the most common choices:
- A record for pointing the domain directly to a new server IP address.
- AAAA record if IPv6 is in use and supported by your hosting setup.
- CNAME record for subdomains that should follow another hostname.
If the domain is the public entry point for a Tomcat application, ensure that all relevant records are updated consistently. Mixed DNS values can cause confusing results during propagation.
How this applies to My App Server and Plesk
With ITA My App Server, the Tomcat service is managed through the hosting control panel, which makes it easier to prepare the target environment before DNS cutover. You can install a suitable Java/Tomcat version, control the service, and verify the application in isolation before exposing it to live traffic.
This is particularly useful when:
- you are migrating a WAR application to a new hosted Tomcat instance,
- you need a private JVM inside a shared hosting account,
- you want to move a servlet or JSP application with minimal downtime, or
- you need a controlled go-live process without a complex enterprise deployment stack.
The practical advantage is simple: you can treat the new Tomcat service as ready only when the application works in the control panel environment, then update DNS as the final step.
FAQ
Should I change DNS before deploying the Tomcat app?
No. Deploy and test the application first. Change DNS only after the new Tomcat environment is confirmed to be ready for production traffic.
How far in advance should I lower DNS TTL?
Usually 24 to 48 hours before the migration is enough, but it depends on your current TTL value. The goal is to let the old TTL expire before the final DNS change.
Can I change DNS and Tomcat at the same time?
You can, but it is not recommended. Changing both at once makes troubleshooting much harder and increases the chance of downtime or partial outages.
Will users lose sessions when DNS changes?
Possibly. If sessions are stored in the Tomcat instance memory, users may need to log in again after the cutover. Plan for that when scheduling the migration.
How long does DNS propagation take?
It depends on the TTL and caching behavior of different resolvers. Some users may see the change within minutes, while others may continue using the old record longer.
What if the new Tomcat server has a different IP but the same domain?
That is a standard DNS cutover. Update the A record to the new IP after the new Tomcat service is tested and ready, then keep the old environment online temporarily.
Is a temporary hostname useful before the DNS switch?
Yes. A temporary hostname or hosts file override lets you test the new Tomcat application without exposing it to all live users.
Conclusion
The right time to change DNS for a Tomcat migration is after the new application is fully tested, the Tomcat service is confirmed to run correctly, and the DNS TTL has been lowered in advance. For hosted Java applications managed through Plesk and My App Server, the safest pattern is to prepare the new Tomcat environment first, validate it privately, then switch the public DNS as the final go-live step.
That sequence keeps downtime low, makes rollback possible, and gives you a cleaner migration for Java hosting, JSP hosting, servlet hosting, or a private JVM setup.