Before you switch DNS to a new Tomcat host, make sure the application is already running correctly on the new environment and that all dependencies are ready. For a Java or JSP application hosted through Plesk and My App Server, the most reliable approach is to validate the site on the new server first, then update DNS only after you have checked the Tomcat service, Java version, document root mapping, application resources, and any external integrations.
A DNS change is not just a domain update. It is the moment when real users begin reaching the new host, so any missed configuration can become visible immediately. The checks below help reduce downtime, avoid broken pages, and confirm that your Tomcat-based application is ready to go live.
Confirm that the application works on the new Tomcat host
Start by testing the application directly on the new hosting account before changing DNS. If you are using a managed hosting platform with Plesk and My App Server, you should verify that the JVM and Tomcat instance start successfully and that the application deploys without errors.
Check that Tomcat starts cleanly
Open the service controls in Plesk and confirm that the Tomcat service is running. If the host provides a private JVM or a dedicated Tomcat instance for the account, make sure the selected Java version is compatible with your application. A startup failure usually points to one of the following:
- Incorrect Java version
- Invalid server.xml or context configuration
- Missing environment variables
- Port conflict or service misconfiguration
- Application deployment errors in the logs
Load the application through the temporary host name
Before DNS changes, test the site using the temporary hostname, preview URL, or any provided internal access method. Confirm that:
- The home page loads
- JSP pages render correctly
- Servlet routes respond as expected
- Static resources such as CSS, JavaScript, and images are available
- Forms submit without server-side errors
If your application uses a base URL, context path, or reverse proxy mapping, make sure it matches the new hosting setup. A site may load in preview but still break after DNS if the host name is hardcoded inside the application.
Verify DNS-related settings before go-live
DNS should only be switched after you have checked all records that affect web and mail traffic. The most common mistake is changing the A record but forgetting related records such as MX, SPF, DKIM, or subdomains used by the application.
Review A, AAAA, and CNAME records
Check the current DNS zone and confirm which records will be updated. Typical items to review include:
- A record for the main domain
- AAAA record if you use IPv6
- CNAME records for www and other aliases
- Subdomains used by the Java application, such as app.example.co.uk or api.example.co.uk
If your new Tomcat host is behind Plesk, make sure the domain points to the correct web server and that the application routing is aligned with the hosting configuration.
Lower TTL in advance
If possible, reduce the TTL of the relevant DNS records before the migration. This helps the new IP address propagate faster when the switch happens. A lower TTL does not guarantee instant update everywhere, but it usually reduces the time users may be directed to the old host.
Change the TTL ahead of time rather than on the same day as the DNS switch. This gives the existing cached values time to expire before the final cutover.
Confirm mail and other services are unaffected
If the domain also handles email, do not assume that a web hosting migration will leave mail untouched. Verify that the DNS zone still contains the correct MX and mail-related records. For example:
- MX records for incoming mail
- SPF TXT record
- DKIM selectors
- DMARC policy
- Autodiscover or mail subdomains if used by your setup
Even if you are only switching the web layer to a new Tomcat host, a DNS mistake can interrupt mail delivery or authentication.
Check the Tomcat and Java configuration
A Tomcat-based application depends on more than just file upload. Before DNS goes live, confirm that the runtime configuration on the new host matches the application requirements.
Match the Java version to the application
One of the most important checks is Java compatibility. Applications built for an older Java runtime may fail on a newer one, and modern applications may require a newer version than the old host provided. Review:
- The Java version required by your application framework
- The version selected in My App Server or the hosting control panel
- Any compilation or runtime warnings in the logs
If you are using a ready-made Tomcat package, confirm that the selected stack supports your deployment. If you uploaded a custom app server version, test it thoroughly before changing DNS.
Check context path and deployment location
Make sure the WAR file or expanded application is deployed to the correct location and that the context path is what you expect. A common issue after migration is the app loading under a different path than before. Verify:
- WAR file name and context name
- Root application mapping
- Any custom context configuration
- Whether the old URL structure is preserved
If your site previously ran at the root domain, confirm that the new host also serves the application from the root and not from a subpath.
Review JVM memory and service limits
Shared Tomcat hosting usually has practical resource limits, and your application should be checked against them before go-live. Review memory settings, thread usage, and any limits documented for the service. If the application works only when it has very high memory allocation or unusually large thread pools, it may not be a good fit for the selected hosting plan.
Look for symptoms such as:
- OutOfMemoryError
- Slow startup time
- Frequent restarts
- Timeouts during initial page load
Validate application dependencies and configuration
Many migration problems are caused not by Tomcat itself, but by forgotten dependencies. Before DNS is updated, check every service or resource your application uses.
Database connectivity
Test all database connections from the new host. Confirm host name, database name, user credentials, and port are correct. If your app uses MySQL, MariaDB, PostgreSQL, or another external database, make sure firewall rules and remote access permissions allow the new host to connect.
Also confirm that database migrations were completed and that the schema version matches the application code. A web application may load but still fail when it reaches a query against an incomplete database.
External APIs and callbacks
If your Java application calls external services, check any API keys, webhook endpoints, and callback URLs. Migration often changes the server IP or host name, which can affect allowlists or signature validation. Common items include:
- Payment gateway endpoints
- Email delivery services
- OAuth redirect URLs
- Webhook receivers
- Third-party CRM or ERP integrations
File permissions and writable directories
Tomcat applications often need write access to specific folders for logs, uploads, cache files, or temporary data. Confirm that all required directories are writable by the service account. If the application uses upload forms or generates documents, test those actions before switching DNS.
Pay special attention to:
- Upload folders
- Temporary folders
- Log directories
- Generated report paths
- Session persistence files, if used
Check SSL and HTTPS readiness
If your site uses HTTPS, SSL must be ready before the DNS change. Users who reach the new host immediately after propagation should see a valid certificate and no browser warnings.
Install and test the certificate on the new host
Confirm that the domain’s SSL certificate is installed on the new environment and matches the hostname users will visit. If the application uses multiple hostnames or subdomains, make sure the certificate covers all required names.
Test the site over HTTPS and verify:
- The certificate is valid and trusted
- The hostname matches the certificate
- There are no mixed-content warnings
- Redirects from HTTP to HTTPS work correctly
Check redirect logic
After migration, old redirect rules may need adjustment. If the application or Apache layer redirects traffic to a specific canonical host, confirm that the destination is the new live domain and not the previous server name or temporary preview address.
Incorrect redirect rules can create loops or send users to the wrong host after DNS updates.
Test the web stack around Tomcat
In many hosting setups, Tomcat works together with Apache. That means you should check both the application server and the web server layer before the DNS switch.
Confirm Apache proxy or handler configuration
If Apache forwards requests to Tomcat, verify that the proxy rules or connector settings are correct. Test whether:
- Static files are served properly
- Dynamic requests reach Tomcat
- Headers are passed as expected
- Client IP and scheme detection work correctly
Misconfigured proxy rules can cause broken login sessions, incorrect redirects, or application URLs that point to the wrong scheme or port.
Check custom headers and rewrite rules
If your application depends on rewrite rules, security headers, or special caching behavior, verify them before go-live. A migration can accidentally leave old .htaccess rules, missing Apache directives, or conflicting configuration files in place.
Make sure rollback is still possible
Good DNS planning includes a rollback option. Before making the final change, ensure you can quickly point traffic back to the old host if an issue appears.
Keep the old host active during propagation
Do not cancel the previous hosting account immediately after changing DNS. Keep the old environment available until you are confident that traffic has fully moved and the new host is stable. This gives you time to catch any missed dependencies or content issues.
Preserve a copy of the old configuration
Save a backup of the old Tomcat configuration, application files, SSL settings, and DNS zone. If you need to compare settings later, having the previous state available can help identify what changed.
Perform final checks on content and functionality
Before switching DNS, walk through the application as a real user would. The goal is to catch any issue that may not be visible from a simple homepage load.
Test key user journeys
Use a checklist that covers the most important parts of the application:
- Login and logout
- Search or filter functions
- Contact or enquiry forms
- File uploads and downloads
- Checkout or transaction pages, if relevant
- Admin or back-office pages
Check for broken links, missing images, layout problems, and unexpected error pages. If the application uses session state, make sure sessions survive normal navigation.
Verify analytics and tracking scripts
If your site uses analytics, tag managers, or conversion tracking, confirm that the scripts still load correctly after deployment. Migration can sometimes change page templates, CSP rules, or JavaScript loading order. Missing tracking is not always a launch blocker, but it is worth checking before the site goes live.
Recommended final checklist before changing DNS
Use this practical checklist just before the cutover:
- The application runs correctly on the new Tomcat host using the temporary host name
- Tomcat service starts and stays stable
- The correct Java version is selected
- WAR files and context paths are correct
- Database connectivity is working
- Uploads, logs, and cache directories are writable
- SSL certificate is installed and valid
- Apache proxy or rewrite rules are correct
- DNS records are reviewed, including A, AAAA, CNAME, MX, SPF, DKIM, and DMARC where needed
- TTL has been lowered in advance if possible
- Rollback plan is ready
- Old hosting remains active during propagation
What to do right after the DNS switch
Once DNS is updated, do not assume the migration is finished. Continue monitoring the application during propagation and test from different networks or devices.
Watch logs and error rates
Check Tomcat logs, Apache logs, and application logs for errors. Look for:
- 404 or 500 responses
- Database connection failures
- SSL or certificate warnings
- Session or authentication errors
- Unexpected redirects
Confirm the correct host is serving traffic
During DNS propagation, some users may still reach the old server while others reach the new one. Make sure both environments are prepared for this period if necessary, especially if you expect traffic overlap. Keep the old site in a safe state, or show a maintenance notice if the content must no longer be edited there.
Common mistakes to avoid
Some issues appear again and again during Tomcat migrations. Avoid these common mistakes:
- Changing DNS before testing the application on the new host
- Forgetting to update the Java version
- Leaving hardcoded URLs inside the application
- Missing database or API access rules
- Ignoring SSL certificate setup
- Overlooking mail-related DNS records
- Removing the old host too early
- Not checking logs after the cutover
FAQ
How can I test a Tomcat site before DNS changes?
Use the temporary hostname, preview URL, or a local hosts file entry if your hosting provider allows it. This lets you open the site on the new server without affecting public DNS.
Should I lower DNS TTL before migration?
Yes, if you can. Lowering TTL a day or two before the switch helps caches expire sooner, which usually makes the new DNS update take effect more quickly.
What if the site works on the temporary URL but not after DNS?
This usually means the application depends on the live domain name, SSL host name, cookie settings, or redirect rules. Check base URLs, virtual host configuration, and any hardcoded references to the old domain.
Do I need to update mail records when moving only the web hosting?
Not always, but you should review them carefully. A web migration should not break email, so confirm that MX, SPF, DKIM, and DMARC records remain correct.
Is it safe to switch DNS immediately after uploading the WAR file?
No. First confirm that Tomcat starts, the app deploys cleanly, database access works, SSL is installed, and the main user journeys are tested. DNS should be the last step, not the first.
How long should I keep the old host available?
Keep it active until you are confident that DNS has fully propagated and the new host is stable. In practice, that often means several days, depending on TTL values and how critical the application is.
Conclusion
Before switching DNS to a new Tomcat host, verify the application, Java runtime, Tomcat service, database access, SSL certificate, and DNS records. For a hosting setup managed through Plesk and My App Server, the safest workflow is to validate everything on the new environment first, then update DNS only when the site behaves correctly under real conditions.
A careful pre-launch check reduces downtime and makes the migration much smoother. If you confirm the key technical points in advance, your Tomcat application is far more likely to go live cleanly and continue working as expected after the DNS change.