The pattern
The story is nearly always the same. A company starts on a niche package — vertical software for the sector, bought when the operation was ten times smaller. The package works, for years. Then growth arrives: more case files, more legal entities, more people working the system at once, more reporting obligations.
The package does not grow along. The vendor is small, the roadmap has stalled, and every acquisition in the sector makes you wonder whether it will still exist next year. Ask for a change and you get a polite answer and no date.
The false choice
The classic reflex is all-or-nothing: replace the whole package with something bigger, in one large migration. Sometimes that is the right path. But it is a heavy one: a long implementation, your whole team on a new system at once, and an operation that has to keep running in the meantime.
So many companies postpone the choice — understandably. With spreadsheets alongside the package, with the most expensive people in the company reporting manually, with an operation that creaks a little more each year. That is the false choice: as if replacing everything or leaving everything alone were the only two options.
What is possible today
What changed in recent years is not that software got cheaper — it is that a generation of capabilities arrived that the old systems cannot reach. A photo in the field that becomes a report by itself, in the right file. An inbox that sorts itself and drafts answers. Workflows that run without anyone retyping. For companies on a closed package, none of that exists — not because it cannot be done, but because their software will not open up to it.
The most important shift: this does not have to be a replacement project. The core you run today is often healthy as a system of record; the modern layer is built around it and proves itself step by step. You own the system, the data and the roadmap — the continuity question shifts from "will my vendor exist next year?" to "which team maintains my platform?". That is a healthier question.
The honest condition
Modernising this way works under one condition: start with the operation, not the software. Map the domain first — the people, the money flows, the obligations — and build second, and most of the risk leaves the engagement. Start building immediately and you rebuild the old package with different bugs.
That is why discovery is a separate, paid step here, with a result that stands on its own. If it ends there, you own an analysis worth its fee. If it continues, everyone knows exactly what will be built — and what will not.