If your Tomcat site is still showing content from the old server after a move, the most common reason is that some visitors are still being sent to the previous IP address. In many cases this is caused by DNS propagation, cached DNS records, browser caching, or a host file entry on the client side. For Java applications hosted through Plesk and My App Server, it can also happen when the domain has been switched correctly but the Tomcat service, virtual host, or application deployment is still pointing to the old environment.
The key point is that a DNS cutover does not update the internet instantly for everyone. Some resolvers refresh quickly, while others keep the old record until the TTL expires. During that window, one person may reach the new server while another still lands on the old one. If the old server is still online, the effect can look like the site has not moved at all.
Why the site may still load from the old server
1. DNS propagation is still in progress
When you change an A record, AAAA record, or nameserver delegation, the new value must spread through many DNS resolvers. Until cached records expire, some users will continue to resolve the old IP address. This is normal and can last from a few minutes to longer, depending on the previous TTL and resolver behaviour.
2. The browser or local DNS cache is still holding the old result
Your own computer, browser, or router may keep a cached answer for the domain. If the cache still contains the previous server address, the browser can continue to connect there even after the DNS zone has been updated.
3. The old server is still responding to the same hostname
If the previous server has not been decommissioned yet, it may still serve the domain name. In that case, visitors using stale DNS will see the old content rather than an error. This is especially common during a cautious go-live period when both servers are kept online for a short time.
4. The Tomcat application was deployed only on one server
For Java hosting and Tomcat hosting, the web application must be available on the target environment as well as correctly attached to the domain. If the WAR file or unpacked application was deployed to the new My App Server instance but not removed from the old one, traffic reaching the old IP will still show the previous version.
5. The Apache or proxy layer is still routing to the old backend
In hosting environments where Apache acts as a front end to Tomcat, a misconfigured proxy, virtual host, or rewrite rule can continue forwarding requests to the old backend. Even if DNS is correct, the web server layer can still point to the previous app server if the configuration was copied without updating the target.
6. There is a mismatch between the domain and the Tomcat service setup
With Plesk and My App Server, a domain can be connected to a private JVM or Apache Tomcat instance. If the domain binding was changed but the service control settings were not refreshed, the app may still be associated with the previous service profile or document root.
How to confirm whether DNS is the issue
Before changing anything on the application side, verify where the domain resolves from different networks. This helps separate DNS delay from Tomcat configuration issues.
Check the current public DNS record
Look up the domain from a public resolver and compare the result with the new server IP. If the public A record or AAAA record still shows the old address, the cutover has not fully completed yet.
Test from more than one connection
Use at least two different networks if possible, such as office broadband and mobile data. If one connection reaches the new server but another still reaches the old server, the issue is almost certainly DNS caching or propagation.
Verify the TTL value
The TTL of the old DNS record influences how long caches may keep it. A high TTL before the cutover often leads to longer periods where some users still see the previous server.
Check whether the old IP still serves the site
If you can access the old server directly, confirm whether the website, Tomcat application, or reverse proxy is still active there. If it is, you may want to keep it available only for a short transition period and then shut it down once traffic has moved.
What to check in Plesk and My App Server
For Tomcat hosting through My App Server, a successful DNS change is only one part of the go-live process. The hosting panel also needs to be aligned with the new domain target.
Confirm the domain binding
Make sure the domain in Plesk is attached to the correct application instance. The site should point to the intended My App Server service, not an older Tomcat instance or a shared document root used for testing.
Review the app server status
Open the service control area and confirm that the intended Tomcat or private JVM service is running on the target account. If the new service is stopped or not fully started, requests may fail over to the old location if that one is still live.
Check the deployed application version
If you are deploying a WAR file, confirm that the same build is installed on the new server. A common mistake is to update DNS but forget to deploy the latest artifact to the new environment.
Inspect context path and application root
Tomcat applications may be deployed under a context path such as /app. If the new environment uses a different context path or application root, the old link may still point to the previous server, especially in bookmarks or hardcoded links.
Verify Apache reverse proxy settings
Where Apache fronts Tomcat, ensure that the proxy target references the new backend. A stale proxy pass or virtual host entry can keep sending traffic to the old app server even when DNS is correct.
Step-by-step fix for a Tomcat site that still loads from the old server
Step 1: Confirm the new DNS record is correct
Check the A record, AAAA record, and any CNAMEs involved in the cutover. The domain should resolve to the new server address or to the correct alias if your setup uses one.
Step 2: Lower the risk of stale caching for future changes
If you plan another migration, reduce the TTL in advance before the next switch. A lower TTL does not guarantee instant propagation, but it reduces the time resolvers are allowed to keep the old answer.
Step 3: Clear local caches
Clear browser cache, flush the local DNS cache on your device, and if possible restart the router. Then test again from a fresh session or a private browsing window.
Step 4: Compare old and new server responses
Access both environments directly if you can. Check page headers, application version, timestamps, or a visible deployment marker. This confirms whether the old server is still serving requests or whether the browser is simply showing a cached page.
Step 5: Check the My App Server configuration
In Plesk, confirm that the domain is attached to the right Java hosting instance. Check the Tomcat service, JVM profile, and application deployment settings. If you use a custom app server, verify that it has been started under the new configuration.
Step 6: Remove or isolate the old server after the cutover window
Once you are confident that DNS has fully moved, stop serving the application from the old server. This helps avoid confusion, prevents old sessions from continuing indefinitely, and makes it easier to spot any remaining cache-related traffic.
Common scenarios and what they usually mean
The site works on mobile data but not on office Wi‑Fi
This usually means the office resolver has cached the old record. The site itself is likely fine, but that network has not refreshed DNS yet.
The new server shows the site, but the old server also still shows the site
This indicates both environments are active. During migration this may be intentional, but after go-live it usually means the old server has not been fully retired or the app was copied there as well.
The domain resolves correctly, but the wrong Tomcat application loads
This points to a Plesk or Apache configuration issue rather than DNS. Review the domain binding, proxy settings, and app server assignment in My App Server.
The browser keeps showing an older version even after refresh
That can be caused by browser cache, service worker behaviour, or application-level caching. In Java web apps, also check whether your application caches static assets or templates aggressively.
The site works by IP but not by domain
That usually means the domain name is still tied to the old IP somewhere in DNS, local cache, or host file entries. It can also happen if the web server virtual host for that hostname is not configured correctly on the new machine.
What to do during a safe DNS cutover
A clean Tomcat migration is usually easiest when you keep the old and new environments in sync for a short period. This reduces the impact of DNS caching and gives users a smoother transition.
- Deploy the same application build to the new My App Server instance before the DNS change.
- Lower TTL values ahead of time where possible.
- Test the new server using the temporary hostname or direct IP.
- Switch the DNS record only after the new environment is confirmed working.
- Keep the old server available during the propagation window.
- Monitor logs on both servers to see where requests are still landing.
- After traffic settles, retire the old setup or disable the old vhost.
How My App Server helps in this situation
For small and medium Java hosting setups, My App Server is useful because it gives you direct control over the Tomcat or private JVM instance from Plesk. That makes it easier to verify which service is serving a domain, restart the app server, and deploy updates without managing a separate enterprise stack.
When you are troubleshooting a site still loading from the old server, the main advantage is visibility. You can compare the service control state, the deployed application, and the domain binding in one place. That reduces guesswork during DNS cutover and makes it easier to confirm that the new target is ready before you retire the old one.
Best practices to avoid this problem on future moves
- Plan DNS changes before the actual go-live date.
- Reduce TTL values in advance for the records you will switch.
- Keep the same Tomcat application version on both environments during the transition.
- Document the old and new IP addresses, hostnames, and proxy targets.
- Check the Plesk domain assignment after every move.
- Test from multiple networks before announcing the migration complete.
- Disable or restrict the old server once public traffic has moved.
FAQ
How long can DNS propagation take?
It depends on the previous TTL, the resolver, and local caching. In practice, some users may see the new server quickly while others continue to reach the old one for several hours, and in some cases longer.
Can I force all visitors to see the new Tomcat server immediately?
Not completely. You can shorten future cache duration by lowering TTL before the cutover, but you cannot control every external resolver or cached client. The safest approach is to keep both servers available during the transition.
Why does the site still load from the old server even though the DNS record is updated?
The most likely reasons are cached DNS on the user side, stale resolver data, or the old server still being live and answering requests. If the domain is correct but the wrong application appears, then the issue may be in Plesk, Apache, or the Tomcat deployment.
Should I keep the old server running after the move?
Only for as long as needed to handle cached traffic and verify the change. Once you are confident the domain has fully moved, it is better to stop the old service to prevent confusion and accidental traffic split.
Does this affect JSP and servlet applications too?
Yes. Any application served through Tomcat, including JSP, servlet, and WAR deployments, can show the same behaviour if DNS, proxy settings, or service bindings still reference the previous server.
What should I check first in Plesk?
Start with the domain assignment, then confirm the My App Server instance, service status, and deployed application path. If those are correct, move on to Apache proxy rules and DNS records.
Conclusion
If a Tomcat site is still loading from the old server in the UK market, the problem is usually not the application itself. It is most often DNS propagation, cached records, or a mismatch between the domain and the Java hosting setup in Plesk. By checking the public DNS record, clearing local caches, verifying the My App Server configuration, and confirming that the old server is only kept live for the transition window, you can complete the cutover with less downtime and fewer surprises.
For Tomcat hosting migrations, the safest approach is to treat DNS and the application layer as two separate parts of the move. When both are checked carefully, the new server becomes visible faster, and users are much less likely to be caught between the old and new environments.