“Pivot” stopped being a startup word years ago. Boards use it, CFOs explain quarterly results with it. But the meaning shifted — adjusting a product early on is one thing. Rebuilding the entire business model while revenue keeps flowing is something else. This article covers the mechanics of doing exactly that: how to change what a business fundamentally does without shutting operations down.
What the Market Looks Like Right Now
The cost of entry dropped
Until around 2020, moving from a product business to SaaS typically meant two to three years of infrastructure work. That’s no longer true and it’s not because companies got better at transformation. The tooling changed.
Kubernetes and containerization are now standard in most enterprise environments. New business logic can be isolated from legacy systems and migrated incrementally, without taking the whole stack down. API-first architecture allows new product layers to sit on top of existing operational systems rather than replacing them outright. Stripe built its entire payment infrastructure on this principle, and companies integrating with it have had to think the same way.
Low-code platforms (Retool, OutSystems, Mendix) let teams prototype new business processes without large engineering efforts. Generative AI has compressed refactoring and testing timelines significantly. Tasks that used to take two weeks now take two days, sometimes less.
Major IT firms (IBM, Accenture, Infosys, DXC Technology, Cognizant) have built dedicated service lines around legacy modernization and model transition, each with its own methodology and pricing approach. The underlying principle across all of them is roughly the same: transformation should be outcome-driven and predictable rather than a single high-stakes cutover. For a closer look at how one such service model works in practice, see https://dxc.com/solutions/modernization-as-a-service.
What’s being tested right now
A few models that would have looked too risky for enterprise two years ago are getting real traction:
Composable business means building the company from modular capability blocks that can be rearranged as conditions change. Gartner has been advocating this for a while; SAP and Salesforce have both started restructuring their product lines around it.
Embedded finance is what happens when a non-financial company absorbs banking functions rather than partnering with a bank. Shopify Capital, Apple Pay Later, Amazon Lending — none of these came from a bank deciding to expand into tech. It went the other way. Mid-size retailers and logistics operators are running early pilots with similar models.
Marketplace over product — shifting from selling directly to hosting a platform where third parties transact and the owner takes a cut. Faire, connecting independent retailers with small producers, hit a $12 billion valuation on exactly this structure.
Where Pivots Actually Break
Most companies that have attempted to change their business model ran into the same cluster of problems. The strategy is rarely the issue. Things fall apart where new business logic meets old technical infrastructure.
Recurring failure points:
- Monolithic legacy systems. Code written decades ago — sometimes in COBOL, sometimes just badly structured — that nobody wants to touch because nobody fully understands what it does. Banks and insurers carry tens of billions of lines of this in production. Any movement here involves real operational risk.
- Data that can’t talk to itself. CRM, ERP, warehouse management, and analytics sitting in separate systems with no real-time integration. A new business model usually requires combining those streams, which turns into an integration project nobody budgeted for.
- Teams shaped by the old model. This one is underestimated. KPIs, incentives, habits, and ways of thinking that evolved to support what currently exists don’t automatically transfer to something new.
- No way back. Pivots often get designed as one-way decisions. When something goes sideways mid-transition, there’s no rollback plan.
GE Digital is worth looking at here. The concept behind the Predix platform was reasonable — connect industrial equipment to the cloud, sell analytics as a service. The execution didn’t hold. The architecture was expensive to maintain, rollout pace fell behind market expectations, and the people side of the transformation was handled poorly. GE spent several billion dollars and quietly abandoned the goal of becoming the “industrial Amazon.”
Building the Foundation Before Moving
Technical preparation
A real audit comes first — not a slide deck summary of the IT estate, but a ground-level map of what’s actually holding business processes together, where the dependencies are, and how much of the codebase has no documentation at all. Most organizations discover things during this step they didn’t expect.
Then comes what Martin Fowler described as the “strangler fig” pattern: the new system grows around the old one, intercepts traffic gradually, and eventually makes the original unnecessary. Amazon rewrote its monolithic codebase into microservices over several years using roughly this approach — without halting one of the world’s largest retail operations to do it.
In practice, the technical groundwork looks something like this:
- Map the core domain. Which parts of the system create actual competitive advantage, and which are commodity infrastructure that could be replaced or outsourced?
- Build an API layer over legacy systems. New components need to interact with old ones without direct database access — otherwise every change creates cascading risk.
- Introduce feature flags. The ability to turn new functionality on or off for specific user groups without a full deployment is not optional during a transition.
- Deploy observability tooling — Datadog, Grafana, OpenTelemetry — before the migration starts, not after something breaks.
- Test against synthetic load before touching live traffic.
Organizational preparation
Technical readiness is half the picture. The other half is harder to scope.
Companies that have managed model transitions without major disruption tend to share certain habits:
- They kept the new model team structurally separate from the existing business. AWS was a distinct internal unit before it became what it is. Inside Amazon’s retail operation, the operational gravity of a large commerce business would likely have shaped it into something more conservative.
- They defined specific, numeric migration targets — share of revenue from the new model by a given date, cost per unit under the new structure, NPS from new customers. “Becoming more digital” doesn’t count.
- They staged the rollout rather than launching fully. Phased releases allow actual learning rather than commitment to a plan that was built on assumptions.
- They communicated honestly inside the company. Employees who don’t understand why the model is changing — and what it means for their own roles — resist in ways that are hard to see and harder to reverse.
The Phases in Practice
Treating a business model pivot as a project with a finish line is usually where planning goes wrong. It’s a process with phases, and each one has its own failure modes.
Phase 1 — Running both models in parallel. The existing model keeps generating revenue and funding the work. The new model launches on a constrained segment — new customers only, or a single geography. The discipline required here is not pulling budget and headcount from the core business to accelerate the experiment. That tradeoff tends to look manageable until it isn’t.
Phase 2 — Migrating traffic. Customer flows shift gradually toward the new model. Hidden dependencies surface during this phase; so do integration gaps that weren’t visible during testing. A solid monitoring setup and a defined rollback procedure aren’t defensive measures — they’re prerequisites for moving at all.
Phase 3 — Winding down the old model. The most delicate stage. The goal isn’t a hard cutoff but an organized transfer of resources — people, budgets, customer relationships. Netflix managed this well: the DVD business contracted over several years while streaming grew, and the timing of that contraction was deliberate, not accidental.
Phase 4 — Cleaning up. Technical and operational debt accumulates during any major transition. Companies that skip this phase end up two or three years later with a new platform that’s already becoming the next legacy problem.
Real Examples Worth Knowing
Shopify started as a fairly conventional SaaS for e-commerce merchants. The shift to a platform model — where third-party developers and app partners became central to the value proposition — required opening the API broadly, moving from REST to GraphQL, and managing a developer ecosystem of thousands simultaneously. The core platform didn’t go down during that transition.
Klarna’s situation is more recent. As interest rates climbed and buy-now-pay-later margins came under pressure, the company started repositioning toward a broader product set and an advertising-supported model. The core product didn’t disappear, but significant backend and product redesign was required while serving tens of millions of active users.
Core banking replacements at institutions like ABN AMRO, ING, and Commonwealth Bank of Australia represent probably the hardest version of this challenge. Replacing the system that processes every financial transaction at a large bank, while the bank keeps operating — this required blue-green deployments, shadow-mode testing running old and new systems simultaneously, and migrating product by product over years.
None of these happened overnight, and none used a cutover date. All ran old and new in parallel longer than originally planned.
Metrics That Tell You Something Real
Standard financial reporting creates a misleading picture during a pivot. Revenue from the old model can keep growing while the new one stagnates, and the aggregate numbers look healthy until the window closes.
Indicators that matter more:
- Revenue mix. The percentage of total revenue coming from the new model, tracked consistently. A rising curve is what matters; a flat one means something in the transition isn’t working.
- CAC under the new model. If customer acquisition costs are higher than under the old model, there needs to be a clear explanation — longer lifetime value, higher average contract size, something concrete.
- Deployment frequency and change failure rate. Google’s DORA metrics have become standard for measuring engineering health during transformation. How often code ships, and how often those shipments cause incidents, tells you a lot about operational readiness.
- Employee NPS. Declining team morale during a transformation is an early warning that tends to be ignored until it causes attrition.
- Time to rollback. If restoring a previous state takes more than four hours, the risk profile is too high for active migration.
What Often Gets Missed
Pivoting without downtime doesn’t mean nothing goes wrong. Things will go wrong. The goal is fast detection and fast recovery, not a spotless transition on paper.
Legacy systems are often described as the obstacle. Sometimes they’re actually the asset — decades of accumulated business logic that reflects real operational complexity more accurately than any new system would. The job isn’t to discard that but to make it accessible.
The resource that tends to run out first in any major transformation isn’t budget or engineering capacity. It’s consistent senior leadership attention. Organizations where the CEO stays personally focused on the transformation agenda move through it meaningfully faster than those where ownership sits three levels down.
Markets don’t extend courtesy timelines. The window for any particular pivot opens and eventually closes. The capacity to transform without operational disruption — without losing customers or burning out teams in the process — has become less of a strategic advantage and more of a baseline requirement.
About the Author
