Replace or evolve: your platform's age is the wrong question.

Why the question is framed badly

"Our platform is eleven years old." That sentence opens a great many modernization discussions and carries almost no useful information. Twenty-year-old systems run critical operations every day without unmanageable debt. Platforms delivered three years ago are already impossible to change, because every modification touches everything.

What makes a platform expensive is not its launch date. It is how hard it is to make a change without side effects, how much of it only two people understand, and how few clean boundaries exist between its parts. Martin Fowler describes the mechanism precisely: systems built over decades, modified patch upon patch, each patch making the next change harder — until the organization concludes it can no longer patch anything and needs a wholesale rebuild.

That is exactly the moment intuition becomes expensive. Facing a system that has turned opaque, starting fresh feels faster than repairing. The unspoken assumption is that everyone knows what the system does. Usually, nobody does.

What a full replacement makes you pay for twice

A replacement budget covers building the new system. It rarely covers the second expense, which is almost always the heavier one: recovering what the old system knew and nobody wrote down.

Those rules do exist, and they are specific. A discount applied to one account type for contractual reasons everyone has forgotten. An order status that triggers a particular accounting entry at month end. A workaround added six years ago for a partner who will not accept a standard format. None of this shows up in a requirements document. All of it reappears in production, one incident at a time.

Three more costs routinely go missing from the comparison: keeping the old system running for the full duration of the project, dual entry or data synchronization during the cutover, and the learning period for teams who have not only changed tools but changed how they work.

Replacements almost never fail on the technology. They fail on what the old system knew and nobody had written down.

Four situations where replacing is the right call

None of this argues for keeping everything as is. There are situations where replacement is both the prudent and the economical decision, and they look like something other than day-to-day frustration.

1. The data model can no longer carry the business. When the structure rules out a reality that is now central — several markets, several brands, a new customer type — no amount of addition works around it for long.
2. The foundation is no longer supported. A language, database or operating version without security patches moves the discussion from comfort to risk.
3. The skills have left the market. When nobody can be hired or trained on the technology in place, the dependency is no longer measured in technical debt but in individual people.
4. Total cost of ownership is durably higher than the alternative. Licences, hosting, workarounds and maintenance hours added together and compared over several years — not on purchase price.

A dated interface, occasional slowness or team frustration, on the other hand, do not justify a full replacement. Those symptoms can very often be treated without touching the foundation, at an order of magnitude less cost.

Incremental replacement is not a half-measure

Between keeping and rebuilding sits a third option, well documented as the strangler fig pattern. An interception layer is placed in front of the existing system, one capability at a time is built outside it, traffic is progressively redirected to the new components, and the old system is decommissioned once nothing depends on it.

Microsoft's architecture guidance describes both the mechanics and the conditions, and insists on two points that often get skipped. First, the interception layer is transitional architecture: it has its own cost, it can become a single point of failure or a bottleneck, and it is meant to be removed. Second, legacy objects are only deleted once the new system has been validated, because rolling back after deletion means restoring structures and replaying data changes.

The main risk of this approach is organizational rather than technical. Once the most visible capabilities are modernized, attention moves elsewhere and the migration stalls halfway. The organization then maintains two systems instead of one. Decommissioning the old one has to be a dated commitment, not an intention.

Decide on criteria, not on impressions

The three options differ less in total cost than in how that cost is spread over time and how much risk they put on daily operations.

Before choosing, an organization gets further by answering three plain questions, in order: which operations cannot stop, even for a day? which business rules exist nowhere but in the code? and what, concretely, will be possible twelve months from now that is not possible today?

The last question is the most useful, because it moves the discussion from technology to capability. A platform does not get replaced because it is old. It gets replaced when keeping it stops the organization from doing something it has decided to do.