Most transformation conversations in PE-backed businesses start with a discussion about strategy, or AI, or growth. Very few start with the codebase. That's usually a mistake, because legacy architecture is often the thing quietly setting the ceiling on everything else, including what a buyer is eventually willing to pay.

‍

Legacy architecture that makes modern delivery slow, fragile and expensive is one of the three tensions that sits underneath almost every transformation programme we see. It doesn't get the same attention as an AI strategy or a growth plan, partly because it's less visible in a board update, and partly because the cost of it doesn't show up cleanly on a P&L. It shows up instead in how long things take, how often they break, and how much it costs to change anything at all. None of that is easy to point to in a single number, which is exactly why it tends to get deprioritised until it can't be any longer.

‍

Why this gets missed until exit

‍

During the ownership period, legacy architecture is usually treated as a known cost of doing business rather than a strategic problem. Engineering teams work around it. Roadmaps get adjusted to avoid the worst of it. It's inconvenient, but it's manageable, and manageable problems rarely get board-level attention when there's a growth thesis competing for the same budget and focus.

‍

The problem is that "manageable" and "invisible to a buyer" are not the same thing. A buyer's technical diligence team isn't looking at the business the way the internal team has learned to. They're looking at what it would actually take to build on top of what exists, and legacy architecture is precisely the kind of thing that looks fine from the outside and turns into a material finding once someone actually gets into the codebase.

‍

What buyers are  testing for

‍

Two years ago, this kind of finding would typically get noted in a diligence report and moved past. Some technical debt surfacing wasn't unusual, and it rarely changed the transaction fundamentally. That's shifted. Buyers are now testing more specifically whether the platform underneath the business can support what the growth thesis actually requires, not just whether it currently works.

‍

That distinction matters. A platform can be functioning perfectly well for the business as it operates today and still be a liability for the business a buyer intends to build. If the growth plan depends on new markets, new product lines, or integrating a bolt-on acquisition, and the underlying architecture can't support that kind of expansion without significant rework, that gap gets priced in. It's no longer treated as a future problem for someone else to deal with. It's treated as a discount on the number being offered today.

‍

The compounding cost of delay

‍

The businesses that come through this well are rarely the ones that fixed everything before a sale process started. That's usually not realistic, and buyers don't expect a perfect platform. What they respond to is evidence that the business understands where its architecture is limiting it, and has a credible, costed plan for addressing the parts that actually matter to the growth thesis, rather than a vague acknowledgement that "there's some tech debt."

‍

The alternative, leaving it until the transaction window opens, tends to be the more expensive path in practice. Not because the underlying problem gets worse on its own, though it often does, but because there's no time left to demonstrate progress. A buyer evaluating a static problem statement values it very differently to a buyer evaluating a business that's already partway through addressing it. The first looks like unquantified risk. The second looks like a managed, understood cost with a clear trajectory.

‍

Where does this start?

‍

Replacing or re-platforming outdated architecture isn't primarily a technology decision, even though it gets treated as one. The starting point that tends to work is understanding what the architecture actually looks like today, not what the documentation says it looks like, and connecting that honestly to what the business's growth thesis actually requires over the ownership period. That's a commercial question before it's a technical one, and it's usually best answered early, well before a data room is being assembled and a diligence team is asking the questions directly.

‍

The technology is, in the end, the more straightforward part to fix. The harder part is having an honest, evidenced answer ready before a buyer asks the question themselves.

‍