The customer-facing replatform

01 — The situation

The current platform is the business — every hour of downtime is measured in revenue. It's also the bottleneck: slow to change, expensive to run, and increasingly hostile to the roadmap.

This engagement rebuilds the customer-facing system while the old one keeps taking orders. The centerpiece is the strangler-pattern cutover: the new platform grows around the old one, route by route, until the old one is serving nothing.

02 — How the gates apply

Smelt defines the cutover sequence as part of the architecture — which routes move first, how sessions and carts survive the seam, and what the rollback path is at every step.

Cast ships behind the seam: each increment moves real traffic to the new platform, so risk is spent in small amounts continuously instead of all at once at launch.

Temper load-tests against recorded production traffic, not synthetic guesses.

03 — What you receive

• ·NEW PLATFORM — LIVE, SERVING ALL TRAFFIC
• ·CUTOVER PLAN, EXECUTED ROUTE BY ROUTE
• ·ROLLBACK PATH DOCUMENTED AT EVERY STEP
• ·PERFORMANCE BUDGETS IN CI
• ·REPOSITORIES AND RUNBOOKS, OWNED BY YOU

04 — Where this goes wrong without discipline

• The rewrite-and-switch: eighteen months of parallel build, one launch weekend, and a rollback at 3am.
• Freezing the old platform during the rebuild. The business won't stop asking for changes, so the plan has to absorb them.
• Migrating the data last. It's the hardest part; schedule it like it is.