If your JSP site is still opening from the old server after a planned cutover, the cause is usually one of a few common DNS, cache, or application-routing issues. In many cases the new hosting account is already working correctly, but visitors, browsers, or intermediate DNS resolvers are still being sent to the previous IP address. For JSP and Tomcat-based sites, it is also possible that Apache, Tomcat, or a proxy layer is still pointing to the old backend even after the domain itself has been changed.
During a go-live change, you should always check the full path from the domain name to the application: authoritative DNS, TTL values, local resolver cache, browser cache, and the hosting control panel configuration. If you are using a managed hosting platform with Plesk and a Java hosting extension such as My App Server, the domain may be correctly added to the new account, but the site can still appear on the old server while some DNS records or application settings continue to resolve there.
Why a JSP site can keep loading from the old server
JSP applications depend on both DNS and the application runtime. Unlike a simple static site, a JSP site can involve Apache, Tomcat, a private JVM, proxy rules, and virtual host mappings. If any part of that chain is still set to the old environment, users may continue to see the old site even after the intended migration.
Common reasons
- DNS propagation is still in progress and some resolvers have not picked up the new IP address yet.
- TTL values were high, so caches are keeping the old DNS answer for longer than expected.
- The domain’s A or AAAA record still points to the old server for some hosts or subdomains.
- Browser or operating system DNS cache is showing an older answer locally.
- Apache virtual host or proxy settings on the old server are still serving the domain.
- Tomcat or My App Server configuration is still bound to the previous hostname, context path, or deployment location.
- There is a mixed setup where www and non-www, or the root domain and subdomain, point to different places.
- IPv6 records are still old, while the IPv4 record has already been updated, or the other way around.
First check: is the old server really serving the site, or is it just cached?
Before changing anything, confirm whether the browser is seeing a real live response from the old server or simply showing cached content. This is important because the fix is different in each case.
Quick checks you can do
- Open the site in a private or incognito window.
- Test from another network, such as mobile data, to avoid your local cache.
- Use a DNS lookup tool to check the current A and AAAA records for the domain.
- Compare the public IP returned by DNS with the IP assigned to the new hosting account.
- Try both the root domain and the www version.
- Check whether the application responds differently when you use the direct server hostname or IP.
If the site only appears old on one device or one browser, the issue is likely cache-related. If everyone sees the old site, the domain or proxy path is still pointing to the previous server.
How DNS cutover works for JSP hosting
For a JSP site, the DNS cutover usually means updating the domain to point to the new hosting account, then allowing time for recursive resolvers across the internet to refresh their cached records. This may sound simple, but the time needed depends on the TTL values set before the change and on how often different DNS resolvers refresh their data.
When the TTL was lowered in advance, the switch should complete much faster. If the old TTL was still long, some visitors may continue to hit the previous server for hours, and occasionally longer in edge cases. That is why a good go-live process is to reduce TTL ahead of the migration, move the application, verify the new server, and only then update the public DNS records.
Records to review during cutover
- A record for the root domain.
- AAAA record if IPv6 is enabled.
- CNAME record for www if it points to the root or another hostname.
- MX records if mail is hosted elsewhere and the zone is being edited.
- TXT records for SPF, DKIM, DMARC, or domain verification.
A common mistake is updating the main A record while leaving the www CNAME or the AAAA record unchanged. If only one record is updated, some visitors may go to the new server and others may still hit the old one.
Check the Plesk and Apache side as well
If your hosting platform uses Plesk, the domain must be correctly assigned in the control panel and the web server must know which site it should serve. For JSP hosting, Apache often sits in front of Tomcat and forwards requests to the application runtime. That means the domain can be visible in DNS, but the server can still answer from an older virtual host or proxy rule.
What to verify in the control panel
- The domain is added to the correct subscription or hosting account.
- The document root is set to the intended application location.
- The domain alias, if used, points to the right primary host.
- Apache and proxy settings are aligned with the active site.
- The Tomcat or My App Server instance is attached to the right domain or application path.
- The deployed WAR or JSP application has been uploaded to the new account.
If you are using My App Server, check that the Java application service is running in the target hosting account and that the correct Tomcat version or private JVM has been installed. A site may appear to be “still on the old server” when the new environment is actually available, but the app has not been deployed there yet.
Step-by-step troubleshooting checklist
Use the checklist below to identify why the JSP site is still resolving to the old server.
1. Confirm the new server is ready
- Confirm the domain exists in the new hosting account.
- Check that the JSP application files or WAR package are deployed.
- Confirm Tomcat or the private JVM is running.
- Test the application locally from the new server where possible.
2. Verify DNS records
- Look up the current A and AAAA records for the domain.
- Compare them with the IP address of the new hosting account.
- Check www, non-www, and any relevant subdomains separately.
- Make sure old records were removed if they are no longer needed.
3. Review TTL values
- Check whether the TTL was lowered before the migration.
- If not, expect some resolvers to keep the old value for longer.
- After the change, allow enough time for caches to refresh.
4. Flush local caches
- Clear browser cache or test in a private window.
- Flush OS DNS cache on your computer if needed.
- Test from a second device and a different network.
5. Check web server routing
- Review Apache virtual host configuration.
- Check any reverse proxy or frontend mapping.
- Verify that the correct domain is mapped to the correct backend.
- Confirm that the old server is no longer answering for the domain.
6. Check Tomcat or My App Server deployment
- Make sure the application was deployed to the new Tomcat instance.
- Confirm the context path is correct.
- Check whether the application uses environment-specific configuration.
- Restart the service only if required by your platform’s guidance.
Special cases that often cause confusion
WWW and non-WWW point to different places
It is common for the root domain and the www hostname to be configured separately. If one points to the new server and the other still points to the old one, visitors may report inconsistent results. Always test both hostnames during and after the cutover.
IPv4 is updated but IPv6 still points to the old server
If your domain has an AAAA record, some clients may prefer IPv6. In that case, they can continue reaching the old server even when IPv4 is already correct. Review both record types together.
Old proxy or load balancer rules are still active
If the old server had Apache proxy rules or a frontend forwarding setup, those rules may still be accepting requests for the domain. Remove or disable them once the cutover is complete.
Tomcat is deployed, but the app was not moved
In JSP hosting, the runtime and the application are separate concerns. A new Tomcat or private JVM may be installed correctly, but the actual application files, configuration, or database connection settings may still be tied to the old environment. This can make the site look like it is loading from the old server when, in fact, the new runtime is not yet serving the live version.
Best practice for a clean go-live
To reduce downtime and avoid DNS confusion, use a structured migration process.
Recommended process
- Lower DNS TTL ahead of the planned switch.
- Prepare the new hosting account, Java runtime, and application deployment.
- Test the JSP site on the new server using temporary access or hosts-file testing if appropriate.
- Verify Apache, Tomcat, and My App Server settings in Plesk.
- Update the DNS records to the new IP address.
- Monitor traffic, logs, and DNS resolution during propagation.
- Keep the old server available briefly if needed, but do not make changes there once the new site is live.
This approach helps prevent split traffic, stale responses, and accidental edits on the wrong server.
What to do if the site is still loading from the old server after 24 hours
If the domain still resolves to the previous server after a full day, the issue is usually not normal DNS propagation anymore. At that point, the problem is more likely to be one of the following:
- The DNS zone was not changed at the authoritative nameserver.
- One or more records were missed during the update.
- The registrar is still using old nameservers.
- The hosting platform is serving the old virtual host configuration.
- A cached resolver is being used by the client network, especially in corporate environments.
Check the authoritative DNS records directly, not just third-party lookup tools. If the authoritative zone is correct but the result still looks wrong, inspect the domain configuration in Plesk and the Apache/Tomcat routing on the new account. If needed, ask support to confirm which backend is currently answering requests for the hostname.
Practical examples
Example 1: The root domain is correct, but www is old
You update example.co.uk to the new IP, but www.example.co.uk still has an old CNAME. Visitors using the www address continue to see the old server. The fix is to update both records consistently.
Example 2: The browser shows old content, but DNS is already updated
A local browser cache or DNS cache is storing the old response. When you test from a mobile connection or private window, the site loads from the new server. In this case the cutover is working and the problem is local caching.
Example 3: The domain points correctly, but the app is still old
The DNS record is correct and the new server is active, but the WAR file was not deployed to the new Tomcat instance. The domain reaches the new host, yet the application content is still the previous version. Deploy the current application package and verify the context path.
FAQ
How long should DNS cutover take for a JSP site?
It depends on the TTL values and resolver caching. If TTL was reduced beforehand, the change may be visible within minutes to a few hours. If the TTL was high, some visitors may keep seeing the old server longer.
Why do some users see the new site while others still see the old one?
That usually means DNS propagation is incomplete or different resolvers are caching different answers. It can also happen when IPv4 and IPv6 records are not aligned.
Can browser cache make it look like the old server is still live?
Yes. Browser cache, DNS cache, and even proxy caches can make a site appear unchanged. Always test from an incognito window and from another network.
Does Plesk automatically move a JSP application when the DNS changes?
No. DNS only controls where the hostname points. The application still needs to be present in the new hosting account, with the correct Apache and Tomcat configuration.
What should I check in My App Server?
Confirm that the Java service is installed, started, and attached to the correct domain or application path. Also verify that the correct Tomcat version or private JVM is selected and that the application is deployed in the new account.
Can the old server still answer requests after DNS is updated?
Yes, for a short period, if caches still hold the old record. It can also happen longer if the old hostname, proxy, or virtual host settings were not removed properly.
Conclusion
If a JSP site is still loading from the old server after cutover, the root cause is usually DNS caching, an incomplete DNS record update, or a lingering Apache/Tomcat routing setting. For JSP hosting and Java hosting on a managed platform, always check both the public DNS side and the application side in Plesk or My App Server. A clean go-live requires the domain, web server, and Java runtime to point to the same active environment.
When in doubt, compare the authoritative DNS records with the new server’s IP, test both www and non-www, verify IPv4 and IPv6, and confirm that the JSP application has actually been deployed to the new Tomcat instance. That sequence solves most cases quickly and helps you complete the migration with less downtime.