The second article in a four-part series on platform modernization. Article 1 made the case for modernization as reliability tax recovery. This one covers how to actually do the work without breaking what’s already running.
The board funded the modernization. Capacity is allocated. Now you have to execute.
This is where most modernization efforts go sideways. The pitch was clean. The plan looked reasonable. Six months in, the team is rebuilding things that already worked, the value creation plan is slipping, and someone in finance is asking hard questions about what actually got delivered.
Teams move fast. Rip out the old system, build the new one, cut over. The “big bang” rewrite fails almost every time. Teams underestimate the complexity hidden in legacy systems. The new platform launches with gaps the old one handled quietly for years. Or the project drags so long that organizational patience runs out and the effort gets killed halfway through.
The alternative is incremental modernization. The discipline isn’t just sequencing. It’s making sure every step pays for itself.
Self-Funding Increments
If Article 1 was about getting modernization funded by reframing it as reliability tax recovery, this is about making sure each increment actually recovers some of that tax.
Every step has to do at least one of three things. Reduce capacity drag from unplanned work. Unlock a roadmap commitment that was blocked by platform limits. Or remove a diligence liability that would discount the exit. If a step doesn’t do any of those, you’ve moved code around without recovering anything.
The strangler fig pattern is the mechanic. Self-funding increments are the test.
The mechanic is straightforward. Rather than replacing a system all at once, new capabilities are built alongside the existing platform. Traffic, data, or workflows are gradually redirected from old to new. The legacy system shrinks over time as more functionality migrates, until it can be decommissioned entirely. The pattern is well-documented and intuitive.
The test is harder. It’s what separates modernization that compounds from modernization that stalls. It also protects against the most common failure mode: running out of patience or budget before the work is complete. If every step delivers value on its own, pausing the effort still leaves you better off than where you started. If steps only pay off when the whole thing is done, the first delay kills the initiative.
This is the discipline the rest of this article is about. Finding the right seams. Choosing between extraction and encapsulation. Sequencing for capacity recovery. All of it serves the same test. Does this increment pay for itself?
Finding the Right Seams
Every legacy system has natural seams. Boundaries where one responsibility ends and another begins. Not every seam is worth splitting. The best candidates have three characteristics:
Well-understood contracts. Clear inputs and outputs. Minimal shared state. If the interface between components is already clean, extraction is straightforward. If it requires untangling six database tables and a dozen global variables, that’s a later-phase candidate.
High change frequency or high operational cost. The component changes often enough to justify the investment, or it’s the source of frequent incidents. Extracting a subsystem that hasn’t been touched in three years delivers less capacity recovery than extracting the one that breaks every other week.
Reduces complexity for nearby teams. Once extracted, does this component make life easier for product teams, operations, and customer support? If extraction creates more coordination burden than it removes, the seam is wrong.
Extract vs. Encapsulate
Most teams get this one wrong.
The choice: extract a capability into a new service, or encapsulate it behind a clean interface within the existing system.
Extraction gets more attention. It’s more visible, easier to communicate to the board. But encapsulation is often the smarter first move.
Encapsulation means wrapping a messy subsystem behind a well-defined API boundary without moving it. It delivers many of the same benefits as extraction. Decouples teams. Enables independent testing. Creates a clear contract. When the time does come to extract, the encapsulated boundary makes the move straightforward because the contract is already defined and battle-tested.
Encapsulate first when:
- The subsystem is stable but the interface is messy
- Team coordination is the bigger problem than deployment coupling
- You need to prove value before committing to full extraction
Extract when:
- Deployment coupling is causing production issues
- The component has fundamentally different scaling or reliability requirements
- The technology stack needs to diverge
Most failed modernization efforts start by extracting too early. They create microservices before establishing clean boundaries, then spend months debugging distributed system problems that didn’t exist in the monolith. Now they have all the operational complexity of a distributed system and none of the team independence benefits.
Encapsulate first. Extract when the boundary is proven.
Sequencing for Capacity Recovery
The sequencing rule: highest capacity recovery or highest risk reduction first.
Highest capacity recovery. The component that, once modernized, returns the most engineering capacity to roadmap work. Often this is the integration layer or workflow orchestration logic that product teams are constantly fighting. Extract this first and you free up the people best positioned to drive value creation plan execution.
Highest risk reduction. The component that causes the most incidents or has the most technical debt. Modernizing this early reduces the operational burden immediately and builds organizational confidence in the effort.
Don’t start with the easiest or the most technically interesting. Those are tempting but they don’t move the needle. Boards don’t fund modernization to make engineers happy. They fund it to recover capacity.
Sequencing also means being honest about dependencies. Hidden dependencies kill more modernization efforts than anything else. The team thinks they’re three weeks from launch, then discovers a critical blocker buried five layers deep.
Testing and Observability as the Safety Net
Incremental modernization without testing and observability is just incremental risk.
Before changing any subsystem, existing behavior has to be captured in tests. Not aspirational test plans. Running assertions that confirm the system does what it’s supposed to do today. Characterization tests are particularly valuable here. They capture current behavior including the quirks and edge cases that aren’t documented anywhere. If a change breaks one, that difference needs to be a conscious decision, not an accident.
Observability is the migration tool. Instrument both old and new systems to capture the same metrics. Route a percentage of traffic through the new path and compare outcomes side by side. Use feature flags to control exposure and enable rapid rollback. The comparative dashboards are what give teams the confidence to shift traffic gradually and the evidence to roll back quickly when something goes wrong.
Without these two disciplines, teams are flying blind. They ship changes, wait for bug reports, and discover problems days or weeks later. That cycle destroys confidence. The reliability tax goes up instead of down.
Reporting Progress in Business Terms
The board doesn’t care about architectural diagrams. They care about capacity, risk, and delivery velocity.
Don’t report that the monolith was decomposed into three services. Report that deployment frequency increased from monthly to weekly. That the blast radius of a failed release decreased by 60%. That onboarding time for new engineers dropped from four weeks to ten days. That 15% of capacity previously going to incident response now flows to roadmap delivery.
These are outcomes business leaders track. They map directly to the business metrics from Article 1: capacity allocation, feature delivery against committed roadmap, customer-impacting incidents, and engineering cost as % of revenue.
Frame every modernization milestone as a business outcome. The architectural achievements stay in the engineering Slack channel.
A Real Example: Order Processing Extraction
A portfolio company had a 12-year-old Rails monolith processing 50,000 orders per day. Order fulfillment logic was the most incident-prone part of the system and the most frequently modified. It was the obvious first extraction candidate. The board had approved a modernization initiative tied to enabling a new enterprise tier on the operating plan.
The team didn’t start by building a new service. They started by encapsulating the order processing logic behind a clean internal API within the monolith. This took three weeks. It immediately reduced coupling. Product teams could now change checkout flows without touching fulfillment code.
Once the boundary was proven, they extracted the encapsulated logic into a standalone service. The extraction took six weeks because the contract was already defined and tested. Traffic was shifted gradually over four weeks using feature flags. By week 13, 100% of orders were flowing through the new service.
The results in business terms: deployment frequency for order fulfillment changes went from monthly to daily. Incidents related to order processing dropped 70%. The team that owned fulfillment recovered roughly 25% of their capacity, which got redeployed against the enterprise tier work. The launch came in two months ahead of the operating plan.
Total effort: 13 weeks. The first three were encapsulation. That alone delivered immediate team independence even before any extraction happened. Every step paid for itself.
Maintaining Parallel Delivery
Long modernization arcs test patience. If leadership treats modernization as a background task, the work signals as unimportant. If it consumes all available capacity, the value creation plan slips and the board loses patience.
The exact split matters less than making the tradeoff explicit. In PE-backed environments, 60-70% on modernization during peak effort and 30-40% on feature delivery tends to hold up. Adjust based on competitive pressure and roadmap commitments. The principle is what matters. Never go to 100% on either. Full focus on modernization creates value creation plan risk. Full focus on features perpetuates the reliability tax that modernization is supposed to recover.
The capacity reserved for features isn’t just about morale. It’s about maintaining velocity on roadmap commitments the board is tracking quarterly. A modernization effort that delivers a clean architecture but causes the company to miss its operating plan is a failure regardless of how good the platform looks.
Self-Funding Increments, Not Architectural Purity
Modernization isn’t a project. It’s a campaign. It needs strategic sequencing, engineering discipline, and patience.
The teams that succeed treat each increment as independently valuable. They encapsulate before they extract. They instrument everything. They report progress in capacity recovered, not microservices deployed.
The teams that fail try to do everything at once, hide dependencies until they become blockers, and announce progress in architectural purity rather than business outcomes.
Every increment has to pay for itself. That’s the test that separates the modernization efforts that compound from the ones that stall.
Even with strong sequencing and discipline, modernization efforts can stall. The next article in this series covers the warning signs that appear six months before leadership notices, and how to pivot before sunk costs become unrecoverable.