Before changing the domain of a live JSP site, review every place where the old public URL is used. In a managed hosting environment, especially when the application runs on a private Tomcat or JVM through Plesk, the domain change is not only a DNS task. It can affect application settings, virtual host mappings, SSL, redirects, cookies, absolute links, callback URLs, and any external service that still points to the old address.
If the site is already live in the UK market, the safest approach is to plan the change as a controlled go-live update rather than a simple name swap. This is especially important for JSP, servlet, and WAR-based applications that use Apache Tomcat, because the application may reference its own host name in configuration files, login flows, or generated links.
What changes when you point a live JSP site to a new domain
A domain change affects both the public layer and the application layer. At the public layer, DNS and HTTPS must start resolving the new name correctly. At the application layer, your JSP app may need updated base URLs, callback endpoints, and rewrite rules so that users do not land on mixed URLs or broken pages.
In a Plesk-based hosting setup, the domain is usually tied to the subscription, web hosting configuration, SSL certificate, and possibly a Tomcat service definition or application context. If the site uses a My App Server private JVM, the same domain change may also require checking how the app server is mapped behind Apache and whether the application expects a specific host header.
Review the current live setup first
Before making any change, document the current state of the live site. This gives you a rollback path if something breaks during the move.
Check the active domain and DNS records
- Confirm the current A, AAAA, and CNAME records.
- Note the TTL values so you know how quickly the change will propagate.
- Identify whether the site uses www, a naked domain, or both.
- Check whether mail-related records are attached to the same domain.
Check how the application is published
- Is the JSP app deployed directly under Tomcat or routed through Apache?
- Is it running in a private JVM managed by My App Server?
- Does the app use a context path such as /app, or is it mapped to the root path?
- Are there reverse proxy rules, rewrite rules, or custom headers involved?
Check the SSL certificate setup
- Does the current certificate cover the old domain only, or multiple names?
- Will the new domain need its own certificate or a reissued SAN certificate?
- Will users still access the old domain during the transition?
Review application settings that may contain the old domain
JSP applications often store the public URL in more than one place. Search the codebase, configuration files, deployment descriptors, and admin settings for the old domain name.
Common places to check
- Application properties files.
- Environment-specific config files.
- JSP templates with hardcoded links.
- Servlet redirect targets.
- Login and logout return URLs.
- API webhook or callback settings.
- Email templates and notification links.
- Sitemaps, robots rules, and canonical tags.
Typical issues caused by hardcoded URLs
- Users are redirected back to the old domain after login.
- Forms submit to an outdated address.
- Images, scripts, or CSS still load from the previous host name.
- Search engines index duplicate pages under both domains.
- External integrations stop working because callbacks no longer match.
Review Tomcat and My App Server host mappings
If the site uses Apache Tomcat or ITA’s My App Server extension, confirm that the new domain is mapped correctly at the server level. This is a common step in JSP hosting because the application may rely on the host name for routing or virtual host configuration.
What to verify in the hosting panel
- The new domain is added to the correct subscription or site.
- The document root or application path points to the right deployment.
- The Tomcat service is still assigned to the correct site.
- The Java version selected for the app is the intended one.
- The app server is running and reachable after the mapping change.
If you use a custom app server configuration
Some JSP applications are deployed with a custom context, manual connector settings, or separate service paths. In that case, review the app server configuration carefully before changing the domain. A new domain can require updates in:
- Connector bindings.
- Virtual host entries.
- Context XML files.
- Proxy or rewrite settings.
- Application startup parameters.
For private JVM setups, also confirm that the service control settings still point to the correct runtime and that the application can restart cleanly after the change.
Review DNS, nameservers, and propagation timing
A live domain change should be done with DNS timing in mind. If the new domain is not resolving properly, the application can appear offline even if Tomcat is running normally.
Before the switch
- Lower TTL values in advance if possible.
- Make sure the new domain has all required records.
- Check that the destination server is ready before updating the domain.
- Verify that any CDN, proxy, or security layer is also updated.
Things to watch during propagation
- Some users may still reach the old domain for a while.
- Cookies may behave differently if both domains are live during the transition.
- Search engines may crawl both addresses if redirects are not in place.
- External systems may take time to update cached DNS values.
Review HTTPS and certificate coverage
For UK-facing public sites, HTTPS should be ready before the new domain goes live. A domain move without a valid certificate creates browser warnings and can break secure sessions.
Check these items before launch
- The certificate covers the new domain exactly.
- If www and non-www are both used, both names are covered.
- The certificate is installed in the correct hosting subscription.
- Tomcat or Apache is serving the correct certificate chain.
- Forced HTTPS redirects still point to the correct host name.
Common HTTPS mistakes
- The old domain has a valid certificate, but the new one does not.
- The certificate is installed, but the site still redirects to HTTP somewhere in the app.
- The app generates absolute HTTPS links with the previous host name.
- Mixed content remains in JSP pages after the migration.
Review redirects and canonical behaviour
If the old domain will stop being used, plan redirects before the public switch. This is important for SEO, bookmarks, and existing traffic. A proper redirect also helps maintain user sessions and reduce support tickets.
Recommended redirect checks
- Set a clear 301 redirect from the old domain to the new one.
- Preserve the path and query string where possible.
- Test both www and non-www versions.
- Check that redirects do not loop between Apache, Tomcat, and the application.
- Update canonical tags to the new domain.
For JSP sites specifically
Some applications generate canonical URLs in JSP pages or through a shared header file. Make sure the canonical host name is updated everywhere. If the application uses a request-based URL builder, test it on the live domain after the change to confirm it respects the new host.
Review external integrations and callbacks
Live sites often connect to payment gateways, identity providers, mailing platforms, CRM systems, analytics tools, and support forms. Many of these services store callback or return URLs that include the domain name.
Check for integration points such as
- Payment gateway return URLs.
- OAuth or SSO redirect URIs.
- Webhook destination URLs.
- Password reset links.
- Notification email links.
- Third-party script allowlists.
If the provider validates callback URLs exactly, even a small change from one domain to another can break the integration. Update these settings before or at the same time as the domain switch.
Review SEO and indexing settings
If the live JSP site is public-facing, the domain change should be treated as an SEO migration as well as a hosting update. This matters for organic traffic, indexed pages, and duplicate content prevention.
SEO items to verify
- 301 redirects are active from old to new URLs.
- XML sitemap references the new domain.
- Robots.txt points to the correct sitemap location.
- Canonical tags use the final public domain.
- Open Graph and structured data URLs are updated.
- Google Search Console and similar tools are updated with the new property.
Useful launch approach for SEO
Keep the old domain live long enough for search engines and users to follow redirects. Do not remove the old domain too early if it still receives traffic or inbound links. In many cases, a gradual transition is safer than a hard cutover.
Review session, cookies, and login behaviour
Domain changes can affect session handling, especially for applications that use browser cookies tied to a specific host or parent domain.
Check the following
- Session cookies are scoped correctly for the new domain.
- Remember-me tokens continue to work after redirecting.
- Logout sends the user to the correct host.
- Authentication flows do not mix the old and new domains.
If the application sets cookie domains manually, review those values carefully. A small mismatch can cause repeated login prompts or broken user sessions after the switch.
Review file paths, uploads, and static assets
Some JSP sites store absolute public URLs in upload handling, asset generation, or template includes. This is common in systems that build links dynamically from base configuration.
Check especially for
- Uploaded file URLs.
- Image delivery links.
- Static asset references in JSP includes.
- CDN origins or cache rules.
- Download links generated by servlets.
Test the site after the domain change by loading pages in a private browser window and verifying that all styles, scripts, images, and downloads still resolve correctly.
Recommended pre-change checklist
Use this checklist before changing a live JSP site domain in a hosting control panel:
- Document the current domain, DNS, SSL, and application mapping.
- Search the application for hardcoded old URLs.
- Confirm Tomcat or My App Server is assigned correctly.
- Prepare DNS records for the new domain.
- Install or reissue the SSL certificate for the new host name.
- Plan 301 redirects from the old domain.
- Update callback URLs and third-party integrations.
- Check canonical tags, sitemaps, and robots settings.
- Test session cookies and authentication flows.
- Keep the old domain active during the transition.
Practical change sequence
A safe order for the domain change is usually:
- Prepare the new domain in the hosting panel.
- Confirm the JSP app, Tomcat service, or private JVM is mapped correctly.
- Install or verify the SSL certificate.
- Update application settings that contain the public URL.
- Update external service callback URLs.
- Publish redirects from old to new.
- Switch DNS or domain mapping.
- Test pages, forms, login, and static assets.
- Monitor logs and browser behaviour after go-live.
Common problems after a domain change
Redirect loops
This usually happens when Apache, Tomcat, and the application all try to enforce their own host or HTTPS rules. Review each layer and make sure only one layer owns the final redirect logic.
Mixed content warnings
If JSP pages still link to HTTP resources or the old domain, browsers may block some assets. Update all absolute links and external references.
Broken login or callback flows
Authentication providers and payment services often require exact redirect URI matching. Update those settings immediately after the domain change, or beforehand if the provider allows it.
Old domain still indexed
If redirects are missing or inconsistent, search engines may continue to index the previous host name. Check canonical URLs and sitemap references.
When to involve hosting support
Contact hosting support if the domain change involves a custom app server, a private JVM, a non-standard Tomcat mapping, or a control panel setting you cannot safely verify yourself. In managed hosting, it is often faster to confirm the mapping and certificate assignment before launch than to troubleshoot a broken live site afterwards.
This is particularly useful when the application runs through ITA’s My App Server, because the service, Java version, and public mapping may all need to stay aligned during the move.
FAQ
Will changing the domain affect the JSP application itself?
It can. The code may not need changes, but configuration files, redirects, cookies, and external callbacks often do.
Do I need to update Tomcat if only the domain changes?
Not always, but you should verify the host mapping and any virtual host or context configuration. A domain change can expose assumptions in the deployment setup.
Should the old domain stay online after the change?
Yes, at least for a transition period. Keep it redirecting to the new domain so users, bookmarks, and search engines can reach the site safely.
What is the biggest risk when changing a live domain?
The most common risks are broken redirects, invalid SSL, hardcoded old URLs, and failed login or callback flows. These issues are more likely than a pure DNS problem.
How do I know if my JSP app contains the old domain name?
Search the codebase, config files, templates, and deployment settings for the old host name. Also check admin panels and third-party integrations.
Conclusion
Changing the domain of a live JSP site is manageable when you treat it as a coordinated update across DNS, HTTPS, Tomcat or My App Server, application configuration, redirects, and external integrations. The safest approach is to review every public URL dependency before launch, test the new domain in the hosting panel, and keep the old domain active long enough to catch any missed references.
For managed JSP hosting, the most reliable result comes from checking both the hosting layer and the application layer together. That is the best way to move a live site without losing traffic, sessions, or trust.