replatforming without a big-bang launch

date: May 26, 2025

Problem: A new commerce platform had to replace a live multi-market estate without interrupting orders, payments, fulfilment, customer accounts, or organic traffic.

The platform was technically ready before the organisation was ready to move every market. A single cutover would have combined application risk, migrated data, DNS changes, redirects, third-party integrations, and a new support process into one event.

Solution: We treated the first launch as a production test with customers, not as the finish line. Two low-volume storefronts moved first. The remaining markets followed only after the team had validated the system and its operating model.

Reduce the number of new things happening at once

A replatform is rarely one migration. It is a coordinated change across infrastructure, application behaviour, data, operations, SEO, analytics, and people. Each part may pass its own checklist while the complete cutover still fails at the handoffs.

The phased launch reduced that coordination risk. The first markets used the same production frontend, API gateway, commerce engine, content platform, queueing, payments, and fulfilment integrations as the larger markets. Their traffic was lower, but their user journeys were representative.

That distinction matters. A staging environment can confirm that software works. A low-volume production launch confirms that the whole delivery system works. It exercises DNS, production payment methods and credentials, alert routing, customer service, and the people making go or no-go decisions.

We also kept routing as the migration boundary. The legacy and new platforms could remain live at the same time, with each country domain pointing to one complete path. We did not split a single customer journey across both storefronts. That made rollback a DNS and routing decision instead of a data reconstruction exercise. Shared downstream systems still needed compatibility, but the customer-facing cutover stayed understandable.

The monorepo described the complete platform in LikeC4. This container view keeps the same boundaries and groups the external services by responsibility:

The synchronous purchase path stopped at the gateway and its direct dependencies. Slower integration work moved through a queue to background functions. That separation kept fulfilment and finance outages away from the customer request path.

The distributed cache was another deliberate boundary. It protected the commerce API as gateway capacity changed, which I cover in more detail in caching a high-volume commerce platform.

Make rollback part of the platform

The rollback plan cannot live only in a launch document. The infrastructure should preserve the previous healthy version while a replacement starts, and it should stop a broken deployment without waiting for manual intervention.

This deployment helper came from the platform codebase. It keeps all existing tasks healthy during rollout, permits temporary double capacity, and enables automatic rollback:

Object.assign(serviceArgs, {
  deploymentCircuitBreaker: {
    enable: true,
    rollback: true,
  },
  healthCheckGracePeriod: 60,
  deploymentMinimumHealthyPercent: 100,
  deploymentMaximumPercent: 200,
});

The container and load balancer used the same health endpoint. That made the deployment decision depend on application health rather than whether a process happened to be running:

health: {
  command: [
    "CMD-SHELL",
    "wget -q --spider http://localhost:8080/healthz || exit 1",
  ],
  startPeriod: "8 seconds",
  interval: "15 seconds",
  retries: 4,
},

Separate technical readiness from launch readiness

Our go-live view had four independent tracks: technical, functional, data, and operational. A green deployment did not compensate for an untested refund flow. A complete catalog import did not compensate for missing redirects. Each track had an owner, a status, a risk, and evidence.

The go or no-go meeting then became short. We were not asking whether people felt comfortable. We were checking whether the evidence met the agreed threshold.

After launch, synthetic checks continued to run against production while the delivery team watched application traces, queue depth, payment flow, order creation, and integration failures. Support staff had the same escalation route used during preparation. The launch window was an operating period, not a one-hour ceremony.

What another team should copy

Start with a market or customer segment that is small enough to limit business impact and complete enough to exercise the architecture. Keep it on the production path. Define rollback before DNS changes. Give functional, data, technical, and operational readiness separate owners.

Do not use the first launch to prove scale. Use it to prove control. Load testing should already have answered the scale question. Our Black Friday readiness programme shows how we approached that work after the phased launch.

Result: The new platform entered production without a big-bang cutover. The first storefronts gave the team operating evidence, and later markets could move through a repeatable launch process instead of a larger version of the same gamble.

I designed and built this at rb2.