Photo: Google Gemini · AI-generated
Every software vendor has a list. The framework two majors behind. The module nobody wants to open. The platform that was modern when it was chosen.
The list is rarely blocked by engineering. Most teams know exactly what to do. They cannot find a window in which to do it.
That is the part that makes modernization different for a product company than for a company modernizing its own internal system.
You do not control the upgrade
An enterprise modernizing an internal application can schedule the migration. One organisation, one decision, one weekend.
A software vendor cannot. Your software runs in other people’s businesses. They upgrade when it suits them, on hardware you did not choose, integrated with systems you have never seen. You may have customers three versions back who are perfectly happy there.
So “we rewrote it” is not a completed project. It is the start of a migration you have to run for every customer, on their timetable, while continuing to support the old version for the ones who have not moved. The engineering is the cheap half.
That is also why the honest cost of modernization is usually double what the estimate says. The estimate covers building the new thing. It rarely covers running two things at once for eighteen months.
The deadline usually comes from somewhere else
Because the internal case for modernization is hard to win, most of it happens when something external forces it.
Windows CE is the clearest example of the last decade. A generation of warehouse and production handhelds ran on it, and when it went end-of-life, every vendor with an app on that platform inherited a deadline they did not set.
We did exactly that migration for a software vendor whose warehouse app — an add-on for Sage 100 — was stuck there. Mobile ERP moved it off Windows CE onto native Android, delivered white-label under the vendor’s own brand.
The interesting constraint was not Android. It was that the app had to keep talking to Sage 100 exactly as it had before, so their customers could replace hardware without changing anything about how the app fitted into their operations. Inventory, receiving, dispatch, production — same workflows, new platform.
Modernize the shell, keep the contract
That constraint is the general lesson.
The parts of your product your customers actually depend on are usually not the parts you want to replace. They depend on behaviour, data formats, and integration points. They rarely care what renders the screen.
So the modernizations that succeed tend to redraw the boundary rather than the whole: replace the platform, the UI layer, the runtime — while holding the integration contract still. It is less satisfying than a clean rewrite. It is also the version that ships, because it does not ask every customer to change at once.
The maintenance does not end when you ship
There is a second thing product companies carry that internal teams often do not: obligations to standards owned by someone else.
We built and maintain a tool bridging Lexware and Deutsche Telekom’s D!VE platform, converting order and quotation data into the exact XML Telekom’s procurement interface accepts. The build was finite. The obligation was not — Telekom’s format kept evolving, and the tool had to keep pace or the partner simply could not submit quotations.
Any vendor integrated with a large partner’s platform, a regulator’s schema, or a payment scheme has this shape somewhere. It is not technical debt. It is a standing commitment, and it deserves a line in the plan rather than being absorbed into “maintenance”.
Doing it without freezing the roadmap
The practical answer is unglamorous: modernization has to run as a parallel track with its own capacity, not as a quarter where features stop.
Roadmaps do not survive being paused. Competitors keep shipping, and the sales team keeps selling against them. A modernization that requires the product to stand still is usually cancelled halfway, which leaves the worst outcome — half-migrated, two codebases, no benefit yet.
This is one of the more common reasons vendors bring in an outside team: not because the work is beyond them, but because it needs to happen alongside the roadmap rather than instead of it. That is the shape of most of our app modernisation work with software vendors.
If you are carrying a list like this, we should talk.