Sprint $170M Commerce Core Replacement

Problem

Sprint's legacy commerce portal held back the launch of a new digital-commerce business. Its order-and-ship transaction model was a poor fit for high-volume, low-latency digital entitlements. Changing the stack safely required scarce, expensive specialists, and extending it would have kept its search, checkout, regression and delivery limits.

What I did

• Compared “keep and extend” against replacing the commerce core on lifecycle cost, change-failure rate, time to market, revenue-disruption risk, peak TPS, page-render times, batch windows and representative feature estimates
• Brought e-commerce sales and marketing into revenue planning
• Led the $170M replacement with tighter scope and a controlled cutover, managing vendors, development teams, internal leadership, cost, schedule, quality, resources and executive communications

Result

• Capacity held through first peak cycles
• No peak search or checkout slowdowns
• Lower cost per shipped feature by year two

The new core gave Sprint a scalable foundation for its digital-commerce business. It handled the shift from a static physical catalog to a larger, faster-changing digital catalog, and held through the first major app-store and promotional cycles. By year two, new engineers could own features without months of ramp-up on the legacy stack.

How this applies to you

Keep-or-replace is one of the most expensive decisions a company makes, and it usually gets made on gut feel or a vendor pitch. An Innovate engagement puts both options on the same scorecard (lifecycle cost, failure rate, time to market, revenue risk) before any contract is signed. See the Innovate work →