If a JSP site is still loading from the old server after a DNS cutover, the most common reason is that not all traffic has actually moved yet. DNS changes can take time to reach every resolver, some devices keep cached records longer than expected, and browsers or proxies may continue to use the old address until their cache expires. In a JSP hosting setup, this can be especially visible when the site is served through Apache Tomcat or a private JVM managed from Plesk, because the application may appear live on the new hosting account while some visitors still reach the previous server.
In most cases, the problem is not that the new JSP host is misconfigured. It is usually a combination of DNS propagation, caching, TTL values, and sometimes application-level links or redirects that still point to the old environment. The goal during go-live is to reduce downtime, but you also need to make sure the old server is not still answering requests for the domain while the DNS change is settling.
Why a JSP site can still resolve to the old server
When a visitor opens your domain, their device does not ask only your hosting platform where the site lives. It first checks several layers of DNS caches before reaching the authoritative record. If any of those layers still hold the old IP address, the browser may continue to load the JSP application from the old server.
Common causes
- DNS propagation is still in progress after changing the A, AAAA, or CNAME record.
- Resolver cache at the ISP, office network, or public DNS service still stores the old value.
- Browser cache or local OS cache is keeping an older lookup.
- TTL was too high before the cutover, so cached records remain valid for longer.
- Hardcoded URLs inside the JSP app still point to the old host, IP, or base URL.
- Redirects or reverse proxy rules on the old server are still sending users back.
- Separate records were not updated, such as www, apex domain, mail-related records, or IPv6 AAAA entries.
If you are using a managed hosting control panel such as Plesk, the DNS zone may be managed in one place, while the Tomcat or Apache service is managed in another. That makes it important to check both DNS and application settings during a cutover.
How DNS cutover works for a JSP hosting platform
For a JSP site, the DNS change usually points the domain to the new server where your Apache Tomcat instance or private JVM is running. The actual application may already be deployed correctly in My App Server, but users will not see it until their lookup resolves to the new IP address.
During the transition, some visitors may reach the new hosting account while others still reach the old one. This is normal for a short period if DNS is still propagating. If the old server remains online and serves the same domain, users may see different versions of the site depending on which resolver they use.
To avoid confusion, it is best to keep the old server available for a limited overlap period, but do not make content changes on both systems independently. The source of truth should be the new JSP hosting environment once the cutover begins.
First checks when the site still loads from the old server
Start with the DNS records and confirm that the domain actually points to the new host. Then check whether the issue is global or local to one network or device.
1. Verify the authoritative DNS record
Check the A record for the domain and the www subdomain, and confirm that they match the new server IP. If you use IPv6, verify the AAAA record as well. A missing or outdated AAAA record can send some users to the wrong place even when IPv4 is correct.
2. Check whether the old server still answers the domain
If the old server is still configured with the same virtual host or domain binding, it may continue to serve the website even after DNS has changed. This is often the case when the old account has not been disabled yet. If possible, remove the domain from the old server after the cutover is complete.
3. Test from multiple networks
Use different connections, such as mobile data, office network, and home network. If the site loads from the new server on one network but not another, the issue is likely DNS caching at the resolver level rather than a problem in Tomcat or Plesk.
4. Clear local cache
On your own device, clear the browser cache and flush the local DNS cache if needed. This does not solve global propagation, but it helps rule out a local caching issue.
5. Compare the IP being returned
Use a DNS lookup tool or command-line lookup to see which IP address the domain returns. If you still see the old address, the record has not fully updated or the resolver has not refreshed yet.
What to check in Plesk and My App Server
In a JSP hosting environment managed through Plesk and My App Server, the application may be correctly deployed but the domain routing may still be incomplete. That is why both the hosting service and the DNS zone must be reviewed together.
DNS zone in Plesk
Confirm that the domain zone contains the correct records for the new server:
- A record for the root domain
- A record or CNAME for www
- AAAA record if IPv6 is in use
- Any required subdomains used by the application
If the zone is managed externally, make sure the changes were made at the registrar or DNS provider, not only inside the hosting panel.
Tomcat or private JVM configuration
Inside My App Server, confirm that the application is running on the expected Java version and Tomcat instance. A site can appear to load from the old server if the new environment is incomplete, stopped, or bound to the wrong hostname.
- Check that the Tomcat service is running
- Confirm that the WAR or JSP application is deployed
- Verify the application context path
- Check whether the app uses absolute links to the old host
- Review any custom connector or port settings
If the application is using a private JVM, make sure the JVM service is started and the service control settings are correct. A DNS change alone does not move the application if the runtime is not active on the new host.
Apache integration
In many JSP hosting setups, Apache acts as the front end and forwards requests to Tomcat. If Apache still has old virtual host rules, rewrite rules, or proxy settings, users may be routed to the wrong backend even after the DNS records have changed. Confirm that the Apache configuration aligns with the new application server setup.
How to reduce downtime during a DNS cutover
The best way to avoid a long period where the site appears to load from the old server is to plan the cutover carefully. DNS changes are rarely instant, but you can shorten the impact window.
Lower TTL before the move
Reduce the TTL for the relevant records ahead of time, ideally a day or more before the migration. This helps resolvers refresh sooner when you switch the records to the new host. If the TTL remained high, users may keep seeing the old server for much longer.
Keep content synchronized
For a JSP application, make sure the same code, configuration, and content are available on the new server before switching DNS. If the app depends on sessions, uploaded files, or database settings, confirm that those dependencies are ready too. The site should behave consistently no matter which server a visitor reaches during the transition.
Use a staged cutover
Point a test subdomain first if possible. This lets you validate the new Tomcat or private JVM setup before moving the main domain. Once you are satisfied, update the production records.
Keep the old server in read-only mode if needed
If you cannot remove the old server immediately, reduce the chance of conflicting changes. For example, stop content edits on the old environment and let the new JSP host become the only place where updates are made.
Monitor both servers during the transition
Check access logs on both the old and new host. If requests are still reaching the old server after the DNS change, that confirms propagation or caching is still in progress. If all traffic keeps going to the old server, the DNS record may not have been updated correctly.
Application-level reasons the old server still appears active
Sometimes the browser reaches the new server, but the application behaves as if it is still on the old one. This usually means some part of the JSP app still contains old environment details.
Absolute URLs in JSP pages
If pages, scripts, forms, or redirects contain hardcoded links to the old domain or IP address, users may be sent back there even after the cutover. Use relative URLs when possible, or update all absolute references in the application.
Session or cookie domain settings
Cookies tied to the old domain setup may create strange behavior during migration. If the domain name stays the same, this is less of an issue, but if subdomains or environment names changed, review cookie scope and session configuration.
Database or API endpoints
The JSP app may still call services that are hosted on the old server. Even if the web root is on the new host, back-end requests can create the impression that the site itself is still old. Update environment variables, connection strings, and integration endpoints as part of the go-live process.
Practical troubleshooting steps
Use the following sequence to isolate the issue quickly.
- Check the domain’s A and AAAA records and confirm they point to the new hosting account.
- Look at the TTL and estimate whether cached records may still be valid.
- Test the domain from a different network or device.
- Confirm that the old server is no longer bound to the domain.
- Verify that Apache Tomcat or the private JVM is running on the new host.
- Check the Plesk DNS zone and web hosting settings for the domain.
- Inspect the JSP application for hardcoded URLs or redirects to the old host.
- Clear browser and local DNS cache for your own testing.
If the problem only affects specific users or regions, the issue is most likely cached DNS data outside your control. If everyone sees the old server, the domain likely still points there or the old server still answers for that hostname.
What to do if the old server must stay online temporarily
There are cases where the previous server cannot be shut down immediately. In that situation, make sure it does not continue to serve the production site indefinitely.
- Keep the old server available only during the propagation window
- Do not continue deploying new changes there
- Review redirects so they do not send traffic back to the old host
- Confirm that SSL certificates are valid on the new destination
- Remove obsolete virtual host entries once traffic has moved
When a JSP hosting platform uses a separate Tomcat service, it is safer to retire the old runtime after the cutover than to leave both live with the same domain configuration for too long.
FAQ
How long can DNS propagation take?
It depends on the TTL values, recursive resolver caches, and how often the relevant networks refresh their records. Some users may see the new server within minutes, while others may continue reaching the old one for several hours.
Why does the site load correctly on my phone but not on my office network?
Your phone and office network may use different DNS resolvers. One resolver may have already refreshed to the new IP, while the other is still caching the old record.
Can Plesk force the old server to stop serving the domain?
Plesk can help you remove or disable the domain binding on the old host, but it cannot control external DNS caches. If the old IP is still cached elsewhere, some users may still reach the old server until the cache expires.
What if the JSP app still redirects to the old URL?
Check the application configuration, context path, and any hardcoded redirect rules. Also review Apache and Tomcat rewrite settings. A redirect in the app can cause traffic to return to the old host even after DNS is correct.
Does changing the nameserver fix this immediately?
No. Changing nameservers also depends on DNS propagation and cache refresh. It can take time before every resolver recognizes the new authoritative DNS provider.
Should I keep the old Tomcat instance running during cutover?
Only for a short overlap period if necessary. Once the domain has moved and you have confirmed that traffic is reaching the new JSP hosting environment, it is best to retire the old instance to avoid conflicting responses.
Conclusion
If a JSP site is still loading from the old server after go-live, the cause is usually DNS caching, incomplete record updates, or leftover application settings rather than a fault in the new hosting platform. In a Plesk-based Java hosting setup with My App Server, you should check DNS records, the Tomcat or private JVM service, Apache routing, and the JSP application itself. A careful DNS cutover with lower TTL, synced content, and validation from multiple networks will usually resolve the issue quickly and reduce downtime.
For the smoothest result, always verify both sides of the migration: the domain must point to the new host, and the new JSP environment must be fully ready to serve the application. When those two parts are aligned, the old server should stop appearing shortly after DNS caches expire.