Zero-downtime ecommerce migration: blue-green, DNS and rollback

Zero downtime is an operational objective, not an absolute promise

An ecommerce migration involves much more than moving an application. DNS, CDN, TLS certificates, the storefront, APIs, sessions, caches, databases, media, payments, queues, webhooks, analytics, consent and email services all sit between a visit and a confirmed order. Treating migration as merely switching on new hosting hides the dependencies most likely to break the funnel. A realistic objective is to minimise user-visible interruption, limit risk exposure and preserve a tested way back.

The blue-green model helps by keeping two environments in parallel: blue is the stable environment serving users, while green is the candidate build under test. Microsoft documents this pattern with separate revisions, verification of green, traffic movement and a route back to blue. The principle is portable, but it cannot guarantee continuity by itself. Mutable data, DNS behaviour and external integrations need their own explicit plans.

Inventory the complete serving path before designing cutover

From the domain to order confirmation

Draw an end-to-end map, not just a server diagram. Record DNS authority, records, proxies, CDN, certificates, redirect rules, frontend runtime, APIs, search, media storage, caches and authentication services. Add the commercial path: product page, availability, cart, promotions, checkout, payment, callback, order creation, inventory update, email and customer account. For every component, document its owner, configuration, required secret or certificate, dependencies and observable signal.

Extend the inventory to queues, scheduled jobs, inbound and outbound webhooks, marketplace feeds, analytics and consent management. These components can still target the old environment when the homepage already looks correct. The inventory becomes the test matrix, the monitoring boundary and the basis for deciding what must be frozen, synchronised or reconfigured.

Build green as an identifiable and repeatable artefact

An immutable release, not a changing copy

Deploy an immutable commit and build ID to green. Runtime versions, dependencies, configuration and migrations must be reproducible. Avoid manual edits made only on the new server: they obscure what was tested and make rebuilding after rollback unreliable. Blue and green can differ in capacity or implementation, but their boundary must be understood and recorded.

Expose green through a temporary hostname or restricted address that is protected from public use and excluded from indexing. Google's hosting-change guidance recommends preparing and testing the target, preventing the test hostname from being indexed and confirming that Googlebot can later access the public site. Check certificates, headers, canonical URLs, robots directives, sitemaps and redirects in a realistic context, while ensuring preview restrictions do not leak into production.

Test journeys, locales and integrations on the target

Run smoke tests and synthetic checks for navigation, search, product pages, carts, vouchers, login, password reset, checkout, test payments and order confirmation. Repeat them for relevant languages and currencies, and verify assets, images, fonts, forms, email and internal links. For callbacks and webhooks, use controlled events, idempotency keys and non-production destinations where the provider supports them. A test should not create real charges or ambiguous orders.

Link each result to the exact green build ID. Add checks for application errors, latency, dependencies, logs and queue depth. A healthy homepage does not certify the system. The gate passes only when journeys designated as critical produce expected state and their evidence belongs to the same artefact that will receive production traffic.

Treat mutable state as a separate workstream

Synchronisation, freeze and compatibility

Blue-green duplicates the execution environment; it does not automatically protect databases, orders or inventory. Define where every data class is written during preparation, cutover and observation. Deliberately choose synchronisation, replication, a freeze window or an application process compatible with both environments. The right strategy depends on the stack and must be rehearsed with representative copies. Do not improvise dual writes without idempotency, ordering and reconciliation.

Establish which schema both blue and green can read and which changes would prevent a return. Before cutover, measure orders, customers, inventory, media and backlog, then repeat those comparisons after each phase. If green accepts writes, routing rollback alone is insufficient: data produced during the interval must be moved or reconciled through an assigned, tested procedure.

Prepare DNS and routing without confusing TTL with certainty

Lower TTL sufficiently early for the current authority and configuration, then verify records, certificates and the capacity of both environments. TTL expresses how long a record may remain cached; it is not a countdown guaranteeing complete propagation. Cloudflare also notes that local caches can retain responses for longer. Keep both environments reachable throughout the observation window.

Where the platform supports it, weighted routing can shift requests gradually between resources for the same domain. AWS Route 53 provides one implementation using relative weights and health checks. It is a provider-specific example, not a universal percentage sequence or timing rule. If progressive routing is unavailable, prepare a direct DNS cutover, observe multiple resolvers and rehearse the reverse change.

Use objective gates to advance or return to blue

Before cutover, specify who decides and which signals stop progression. Gates may include error rate, latency, checkout completion, order creation, payment callbacks, queue backlog, webhook failure, inventory consistency and crawler access. Baselines, thresholds and observation periods depend on the store's traffic and risk profile; values copied from a generic runbook are not evidence for this system.

The rollback plan must cover routing, configuration, asynchronous processes and reconciliation of writes accepted by green. Keep blue serving-capable, with valid capacity and credentials, until the decision is closed. Rehearsing the return in a controlled simulation exposes missing permissions, immutable records and slow procedures before production depends on them.

Observe both environments and retire cautiously

• Traffic: inspect requests and response codes on blue and green from multiple vantage points.
• Commerce: reconcile checkout, payments, orders, inventory and notifications.
• Integrations: verify callbacks, webhooks, queues, feeds, analytics and consent.
• Search: monitor crawler access, sitemaps, robots directives, canonical URLs and redirects.
• Release: attach logs, metrics and alerts to the build ID actually being served.

Google recommends monitoring logs from both the old and new hosting and shutting the former down only after it no longer receives traffic. Even then, retain backups, audit evidence and recovery options according to company policy. Migration finishes when the system and its data are stable, not when the first resolver returns a new address. Explore our ecommerce and infrastructure services for help aligning environments, DNS and observability.

A controlled migration combines inventory, an immutable build, journey testing, a data strategy, observable cutover and rehearsed rollback. If you want to turn those elements into a runbook with clear ownership and measurable gates, contact AE Digital Agency to review the architecture and execution plan.