Why is a Java site still loading from the old server in the UK

If a Java site still loads from the old server after you have changed DNS, the most common cause is that some part of the traffic is still resolving to the previous IP address. In a typical cutover, the domain, subdomain, or a related hostname may still be cached by resolvers, browsers, local devices, or even by the application itself. For Java and Tomcat-based sites, this can also happen when the web application is moved to a new Plesk subscription but the DNS record, virtual host, or application endpoint has not been fully updated yet.

In a managed hosting setup, the fastest way to diagnose the issue is to check the DNS record that your visitors actually use, confirm the active A/AAAA records, review TTL values, and verify that the new server is serving the expected site on the correct hostname. If your Java application runs on a private JVM or Apache Tomcat instance through the My App Server extension in Plesk, it is also important to confirm that the application is deployed on the new hosting account and that the web root or reverse proxy target points to the correct local service.

Why this happens during a DNS cutover

When you move a Java site to a new hosting platform, DNS changes do not switch traffic instantly for every visitor. DNS information is cached at multiple levels, and each cache may keep the old address for its own lifetime. As a result, some users may already see the new server while others still reach the old one.

The most common reasons are:

DNS propagation delay — recursive resolvers are still using the old record until the TTL expires.
Browser or operating system cache — the client device keeps an older resolution.
Incorrect record updated — the main domain was changed, but www, a subdomain, or an API hostname still points to the old IP.
AAAA record mismatch — IPv6 traffic can still go to the old server if the IPv6 record was not updated.
Nameserver mismatch — the domain is edited in one DNS zone, but the domain is delegated to another nameserver set.
CDN or proxy cache — a front layer is still routing to the old origin.
Application-level redirect or hardcoded endpoint — Java app configuration still references the old host, port, or callback URL.

What to check first when a Java site still loads from the old server

Start with the simplest checks before moving to server-side troubleshooting. In many cases, the issue is not with the Java application itself but with DNS or hostname consistency.

1. Confirm which hostname is still pointing to the old server

Test the exact hostname that visitors use. A site may load correctly on the root domain but still use the old server on www, app, api, or another subdomain.

Check the following separately:

example.com
www.example.com
Any Java app subdomain such as app.example.com
Callback or integration hostnames used by payment, SSO, or API clients

If only one hostname is outdated, update that DNS record in the active DNS zone.

2. Verify the current A and AAAA records

For most website cutovers, the A record is the main record that points the hostname to the new IPv4 address. If you use IPv6, the AAAA record must also be updated. Leaving an old AAAA record in place can cause some users or networks to reach the old server even when the IPv4 address is correct.

Make sure that:

The A record points to the new server IP.
The AAAA record also points to the new server, or is removed if IPv6 is not in use.
There is no conflicting CNAME or extra A record for the same hostname.

3. Check the authoritative nameservers

If the domain uses external DNS, make sure you are editing the zone on the authoritative nameservers. Updating DNS in the hosting control panel does not help if the domain is delegated somewhere else.

In a managed hosting environment, confirm that:

The registrar points to the correct nameserver set.
The DNS zone is active on the nameservers that the domain actually uses.
The same record has been updated everywhere needed.

4. Review TTL values before and after the move

TTL, or Time To Live, controls how long DNS resolvers may cache the record. A high TTL can slow cutover. If you plan a migration, it is usually wise to lower the TTL in advance, wait for the old TTL to expire, and only then switch the record to the new IP.

Useful practice:

Lower TTL 24 to 48 hours before the planned move.
Use a short TTL during the transition.
Restore a normal TTL after the migration is stable.

How DNS caching can make the old server appear active

Even after the DNS zone has been changed correctly, users may still see the old server because of cache. This does not always mean something is broken. It often means the internet is still converging to the new target.

Typical cache layers include:

Recursive resolvers used by ISPs, companies, or public DNS services
Local operating system cache on the visitor’s machine
Browser cache for DNS or content
Corporate proxy or security gateway
Mobile network DNS cache

If some devices already use the new server while others still use the old one, that usually confirms a propagation or cache issue rather than an application fault.

Java and Tomcat-specific reasons the old server still appears

When the site runs on Java, JSP, or Tomcat, the cutover can involve both DNS and application configuration. A hostname can resolve correctly but still show content from the old environment if the app stack is not aligned.

Tomcat or private JVM not deployed on the new account

If you moved the domain but did not install the Java application on the new Plesk subscription, the request may still reach the old host if the DNS record has not fully switched, or the new server may return a default page. With My App Server, make sure the application is installed on the new hosting account and that the expected Tomcat or private JVM instance is active there.

Old virtual host or binding still in place

A Java site can depend on the correct hostname binding. If the new server hosts multiple domains, the wrong virtual host can answer the request and make it look like the old site is still active. Confirm that the domain is mapped to the correct Plesk subscription and that the Java app is attached to the right host header.

Hardcoded base URL in the application

Some Java applications generate absolute links, redirects, SSO callbacks, or API URLs using a configured base address. If that value still points to the old server name or IP, the browser can be sent back to the previous environment even after DNS has changed.

Review settings such as:

Application base URL
Redirect URIs
Callback endpoints
Session cookie domain settings
External service endpoints

Tomcat context path or deployment artifact mismatch

If you deploy a WAR file or use a custom context path, the new server may be serving a different path than expected. In that case, visitors think they reached the old site because the content or login flow does not match the new environment. Check the deployed artifact, context path, and version in the My App Server interface.

Step-by-step checklist to fix the cutover

Use this checklist to narrow down the cause and complete the migration with less downtime.

Identify the exact hostname that still resolves to the old server.
Check the current DNS records for A, AAAA, CNAME, and any related subdomains.
Confirm the authoritative DNS zone is the one you edited.
Reduce TTL before future moves, if you have not already.
Verify the new server IP matches the updated records.
Remove outdated AAAA records if IPv6 is no longer used.
Confirm the Java app is installed in the correct Plesk subscription.
Check the My App Server / Tomcat service status and application deployment.
Inspect redirect rules in the app, Apache, or Plesk configuration.
Test from a different network or a DNS lookup tool to see whether the old IP is still returned.

How to test whether DNS is still sending traffic to the old server

You can validate the cutover by comparing the IP address returned by DNS with the actual server response. The goal is to determine whether the client is still resolving the old address or whether the new server is forwarding, redirecting, or proxying requests back to the old environment.

Useful tests include:

Check the hostname from more than one network.
Compare the DNS response from different resolvers.
Open the site in a private browser session.
Flush local DNS cache on your device if needed.
Use the hosting control panel or server logs to see which hostname is being requested.

If your hosting setup provides access to logs, verify whether the incoming request reaches the new server at all. If there are no hits in the new environment, DNS or cache is still the likely issue. If there are hits but the content is wrong, the problem is probably application-level.

What to check in Plesk and My App Server

For Java hosting on a shared hosting platform, Plesk and the My App Server extension provide the practical controls needed for a smooth transition. When the site still appears to load from the old server, check the new hosting account for the following:

The domain is added to the correct subscription.
The Java application is installed or imported in My App Server.
The selected Java version matches the application requirements.
The Tomcat or private JVM service is running.
The deployed WAR, JSP, or servlet application is in the expected path.
Apache or the web server is configured to route the hostname correctly.
No stale redirect rules point back to the old domain or IP.

If you use custom app server settings, review them carefully after the move. A misconfigured port, context path, or service binding can make the new server appear unavailable even though DNS is already correct.

How to avoid this problem in future migrations

Planning the cutover properly can reduce the chance of visitors reaching the old server.

Lower TTL before the migration.
Verify both A and AAAA records.
Keep the old server online for a short overlap period.
Make sure the new Java application is deployed and tested before the DNS change.
Test all important hostnames, not only the main domain.
Review redirects and application URLs inside Tomcat and the Java app.
Confirm the correct site is assigned in Plesk before going live.

For Java applications, it is often helpful to prepare the new Tomcat or private JVM instance first, deploy the application, test it through a temporary hostname or hosts-file override, and only then switch public DNS. This reduces downtime and makes it easier to identify whether any issue is DNS-related or application-related.

When the old server should be kept online temporarily

In a normal migration, keeping the old server available for a short period can help users whose DNS has not fully updated yet. This is especially useful when the site has sessions, login flows, or external integrations that may still be reaching cached addresses.

Keep the old environment running briefly if:

You expect DNS propagation to take time.
The application uses cached callbacks or scheduled jobs.
Users may already have active sessions.
Third-party services still need time to refresh DNS.

Once traffic has fully moved and logs confirm the new server is serving requests reliably, you can retire the old server.

FAQ

Why do some users see the new Java site and others still see the old one?

This usually means DNS propagation is still in progress or some resolvers are caching the old IP. It can also happen if one hostname was updated and another was not.

How long can DNS cutover take?

It depends on the TTL and the caches involved. Some users switch quickly, while others may keep the old result until the cache expires. Lower TTL values help the transition happen faster.

Can an AAAA record keep sending traffic to the old server?

Yes. If IPv6 is enabled and the AAAA record still points to the old address, some clients may continue to reach the old server even if the A record is correct.

What if the browser shows the old site even after DNS is correct?

Check browser cache, local DNS cache, and any redirect rules in the application. Also verify that the new server is hosting the correct virtual host and Java application.

Does My App Server change DNS automatically?

No. My App Server helps you install and manage Java applications, Tomcat, and private JVM services through Plesk, but DNS records still need to be updated in the correct DNS zone or on the authoritative nameserver.

Can a Java app redirect users back to the old server?

Yes. Hardcoded base URLs, callback endpoints, or old redirect rules can send users back to the previous environment even after the DNS cutover is complete.

Conclusion

If a Java site still loads from the old server after a move, the issue is usually one of three things: DNS has not fully propagated, the wrong hostname or record was updated, or the Java/Tomcat application still contains old server references. In a Plesk-based hosting setup with My App Server, the practical fix is to verify DNS records, confirm the authoritative nameservers, check both IPv4 and IPv6 settings, and make sure the Java application is deployed and bound to the correct domain on the new account.

Once the DNS zone, web server, and Java runtime are aligned, traffic should move cleanly to the new server with minimal downtime. For future go-live changes, lower TTL in advance, test all hostnames, and keep the old environment online briefly until the cutover is fully stable.

Why is a Java site still loading from the old server in the UK?