Bramvia — Business Central Experts
Selling your company in 2-3 years? Outdated technology is a price adjuster, not a footnote
In diligence, 'technology so outdated it can't be integrated' is listed among deal-breakers. Buyers price execution risk. What acquirers actually test, what they discount for, and why the fix takes longer than the sale process.
Short answer: if you plan to sell within two or three years, your ERP is part of the valuation. Private equity diligence checklists list "technology so outdated it can't be integrated" among the deal-breakers, and buyers apply price adjusters for gaps they will have to fix themselves — the same way they knock money off for deferred capital expenditure. On the other side, buyers pay a premium for reduced execution risk: an acquirer who can integrate your business without replacing the system first is buying a cleaner asset. The uncomfortable timing is that a migration takes 3-9 months and the benefits — clean data, a reliable close, reporting a buyer trusts — need a few quarters of history behind them to be credible. Which means the work has to start before the process does, not during it.
What buyers actually test
Diligence is not a software review. It is a series of questions about risk, and technology answers several of them:
| What they ask | What they're really testing |
|---|---|
| How long does your month-end close take? | Whether your numbers can be trusted, and how much finance work the buyer inherits |
| Can we get three years of clean, consistent data? | Quality of earnings, and whether the reported margin survives inspection |
| Is the system supported and patchable? | Cyber exposure and immediate capital need |
| How many people are required to produce the monthly pack? | Whether management reporting is a process or a person |
| Can this be integrated with our platform? | Integration cost and timeline — priced directly |
| Who holds the knowledge of how it works? | Key-person risk, which is a discount every time |
| Is customer and margin data reliable at a granular level? | Whether the growth story is verifiable |
Notice how few of those are technical. They are all financial questions that a system either answers or doesn't.
Where the discount comes from
Integration cost. If the acquirer has to replace your ERP on day one, that cost and risk lands in their model, and it comes out of your price. The same project you'd pay for yourself gets valued by them at a premium for disruption.
Quality of earnings. If margin by product and customer can't be produced reliably, the quality-of-earnings work takes longer, finds more adjustments, and every adjustment is a negotiation you lose.
Key-person risk. "One consultant who knows our system" is a sentence that costs money in diligence. So is "the controller builds the pack by hand."
Cyber and insurability. Unsupported software in production is now a question insurers can decline on, which makes it a diligence finding too. Why that has changed.
Deferred spend, priced like capex. Diligence treats necessary-but-delayed investment as a deduction. An ERP the buyer must replace is exactly that.
Where the premium comes from
The mirror image is worth stating, because it's the actual argument for acting early:
- A supported, cloud-based system with a documented configuration is one less integration project in the buyer's plan.
- A close in five days rather than three weeks signals a finance function that scales.
- Granular, reliable margin data makes the growth story verifiable instead of assertable — and verifiable stories hold their multiple in negotiation.
- Multi-entity and intercompany handled in the system matters enormously to buyers who plan bolt-ons. PE playbooks are explicit that an ERP unable to scale past the first or second acquisition forces costly re-platforming mid-hold — so a platform that can absorb entities is a feature they pay for.
What not to do
Don't start a migration six months before going to market. A project mid-flight during diligence is the worst of both worlds: disruption, unfinished data, and a buyer who sees risk rather than progress. Either finish it with a few quarters to spare, or leave it visibly documented as the buyer's option with a scoped cost.
Don't over-build to impress. Buyers don't pay extra for an expensive system. They pay for low risk and clean numbers. We were brought into a US distribution business that had spent roughly $2 million on an SAP integration it did not need — scoped for a company several times its size. That spend did not become value; it became a question about how decisions get made.
Don't clean the data only in the reporting layer. Quality of earnings goes to the transactions. A polished dashboard over inconsistent history gets found in week two.
A realistic sequence, working backwards
| Time before exit | What to do |
|---|---|
| 30-36 months | Decide honestly whether the system can carry the company through a sale. If not, this is when the migration starts. |
| 24 months | System live. Clean master data. Close measured and improving. |
| 18 months | Four quarters of consistent history accumulating. Margin by product and customer reliable. |
| 12 months | Reporting pack produced from the system, not assembled. Key-person dependency documented away. |
| 6 months | Diligence-ready data room: three years of consistent data, configuration documented, no unsupported software in production. |
| Process | Nothing in flight. The technology is an asset in the story, not a line item in the discount. |
If you are closer than that, the play changes: document precisely, don't start anything, and quantify what a buyer would need to do. A scoped, credible plan costs less in negotiation than an unknown.
How we help
Two ways, and they're different engagements:
- Before you decide: a fixed-fee analysis of your own data that tells you what a buyer will find — margin quality, data consistency, how much of the reporting is manual, where the key-person risk sits. That's the Profit Leak Audit, and it works on any ERP.
- If the answer is to modernise: the migration itself, split into parts, each invoiced only after you accept it — which matters when the timeline has a sale at the end of it.
And the honest version: if your system will carry you through a sale as it is, we'll say so. A migration that doesn't need to happen is the most expensive thing on this page.
FAQ
Will a buyer really pay more because of our ERP? They'll pay more for lower execution risk, and the system is a large part of that. The mechanism is usually less discount rather than more premium, but the euro is the same.
We're being acquired by a strategic buyer who'll replace everything anyway. Then the argument is quality of earnings and the speed of your close, not the platform. Clean, granular, verifiable data still moves the price.
Is there time if we're 18 months out? For a migration, it's tight but possible in a small or mid-sized company — 3-9 months of project plus a few quarters of history. For anything less, document rather than start.
What about a carve-out? Different problem: the seller usually keeps you on their system under a transitional services agreement, and missed separation milestones force costly extensions. That deserves its own plan, early.
Planning an exit and unsure what a buyer will find? Free assessment, no commitment — confidential, and the report is yours.