A global website launch is often compressed into three actions: provision a server, enable CDN, and point the domain at the new address. That can make a page appear quickly, but it does not answer the questions that determine long-term reliability: which systems handle the request, who owns each stage, how a failed change is reversed, and whether the business path was actually verified.
A more reliable launch begins with an end-to-end delivery map from the user to the application and onward into continuous operations. The map is not paperwork for its own sake. It turns hidden dependencies into ownership that both technical and non-technical teams can inspect.
Define what “launch complete” means
Stakeholders rarely mean the same thing by launch. Leadership may see the home page and consider the work finished. Editors may still be validating content, marketing may be waiting for form delivery, and engineers may still be checking certificates, caching, logs, and capacity. A shared acceptance definition prevents the project from oscillating between “it looks ready” and “it cannot be used.”
- Reachable: primary regions can open the correct HTTPS domain, with redirects, error pages, and mobile rendering verified.
- Usable: forms, login, downloads, mail, video, and other critical journeys complete successfully.
- Observable: certificate expiry, service failure, capacity pressure, and application errors can be detected.
- Recoverable: a known release, data copy, domain configuration, and required credentials have an executable recovery path.
Stage one: entry and DNS decide where requests go
DNS may contain only a handful of records, yet it owns the first traffic decision. Review primary and legacy domains, subdomains, authoritative DNS, TTL, IPv4 and IPv6, certificate scope, and account ownership. Missing one record can create a split state in which some users reach the new system while others remain on the old one.
Reduce TTL before the migration window, record the old values and destination, prove that the new entry works independently, and test resolution from more than one network after the switch.
| Area | Confirm | Common failure |
|---|---|---|
| Authoritative DNS | Account ownership, complete records, change access | Account belongs to a former employee or vendor |
| Records | Root, www, API, and mail-related entries | Only the home page record is migrated |
| TTL | Lower before the switch, restore after stability | Long caches make cutover and rollback slow |
| Certificates | Coverage, renewal method, expiry alert | Subdomains or automated renewal are missing |
Stage two: the edge is a policy set, not a switch
CDN value comes from deciding what can be cached, for how long, and under which conditions. HTML, images, scripts, downloads, video, and APIs need different policies. Versioned static assets can use long caching; HTML needs fresher rules; authenticated, administrative, and personalized routes generally should not enter a public cache.
Origin policy matters too: which hostname the edge uses, whether origin TLS is verified, whether direct access is restricted, and how cache misses are prevented from overwhelming the application.
Stage three: verify the business, not just the process
An origin often includes the web service, application process, database, object storage, mail, and external APIs. A static health endpoint can prove that a server responds without proving that a visitor can submit a form or retrieve data.
Use lightweight health checks for load balancing and restart decisions, and separate synthetic checks for real journeys. A synthetic check might open an event page, submit a controlled test form, retrieve a known asset, and verify the downstream result.
Stage four: change, monitoring, and recovery must coexist
Post-launch incidents often come from later changes rather than the first configuration: renewal behavior changes, temporary cache exceptions remain, a migration leaves old firewall rules, or content growth fills a disk. Each material change should record the reason, operator, scope, verification, and rollback method.
| Stage | Ownership question | Minimum deliverable |
|---|---|---|
| Entry | Who controls domains and certificates? | Record inventory, account owner, rollback destination |
| Edge | Which routes cache and how are they purged? | Cache policy, origin restriction, purge procedure |
| Application | Were all business dependencies verified? | Health checks, log locations, dependency list |
| Operations | Who receives alerts and restores service? | On-call contact, backup location, recovery steps |
Run cutover in three windows
- Before: freeze risky content changes, take backups, test the new site, forms, mail, certificates, and monitoring, and preserve the old entry information.
- During: change routing, observe errors, origin traffic, TLS, and critical journeys, and record exact times.
- After: retest from primary regions, inspect redirects and old links, retain the old environment for an agreed period, and retire it deliberately.
A professional launch does not make infrastructure sound complicated. It gives every stage clear ownership, measurable acceptance, and an executable rollback path. Once the route is explicit, communication shortens, diagnosis accelerates, and ongoing cost becomes easier to explain.