Prepare the server and certificate for the intended hostname, test the application before changing public DNS, and keep the old environment available during the transition. Verify authoritative records, cached answers and TLS independently. A DNS update alone does not establish that the correct application and certificate are being served.
Inventory the names and dependencies
List every hostname the site uses, including the main domain, aliases, API endpoints and application callbacks. Record who controls registration and authoritative DNS. Hosting an application does not automatically register its domain or give the server operator control of its records. Keep access to the existing environment until the new one has been validated.
Also identify email and third-party verification records that the move should preserve. A website migration should not casually replace an entire DNS zone. Make a record-level change plan with the intended addresses and a rollback value. Store credentials privately; the runbook needs owners and procedures rather than actual passwords or API tokens.
Prepare hostname routing on the new server
A machine receiving a connection must serve the intended application for its hostname. Configure the web server or hosting panel accordingly, with the public document root separated from private configuration and credentials. Test all required names and redirects, not only a generic welcome page reached through the server's address.
Use a controlled test method that sends the intended hostname to the new endpoint before the public change. Check login, uploads and application-generated links where applicable. Disable jobs that could duplicate production actions during testing. The test should prove application behaviour without sending real mail, taking payments or modifying the old live database unintentionally.
Choose a certificate validation method
Certificate issuance requires proof of control for the requested names. Let's Encrypt documents HTTP-01 and DNS-01 among its validation methods. HTTP validation depends on serving the required challenge correctly; DNS validation uses a specified DNS record and can support wildcard issuance. Select a method that fits the actual deployment and can be maintained safely.
Keep validation credentials narrowly scoped where possible. DNS automation is especially sensitive because broad DNS credentials can affect more than one website. Plan certificate renewal and how the renewed files reach the serving process. Successful first issuance is useful, but a site also needs a working renewal process and monitoring of the certificate it actually presents.
Plan the cache window before changing DNS
DNS records carry a time-to-live used by resolvers when caching answers. A record change does not instantaneously replace every cached result. If a transition benefits from a shorter TTL, plan the adjustment early enough that previously cached answers can expire. Keep both old and new environments able to handle the transition you designed.
This illustrative sequence separates preparation from the public cutover. Its timing must be adapted to the domain, resolver behaviour and application. It is not a universal propagation schedule. A migration involving live writes also needs an application-specific data cutover, because two functioning web servers can otherwise accept changes into different datasets.
| Stage | Action | Condition before proceeding |
|---|---|---|
| Preparation | Inventory records and configure new endpoint | Application works for intended names |
| Certificate | Issue and install certificate | Correct chain and hostname validate |
| Transition | Update only planned DNS records | Data cutover and rollback are defined |
| Observation | Check authoritative and client results | User journeys succeed through new endpoint |
| Completion | Retire old service after validation | Residual traffic and recovery needs reviewed |
Verify DNS and TLS separately
Check the authoritative record first, then compare answers from clients or resolvers involved in the transition. A correct authoritative value and an older cached value can coexist. Inspect the endpoint reached by the browser rather than assuming every connection already uses the new address. Keep observations timestamped so the transition is understandable.
For TLS, validate the intended hostname, certificate validity and chain through an actual client connection. Inspect every required alias and redirect path. Mozilla's TLS documentation explains server authentication and mixed-content concerns: the page and its subresources should be delivered securely. A certificate on one hostname does not automatically cover another application endpoint.
Make rollback a data decision too
A DNS rollback can redirect traffic, but it does not reverse writes made on the new application. Define how you will handle that data before the cutover. For a static publication, rollback may be straightforward; for a service accepting uploads or orders, the application state needs a clear owner and reconciliation procedure.
Imagine migrating a small publishing site with comments. You can prepare a maintenance interval or a controlled read-only transition while the final data is copied. Test the reopen procedure and keep the old deployment ready. Choose the approach that fits the application rather than using a DNS change as a substitute for consistency planning.
Observe the site after the switch
Verify real user journeys, error rates, certificate presentation and background tasks after the new endpoint receives traffic. Confirm that backups now cover the intended application and data. Review old-server access before retirement and remove obsolete credentials when the recovery and rollback needs have been resolved. Record the final DNS and certificate configuration.
When selecting SwissOctet web hosting or compute, confirm the actual domain, certificate and administration responsibilities for the configuration. The catalogue provides a hosting destination and resources; it does not establish that your domain has already been connected or that certificate renewal has been configured. Keep those steps concrete and verifiable in the deployment plan.
Your practical checklist.
- Inventory every hostname and preserve unrelated DNS records.
- Test hostname routing before public cutover.
- Choose and automate a suitable certificate challenge.
- Plan TTL changes and the data transition.
- Verify DNS and TLS through separate checks.
- Retain rollback access and resolve new writes before reverting.
The details that matter.
Does changing an A record activate HTTPS?+
No. DNS chooses an endpoint; that endpoint still needs the correct hostname routing and a valid, installed certificate.
Can I revert only the DNS record if something breaks?+
Traffic can be redirected, but application writes need separate handling. Define a data rollback or reconciliation plan before the migration.
Is a wildcard certificate always necessary?+
No. Choose certificate names and validation according to the actual hostnames. A wildcard has specific coverage and validation requirements; it is not a universal migration shortcut.
Go to the source.
These references support the technical concepts in this guide. Follow the current documentation before changing a production system.
- Let's Encrypt: Challenge types letsencrypt.org
- IETF RFC 1034: DNS concepts and facilities datatracker.ietf.org
- Mozilla MDN: Transport Layer Security developer.mozilla.org
Editorial guidance by SwissOctet. Examples are illustrative. Service specifications, available options and contractual conditions must be verified separately.