The customer-facing replatform

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.

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.

• ·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

• 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.