Before switching DNS to a new Java host, make sure the application is already working on the new environment and that the domain, Tomcat instance, and SSL are ready for traffic. A DNS change is usually the last step in a Java hosting migration, and a careful final check helps avoid downtime, broken sessions, or unexpected redirects.
If you are moving a Java application to a managed hosting platform with Plesk and a custom Java service such as My App Server, the most important checks are not only “Does the site open?” but also “Does the correct Tomcat instance start?”, “Is the right Java version selected?”, and “Will the application behave correctly after the domain begins resolving to the new host?”
What to verify before changing DNS
Before you point your domain to a new Java host, confirm that the full application stack is ready. This should include the web application itself, the JVM/Tomcat service, any database connections, SSL, and the DNS values you will publish.
1. Test the application on the new host using a temporary URL or hosts file
Do not rely only on the live domain name. First validate the application on the new hosting account by using one of these methods:
- a temporary hostname provided by the hosting platform
- a preview URL in the control panel
- your local hosts file to map the domain to the new server IP
This lets you check the site before public DNS changes are visible everywhere. For Java applications, this is especially important because the application may depend on context paths, servlet mappings, session handling, or backend services that only show problems under real application load.
2. Check that the correct Java version is installed and selected
If your hosting plan supports multiple Java versions, verify that the application is running on the version it expects. A Java application that works on one runtime may fail on another because of class library differences, deprecated APIs, or TLS behavior.
Confirm:
- the selected Java version matches the app requirements
- the startup command or Tomcat configuration uses the intended runtime
- your application was compiled for a compatible target version
With My App Server, this is often managed through Plesk and the Java service settings. If you uploaded a custom Java application server, verify that the correct runtime path is configured and that the JVM starts cleanly.
3. Confirm Tomcat starts without errors
For Tomcat hosting, a successful DNS switch only matters if the application server is healthy. Check the service status and logs before go-live.
Look for:
- Tomcat service running normally
- no startup errors in the logs
- the web application deployed successfully
- no failed library loading or classpath errors
If you are using a private JVM or custom application server, make sure the process is bound correctly, the ports are accessible internally, and the service can restart after a controlled stop.
4. Validate the WAR, JSP, or servlet deployment
Check that the application package was deployed correctly and that all required files are present. Common issues include missing context files, incomplete WAR uploads, incorrect folder names, or undeployed changes after a restart.
Verify that:
- the WAR file unpacked correctly, if your setup uses auto-deploy
- the application context path is correct
- JSP pages compile successfully
- servlet mappings and filters work as expected
For Java hosting environments based on Plesk, it is a good idea to test a few important URLs directly, not just the home page. A page may load while a specific servlet endpoint still fails.
5. Check database connectivity and credentials
Many Java applications depend on MySQL, MariaDB, PostgreSQL, or another database service. Before switching DNS, confirm that the application can connect to the database from the new host and that credentials are correct in the configuration files.
Test:
- database hostname or connection string
- username and password
- schema permissions
- connection pool settings
If the database is remote, be sure the new host is allowed to connect. If the database moved too, confirm that the application points to the new database endpoint and not the old one.
6. Review SSL certificate readiness
Before DNS is changed, confirm that the domain has a valid SSL certificate installed on the new host. Otherwise, users may see browser warnings as soon as the domain begins resolving to the new server.
Check:
- certificate installed for the correct domain and any required aliases
- certificate chain is complete
- HTTPS responds correctly on the new host
- HTTP to HTTPS redirection works as intended
If you are using Let’s Encrypt through the hosting control panel, make sure the certificate is issued for the exact hostname users will browse. Also verify whether the application redirects to www or non-www and make that consistent before go-live.
DNS-specific checks before the switch
DNS is often the simplest part of the migration, but small mistakes can still break a production application. Review the records carefully before you update them.
7. Lower the DNS TTL in advance
If possible, reduce the TTL of the relevant DNS records at least a day before the switch. This helps the new record propagate faster once you change it.
For example, lower the TTL for:
- A records for the main domain
- AAAA records if you use IPv6
- www subdomain records
- any app subdomains that point to the new host
A lower TTL does not make propagation instant, but it can reduce the time users spend resolving the old host.
8. Identify every DNS record that may need updating
Do not change only the main website record if the application uses other names. A Java application may also rely on additional hostnames for API endpoints, admin panels, static assets, or mail-related integrations.
Review these record types:
- A and AAAA records
- CNAME records
- MX records, if mail is involved
- TXT records for SPF, DKIM, DMARC, or verification
- SRV records, if used by related services
If the Java application sends emails, uses callback URLs, or integrates with third-party services, make sure those services are not still pointing to the old infrastructure.
9. Make sure the domain points to the correct IP address
Double-check the destination IP address and ensure it belongs to the new hosting environment. A typo here can create difficult-to-diagnose downtime.
Before publishing the new DNS value, confirm:
- the IP address is correct
- the application is listening on the intended web ports
- the hosting account is configured to accept the domain
If the platform uses virtual hosts or domain bindings in Plesk, verify that the domain has been added properly to the new hosting account and is assigned to the right document root or Java application context.
Application behavior checks that are easy to miss
Some issues only appear after real traffic reaches the new host. Review the following items before the DNS cutover.
10. Test login, session handling, and cookies
Java web applications often use sessions for authentication or shopping cart state. After migration, verify that:
- users can log in
- sessions persist during navigation
- logout works properly
- cookies are set with the correct domain and secure flags
If the application stores absolute URLs in session-related logic, a change in hostname or protocol can break logins or redirects. This is common in older JSP or servlet-based applications.
11. Confirm that absolute URLs and redirects are updated
Applications sometimes contain hardcoded links to the old host. Before switching DNS, search for references to the previous domain in configuration files, templates, and application properties.
Check for:
- redirect targets
- callback URLs
- API endpoints
- image and asset links
- SMTP or notification links that may appear in generated messages
It is also worth testing canonical redirects, such as http to https and non-www to www, to ensure they point to the final public hostname you want users to see.
12. Verify file permissions and upload paths
During migration, files may move into a different document root or application directory. Check that the Java process can read the files it needs and write where it must, such as temporary folders, upload directories, or log paths.
Make sure:
- upload directories are writable if the application stores user files
- log directories exist and are accessible
- temporary directories are available to the JVM
- static assets are served correctly
On managed hosting platforms, permission problems are a common source of post-migration errors. Fix them before DNS is changed so users do not discover them first.
13. Review cron jobs, scheduled tasks, and background processes
If the application uses scheduled jobs, verify that they are already reconfigured on the new host. A Java application may depend on scheduled cleanup tasks, report generation, cache refresh jobs, or periodic synchronization.
Confirm:
- cron jobs are recreated on the new hosting account
- script paths and environment variables are correct
- scheduled tasks are not still running on the old server
- duplicate execution will not occur after DNS changes
This step matters because switching DNS does not move background jobs automatically.
Operational checks before going live
Once the technical validation is complete, do a short operational review. These checks help reduce user-facing issues during the first hours after cutover.
14. Prepare a rollback plan
If something unexpected breaks after DNS changes, you should be able to restore service quickly. Keep the old environment available until the new host has proven stable.
Your rollback plan should include:
- the old DNS values
- the old hosting configuration
- notes about any data synchronization needed
- the person responsible for making the rollback decision
For Java hosting migrations, rollback is easiest when you know whether the new host is already handling live writes, uploads, or form submissions. If live data is being generated, plan carefully before switching back.
15. Check monitoring and log access
After the DNS switch, you will want quick access to logs and service status. Verify that you can inspect Tomcat logs, application logs, and web server logs from the control panel or file manager.
Useful checks include:
- access to error logs in Plesk or the file system
- ability to restart the Java service if needed
- visibility into access logs for traffic debugging
- any configured monitoring or uptime alerts
If your application encounters an issue during propagation, logs are usually the fastest way to identify whether the problem is DNS, SSL, routing, or the Java runtime.
16. Confirm the new host can handle the expected traffic
A managed Java hosting environment is often suitable for small and medium applications, but it is still worth validating expected usage before go-live. Make sure the new host has enough CPU, memory, and storage for the application’s normal baseline.
Check:
- available JVM memory settings
- disk space for logs, cache, and uploads
- concurrent connection limits
- application startup time after restart
If the application already felt slow during testing, do not assume it will improve after the DNS switch. Resolve performance concerns first.
Recommended pre-switch checklist
Use this short checklist just before changing DNS:
- the application works on the new host via temporary access
- Tomcat or the Java service starts successfully
- the correct Java version is selected
- database connections are working
- SSL certificate is installed and valid
- DNS TTL has been lowered
- all required DNS records have been reviewed
- redirects and canonical URLs are correct
- session login and forms were tested
- cron jobs and background tasks are recreated
- logs are accessible for troubleshooting
- rollback plan is ready
Common mistakes to avoid
Changing DNS before testing the app
This is the most common error. A domain can resolve correctly while the application still fails because the Java service, database, or SSL setup is incomplete.
Forgetting subdomains and APIs
If your application uses api.example.com, admin.example.com, or static.example.com, update those records too. Otherwise part of the platform may keep pointing to the old server.
Ignoring cached DNS and browser behavior
Even after the DNS change is published, some users may continue to see the old destination until their resolver cache expires. This is normal and another reason to keep the old environment available for a while.
Not checking Java runtime compatibility
A working codebase on one JVM may fail on another due to version differences. Always confirm compatibility before go-live.
Overlooking file permissions and write access
Many migration issues come from upload folders, temp directories, and log paths rather than from the application code itself.
FAQ
How long should I wait after changing DNS?
Propagation time depends on TTL and resolver caching. Some users may reach the new host quickly, while others may continue to see the previous server for longer. Lower TTL values help reduce this window, but you should still keep the old environment available during the transition.
Should I switch DNS before or after testing Tomcat?
After testing. Tomcat, the selected Java version, the application deployment, and any database connections should all work on the new host before the domain is pointed there.
Do I need to test HTTPS separately?
Yes. Test both HTTP and HTTPS if your site supports both. Confirm that the SSL certificate is installed and that redirects go to the correct final URL.
What if my Java app uses a custom Tomcat setup?
Then you should verify the custom service configuration, startup parameters, paths, and logs even more carefully. A custom Tomcat or private JVM can work well on managed hosting, but it must be validated before the DNS cutover.
What should I do if the site breaks after DNS propagation starts?
Use your rollback plan. Check logs first to determine whether the issue is DNS-related, application-related, or caused by a missing dependency. If needed, restore the previous DNS record while you fix the new environment.
Conclusion
Before switching DNS to a new Java host, the safest approach is to verify the application on the new environment first, then review Tomcat, Java version, database access, SSL, and DNS records. In a hosted Java setup with Plesk and My App Server, this means checking both the hosting control panel configuration and the application itself.
When these final checks are complete, the domain cutover becomes a simple publish step instead of a troubleshooting exercise. That is the main goal of final checks before going live: reducing risk, avoiding avoidable downtime, and making sure users reach a fully working Java application from the first DNS lookup.