When you migrate a Java application to a new hosting environment, DNS should usually be changed only after the application is ready to receive real traffic. In most cases, the best time for DNS cutover is after your Java app, Tomcat instance, database connections, SSL certificate, and path settings have all been tested on the new host and the site works correctly on a temporary or preview URL.
If you change DNS too early, visitors may reach the new server before the application is fully configured. If you wait too long, you may keep serving traffic from the old environment while the new Java hosting setup is already ready. The goal is to switch DNS at a point where the new platform can answer requests immediately, with the lowest possible downtime and minimal risk of broken sessions, missing assets, or database errors.
When should you change DNS for a Java migration?
Change DNS when the new Java application stack is confirmed working and you are ready to make it the live destination for your domain. For a typical Java hosting or Tomcat hosting migration, that means:
- the application deploys successfully on the new server;
- Tomcat starts without errors and stays running;
- the correct Java version is selected;
- database connections are validated;
- file permissions and upload paths are correct;
- HTTPS works with a valid SSL certificate;
- the site is tested through a temporary hostname, hosts-file test, or preview URL;
- the old environment is still available during the propagation window.
In other words, DNS cutover should be the last planned step in the migration, not the first one. The DNS record change itself is simple, but the timing is critical because it determines when users begin reaching the new host.
Why timing matters during Java DNS cutover
Unlike a static website, a Java application often depends on a running service, a specific Java runtime, Tomcat configuration, and sometimes session or database state. If DNS is switched before those pieces are ready, users may see errors such as:
- 502, 503, or 500 errors;
- blank pages or failed JSP compilation;
- login sessions not working;
- missing images, CSS, or uploads;
- database connection failures;
- incorrect redirects after login or checkout.
For a managed hosting environment using Plesk and My App Server, the practical advantage is that you can prepare the Java service in advance, test it independently, and only then switch the domain’s DNS to the new platform. That reduces live risk and makes the cutover easier to control.
Best time to switch DNS in a Java migration
Recommended cutover window
The safest time to change DNS is during a low-traffic window, usually outside business hours or when your audience is least active. This is especially important for applications with active users, forms, logins, or shopping flows.
In many Java hosting migrations, the ideal sequence is:
- Prepare the new Tomcat or private JVM instance.
- Deploy the application to the new server.
- Test the app using a temporary hostname or local hosts-file override.
- Lower the DNS TTL in advance.
- Freeze content changes if needed.
- Perform final sync of files and database changes.
- Update DNS to point the domain to the new hosting platform.
- Monitor the site until traffic fully settles on the new environment.
How long before cutover should you lower TTL?
If you control DNS, reduce the TTL at least 24 to 48 hours before the migration. A lower TTL helps resolvers pick up the new records faster once you switch them. For example, if your current TTL is 86400 seconds, you may want to reduce it to 300 or 600 seconds before the migration window.
Keep in mind that TTL only affects future DNS lookups. Some visitors may still use cached values until their resolver expires, so DNS propagation is never perfectly instant.
What should be ready before changing DNS
Before the cutover, confirm that the new Java hosting environment is fully prepared. In a Plesk-based setup with My App Server, this usually means checking the service and the application together, not separately.
Application readiness checklist
- The WAR, JSP, or servlet application is deployed correctly.
- The correct application context path is configured.
- Tomcat starts and serves requests on the expected port or internal setup.
- The right Java version is selected for the app.
- Environment variables or JVM parameters are set if required.
- Database hostnames, usernames, and passwords are updated if the database moved.
- File upload paths, cache paths, and log paths are writable.
- SSL certificate is installed for the domain.
- Redirect rules are reviewed so they do not point to the old host.
Validation before live traffic
Test the migrated application with real browser requests, not only with a service status check. Open important pages, submit forms, log in if relevant, and verify that static assets load correctly. If the app uses background jobs or scheduled tasks, make sure those are not interrupted by the migration.
If possible, compare responses on the old and new hosts to confirm that the content, headers, and behavior match. This is especially useful for Java applications that depend on custom filters, sessions, or URL rewriting.
How DNS cutover works for a Java application
DNS cutover means changing the domain’s A or AAAA record, or sometimes the nameserver delegation, so the domain starts resolving to the new hosting environment. For most Java migrations, you do not need to change every DNS record. Often you only need to update the record that points the main domain and any relevant subdomains to the new server.
If your Java application also uses mail, API endpoints, or subdomains such as app.example.com and www.example.com, review each record separately. Do not change DNS more widely than necessary unless the migration plan requires it.
A and AAAA records vs nameserver changes
Changing an A or AAAA record is usually the simplest method when only the hosting destination changes. Changing nameservers is broader and can affect all zone management at once. For a Java migration, a record-level cutover is often easier to validate and roll back if needed.
Use the approach that matches your DNS setup, but keep the following rule in mind: make the smallest change that safely moves traffic to the new Java hosting platform.
Practical cutover steps for My App Server and Plesk
In a hosting environment with Plesk and My App Server, the cutover usually follows a controlled service deployment. The exact steps may vary, but the structure is often the same.
- Clone or prepare the Java application on the new subscription or domain.
- Select the required Java runtime version in My App Server.
- Start the Tomcat service and confirm it is healthy.
- Deploy the application package and verify the context path.
- Test the app using a temporary hostname or direct preview access.
- Check logs for startup warnings, classpath issues, or dependency errors.
- Update the DNS record for the live domain.
- Keep the old environment active during propagation.
- Monitor access logs and app logs after the switch.
This approach works well for small and medium Java applications that use a dedicated Tomcat instance or private JVM inside a shared hosting account. It is practical for JSP hosting, servlet hosting, and standard WAR deployments where the main objective is clean go-live with minimal downtime.
How to reduce downtime during DNS propagation
DNS propagation cannot be fully eliminated, but you can reduce the impact by planning carefully.
Use a lower TTL in advance
Lowering TTL before cutover helps speed up record updates. This is one of the most effective steps if you control the DNS zone.
Keep the old host online temporarily
Do not shut down the old Java environment immediately after DNS changes. Keep it available long enough to catch visitors whose DNS cache still points to the previous server. This avoids unnecessary failures during the transition period.
Freeze important changes during the cutover
If the application accepts user-generated content, orders, or account changes, avoid simultaneous updates on both platforms. Freeze content changes briefly or define a short maintenance window so you do not lose data between the final sync and the DNS switch.
Synchronize data before the switch
If your Java app stores uploaded files, generated content, or database records, make sure the final data is copied to the new host immediately before the DNS update. This is especially important if users can change data in real time.
Common mistakes when changing DNS for Java hosting
Switching DNS before testing Tomcat
One of the most common mistakes is pointing the domain to the new server before Tomcat has been fully verified. A Java application may deploy but still fail under real traffic because of missing libraries, wrong JVM flags, or path issues.
Forgetting SSL before go-live
If the domain uses HTTPS, make sure the certificate is ready before DNS cutover. A valid certificate should be installed and the site should load cleanly over HTTPS on the new host. Otherwise, users may see certificate warnings right after the migration.
Not checking subdomains
Many Java applications use more than one hostname. For example, the main site may be on example.com while the app is on app.example.com. Check all related DNS records so users are not sent to different servers by mistake.
Ignoring cached sessions
Session-based Java applications may behave differently once traffic starts flowing to the new environment. If sessions are stored in memory on the old host, users may need to log in again after the move. Plan for that behavior and communicate it if necessary.
Removing the old server too soon
Even if the new server is working, some recursive resolvers will still send traffic to the old IP for a while. Keeping the old host online avoids hard failures during that transition period.
Rollback planning
Before changing DNS, decide how you would roll back if something unexpected happens. DNS rollback is usually as simple as changing the record back to the old IP, but the effect still depends on TTL and cache duration.
Have the following ready:
- the old DNS record values;
- a copy of the previous application package if needed;
- access to both hosting environments;
- log access for troubleshooting;
- confirmation of which database and file stores are live.
In practice, a rollback is easiest when you have already kept the old Java host active and preserved its configuration during the cutover window.
DNS timing examples for typical Java migrations
Example 1: simple Tomcat migration
A small JSP application is moved to a new hosting account with My App Server. The app is deployed, the Java version is matched, and the site is tested on a preview URL. Once everything works, the A record is changed during a quiet period. The old server stays online for several hours until traffic fully settles.
Example 2: application with database move
A servlet application is migrating together with its database. First the database is copied and tested. Then the Java app is pointed to the new database and verified. Only after the new environment passes login and form tests is DNS changed. This avoids sending live users to an app that still points to the old data source.
Example 3: staged go-live with low TTL
The domain TTL is reduced two days before the migration. The new Tomcat instance is prepared in Plesk, the app is tested by modifying local hosts-file entries, and the final content sync is completed just before cutover. DNS is updated, and most users reach the new host quickly because the TTL had already been lowered.
FAQ
Should I change DNS before or after deploying the Java app?
After deploying and testing the Java app. DNS should point to the new environment only when the application is ready to serve real visitors.
Can I test a Java migration without changing DNS?
Yes. You can often test using a temporary hostname, preview URL, or local hosts-file override. This lets you verify Tomcat, SSL, and application behavior before the live domain is moved.
How long does DNS propagation take?
It depends on the TTL and resolver caching. Some users may see the new destination within minutes, while others may take longer. That is why the old server should stay available during the transition.
Is it better to change only the A record?
Usually yes, if only the web hosting destination changes. Changing a single record is often simpler than moving nameservers, especially for a Java application migration where you want controlled cutover.
What if my Java app uses sessions?
Expect some users to lose sessions when the traffic moves to the new server, unless the application has a shared session strategy. For many small and medium hosting setups, a brief re-login after cutover is normal.
Do I need to stop Tomcat before changing DNS?
Not necessarily. In many cases, it is better to keep the application running on the new server and simply switch DNS when ready. The old server should remain available until propagation is complete.
Summary
For a Java migration, change DNS only after the new hosting environment has been fully prepared, tested, and confirmed ready for live traffic. The safest approach is to deploy the application first, validate Tomcat, Java version, SSL, and database connectivity, then switch the DNS record during a low-traffic window. Lower TTL in advance, keep the old host online for a while, and monitor the application closely after cutover.
With a controlled process in Plesk and My App Server, DNS cutover becomes a predictable final step instead of a risky event. That is the best way to move a Java, Tomcat, or JSP application with less downtime and fewer surprises.