Every ageing platform carries a backlog of things the team would fix given a free quarter. The instinct, once an exit comes into view, is to treat that backlog as a punch list and start at the top. That instinct is expensive and usually wrong. A hold period is finite, engineering capacity is scarce, and most technical debt has no bearing whatsoever on what a strategic acquirer's technical team will conclude in the data room. The task is not remediation. It is sequencing.
The right frame is deceptively simple: modernisation should be ordered by what changes the diligence outcome and, through it, the price. Debt that a buyer will surface, test and discount belongs at the front. Debt that lives entirely inside your own four walls — inelegant but working, invisible to an outsider — belongs at the back, or nowhere at all.
Prioritise what a buyer will actually test
An incoming acquirer's engineers arrive with a short, sharp list. They are not auditing your code for beauty; they are pricing the risk of owning it. In our experience that scrutiny concentrates in a handful of places:
- Key-person concentration. If one engineer holds the architecture in their head and nowhere else, that is a valuation problem before it is a technical one. Buyers price the bus factor.
- Security posture. Dependency hygiene, secrets handling, access controls, a credible answer to "what happens when this is breached." This is table stakes and it is always checked.
- Scalability ceilings. The point at which the current design stops absorbing load — and whether the buyer's growth thesis runs straight into it.
- Undocumented architecture. A platform that cannot be explained cannot be diligenced quickly, and slow diligence erodes both confidence and leverage.
Retire those first. The cosmetic and internal debt — a dated build pipeline that still works, a module the team dislikes, naming conventions nobody outside will ever read — is real, but it does not move the price. Defer it deliberately, and be able to say why.
The question is never "is this debt?" It is "will an acquirer's technical team test it, and will the answer change the price?"
Why the eighteen-month rewrite is the wrong answer
The reflex response to accumulated debt is a big rewrite — a ground-up rebuild that promises to make everything clean at once. In a hold period this is almost always the wrong instrument. A rewrite consumes the entire window, carries real delivery risk, and produces its value, if it produces any, exactly when you can least afford a slipped timeline. It also tends to modernise indiscriminately: the same effort spent on debt a buyer will price and debt no buyer will ever see.
A focused sprint aimed at exit-readiness inverts that. Three months, not eighteen — enough to close the specific gaps that survive a financial buyer's review but will not survive a trade buyer's technical team, and not a day spent gold-plating what nobody will inspect. The measure of success is not how much of the backlog cleared. It is whether the platform now answers the diligence questions cleanly.
Transfer capability; do not create dependency
Modernisation done for a portfolio company should leave that company stronger without leaving it hooked on the firm that did the work. Debt retired by an outside team that then leaves is debt half-paid: the buyer inherits a platform whose recent improvements no internal engineer can explain or extend. That is a new key-person risk wearing a vendor's badge.
The work belongs alongside the portfolio company's own engineers — hands-on, transferring the judgement and not just the commits, so that when the outside team steps away the capability stays behind. Capability transfer, not dependency. An acquirer can tell the difference in an afternoon.
Agree the exit criteria up front
Because the goal is a diligence outcome and not a finished backlog, the engagement needs a defined end before it begins. Name the specific risks being retired, the state that counts as "done" for each, and the point at which further work stops earning its cost. Agreed exit criteria keep a modernisation sprint from drifting into an open-ended retainer, and they give the board and the incoming buyer the same clear account of what was addressed and, just as importantly, what was consciously left alone. Sequencing technical debt for exit is a judgement about where value leaks and where it does not — and the discipline is in what you choose not to fix.