If you are planning a JSP migration on a managed hosting platform, the right time to change DNS is usually when your new Tomcat or Java application is fully deployed, tested, and ready to receive live traffic. In most cases, the safest approach is to keep the current DNS records in place until the new JSP site on My App Server is working correctly, then lower the TTL in advance and switch the DNS only during the final cutover window. This reduces downtime and gives you a clean rollback path if anything unexpected happens.
For UK businesses migrating JSP, Servlet, or WAR-based applications, DNS cutover is often the last step in the go-live process, not the first. If you change DNS too early, visitors may be directed to the new host before the application, virtual host, SSL certificate, or database connection is ready. If you wait too long, both old and new environments may stay active longer than necessary, which can create data sync issues or split traffic. The key is to match DNS timing with the readiness of your Java hosting environment, your Apache Tomcat setup, and your planned validation process.
When to change DNS during a JSP migration
Change DNS only after the new JSP application has been installed, configured, and verified on the target hosting account. In a typical Plesk-based hosting setup with My App Server, that means the following should already be in place:
- Tomcat or your private JVM is installed and running correctly.
- The JSP application has been deployed and starts without errors.
- Required environment variables, context path, and servlet mappings are correct.
- Database connections, API endpoints, and file permissions have been checked.
- HTTPS is configured and the correct SSL certificate is ready for the live domain.
- The application has been tested using a temporary URL, preview host, hosts-file override, or staging subdomain.
If any of these items are still incomplete, the DNS change should wait. DNS cutover is not the place to debug Java classpath issues, missing libraries, or Tomcat startup errors. Those should be resolved beforehand in staging or in a test environment inside the same control panel structure.
Best practice: prepare DNS before the cutover
To make the migration smoother, prepare DNS several hours or even a few days before go-live. The most common step is reducing the TTL for the relevant records, such as the A record, AAAA record, or CNAME record, depending on how your domain is set up. Lowering the TTL in advance helps DNS changes spread faster when you finally switch traffic.
A practical approach is:
- Review the current DNS zone and identify the records used by the live JSP application.
- Reduce TTL values ahead of migration, typically 300 seconds or another low value that fits your plan.
- Verify the new Tomcat application on the target server using a temporary URL or test host.
- Check that SSL, redirects, and canonical hostnames behave correctly.
- Schedule the DNS update for a quiet period with low user activity.
- Monitor traffic, logs, and application health after the cutover.
This is especially useful in a managed hosting environment where you want to avoid a long propagation window. A lower TTL does not guarantee instant DNS updates everywhere, but it usually shortens the transition and makes go-live more predictable.
How DNS cutover fits a JSP migration
In a JSP migration, DNS is the final routing layer that points the public domain to the new hosting platform. The application itself may already be deployed to My App Server, Tomcat, or a private JVM inside the account, but users will not see it until the domain resolves to the new origin.
Typical migration flow:
- Build and test the application on the new platform.
- Confirm the Java version and Tomcat version you need.
- Upload the WAR or application files and configure the context.
- Test the app using a staging URL or temporary hostname.
- Lower DNS TTL before the cutover.
- Change DNS when you are ready to switch public traffic.
- Monitor the live domain and fix any post-migration issues.
For JSP hosting, it is common to test several layers before changing DNS: the web server, the servlet container, session behavior, database connectivity, and static assets. If any part fails after DNS is changed, users may see partial functionality or inconsistent pages. That is why the DNS switch should happen only after the application is effectively production-ready.
What to verify before changing DNS
1. The Tomcat service is healthy
If you are using My App Server in Plesk, confirm that your Tomcat or Java service is running normally and that the service control panel shows no errors. A JSP application can appear installed but still fail at runtime if the service is stopped, misconfigured, or using the wrong Java version.
2. The correct Java version is selected
Many JSP and servlet applications depend on a specific Java runtime. Before you update DNS, make sure the application has been tested on the same Java version that will be used in production. If you are using a ready-made Tomcat version or a manually uploaded custom app server, verify compatibility carefully.
3. The domain and vhost mapping are correct
Check that the live hostname, subdomains, and aliases point to the right application context. A common migration problem is a successful DNS update that still lands on a web server without the correct virtual host mapping. In Plesk, domain bindings and Apache/Tomcat routing should be reviewed before go-live.
4. SSL is ready
If the site uses HTTPS, install or renew the certificate before the DNS change. When DNS is switched, visitors may hit the new server immediately, so the certificate must already match the hostname. This is important for login pages, checkout flows, and any JSP app that uses secure sessions.
5. Static and dynamic resources work together
JSP applications often serve static files through Apache and dynamic content through Tomcat. Make sure images, CSS, JavaScript, uploads, and endpoint URLs all resolve properly after migration. DNS cutover should not be used as a fix for broken resource paths.
Recommended timing for UK go-live
For UK traffic, a common and sensible pattern is to schedule the DNS change during a low-traffic period for your audience. That may be early morning, late evening, or another quiet window based on your own analytics. The best time is not necessarily the same as the best time for your technical team; it should also consider customer activity, business hours, and support availability.
Choose a time when:
- Your support team is available to monitor the change.
- Database or content freezes are in place if needed.
- Rollback can be performed quickly if the app misbehaves.
- You can watch logs, response codes, and login flows in real time.
If your JSP application is transactional, such as an internal portal, booking system, or customer dashboard, avoid changing DNS during peak use. Even a short propagation period can create confusion if some users reach the old environment and others the new one.
How to reduce downtime during DNS change
DNS cutover is rarely instant everywhere, but you can reduce visible downtime by planning carefully.
- Lower TTL values well before migration.
- Keep the old environment available until the new one is confirmed stable.
- Use a temporary maintenance page only if necessary, and keep it consistent.
- Freeze content changes during the migration window if your app stores data.
- Test the new site through direct server access before switching public DNS.
- Monitor server logs, application logs, and error pages after the update.
In a managed hosting or Plesk environment, you may also be able to check the application at the server level before the domain fully points to it. That gives you a safer validation step than waiting for public DNS to propagate.
How My App Server helps with JSP migration
If your hosting platform includes My App Server, the migration process is usually simpler because you can manage Java hosting from the control panel rather than building the environment manually. This is useful for JSP hosting, Tomcat hosting, servlet hosting, and small to medium Java applications.
Typical advantages include:
- Controlled deployment of a private JVM within the hosting account.
- Simple installation of available Tomcat or Java versions.
- Support for custom app server setups where needed.
- Service control from the control panel.
- Easy testing before DNS cutover.
- Clear separation between the web hosting layer and the Java application layer.
This model is practical when you need to migrate a JSP site without moving to a complex enterprise architecture. It fits application workloads where you want direct control over the Java runtime, but you do not need heavyweight cluster management or advanced enterprise application server features.
Step-by-step DNS change checklist for JSP go-live
- Confirm that the target hosting account is ready in Plesk.
- Install or verify the correct Tomcat/Java version in My App Server.
- Deploy the JSP application and complete internal testing.
- Check logs for startup errors, missing classes, and configuration problems.
- Prepare SSL for the live hostname.
- Lower the TTL on the existing DNS records ahead of time.
- Document the current DNS values so you can roll back if required.
- Schedule the DNS change during a monitored low-traffic window.
- Update the A, AAAA, or CNAME records to the new destination.
- Verify the site from multiple networks and devices.
- Check application login, forms, session handling, and key pages.
- Watch for 404, 500, redirect loop, and certificate issues.
Common mistakes to avoid
Changing DNS before the application is tested
This is the most common mistake. If the app has not been verified on the new Tomcat environment, the DNS change may expose users to errors immediately.
Forgetting to reduce TTL
If the TTL is still high, some users may continue reaching the old host for much longer than expected. That can make cutover inconsistent and harder to troubleshoot.
Not checking SSL before go-live
A valid DNS record does not guarantee a valid certificate. If HTTPS is not ready, browsers may warn users or block access.
Leaving the old and new systems unsynchronised
If content, sessions, or database writes are still flowing to both sides, you may see data mismatch after the switch. Plan a clear freeze or synchronization strategy.
Ignoring Apache and Tomcat routing
In many JSP deployments, the public request reaches Apache first and is then passed to Tomcat. If this path is misconfigured, the site may resolve by DNS but still fail at the application layer.
Rollback plan if the cutover fails
Always keep a rollback plan ready before changing DNS. The simplest rollback is to restore the previous DNS record values, provided the old environment is still available and has not been changed or decommissioned.
Your rollback checklist should include:
- Previous DNS values saved in advance.
- The old hosting environment kept active for a short transition period.
- Access to both the old and new control panels or server setups.
- A way to confirm which version of the site users are seeing.
- A decision point for when to abandon the cutover and revert.
If the issue is application-level rather than DNS-level, changing DNS back may not solve the underlying problem, but it can quickly restore service while you investigate.
FAQ
Should I change DNS before or after deploying the JSP application?
After deploying and testing the JSP application. DNS should be the last step in the migration once the new Tomcat or Java setup is ready for live traffic.
How long before go-live should I lower TTL?
Ideally, lower TTL several hours to a day before the cutover, and sometimes earlier if your DNS provider or migration plan needs more buffer. The goal is to make the final switch propagate faster.
Can I test the new JSP site without changing DNS?
Yes. You can usually test it using a temporary URL, hosts-file override, preview domain, or another controlled method in your hosting setup before the public domain is pointed at the new server.
What if my JSP app uses a private JVM in My App Server?
That is fine, as long as the JVM, Tomcat service, and deployed application are working correctly before DNS is switched. The DNS change itself does not depend on the runtime model, but the runtime must be stable first.
Does DNS cutover affect Apache and Tomcat separately?
DNS points users to the host, not directly to the Java process. However, if Apache, Tomcat, and virtual host routing are linked in your setup, all of them must be correct before the domain is changed.
What is the safest approach for a live migration?
Test the new environment fully, lower TTL early, keep the old site available during the transition, and switch DNS during a monitored window. This is the safest and most practical approach for most JSP hosting migrations.
Conclusion
The right time to change DNS for a JSP migration in the UK is after the new Java hosting environment is ready, tested, and confirmed to serve the live domain correctly. In a Plesk-based setup with My App Server, that means your Tomcat or private JVM should already be running, your JSP application should be validated, and SSL should be in place before the cutover. Lower TTL ahead of time, switch during a quiet monitored window, and keep a rollback path ready. This approach gives you a cleaner go-live, less downtime, and a much safer migration for users.