Summary
Over the years, every customer of an ERP, an HR system or a payroll package ended up with its own adaptations: through configuration, through code written for it alone, through external mechanisms built around the system. The product turned into a collection of variants, and every legal change, security fix and upgrade is paid for variant by variant. Three pressures make this untenable: extra margin must now come from lowering the cost of production; the Cyber Resilience Act, DORA and NIS2 require every maintained version to be monitored and fixed; and AI speeds up work on a shared, well-described model but stalls on what nobody has documented. Building a modern platform next to the old system is no way out: it adds a cost and retires nothing.
The way out the article proposes is SharedCore: keep what works, such as the calculation engine, and replace the rest with a new product. Customers move to it; their variants do not. Three rules hold it together: a shared core that never changes for a single customer; base models adapted to each type of customer, with the product’s boundary set, as a rule of thumb, at about 20% of components modified or developed; and a common evolution, a single version that the vendor evolves and updates, on-premise or in the cloud. Before any work starts, five questions need answers, starting with the objective: a measurable intention, not an action.
The evidence comes from the author’s own experience a few years ago: replacing an old client-server business package that some 1,500 customers used remotely. The objective was economic; the obstacle was migration, estimated at 70 days of work per customer. Business teams, architects and support designed base models with a panel of 10 to 12 business managers from all kinds of customers, one model per type of customer. These models covered 80% of the needs, and migrating a customer dropped to 6 days, spent only on its own data. Out of 100 customers, 90 accepted their base model from the start, 6 followed after a year of support and 4 left. The article then covers the AI-assisted inventory, migration in cohorts and the firmness the boundary demands, before the strategy’s real limit: a change of business model that only the head of the business unit can decide on.
Key ideas
- Software adapted customer by customer becomes hundreds of products, and every legal change, fix and upgrade is paid for once per variant. A new platform built next to the old system retires nothing; convergence costs money up front too, but each customer who migrates retires part of the old system, until it can be switched off.
- Nothing is customised in the code. A need that configuration does not cover becomes a configurable feature for everyone, is built by the customer outside the product through its APIs, or is not done. Beyond about 20% of components modified or developed, the customer falls outside the product.
- The base model was the missing piece: one per type of customer, designed with a panel of customers, it cut the time to migrate a customer from 70 days to 6, and 90 customers in 100 accepted it from the start, because it was built with them and contracts were now renewed only on the new product.
- The 4 customers in 100 who left are the price of the boundary, not a failure. Holding that boundary takes a credible offer and customers who get support.
- The limit is not technical: moving from tailored software to a single product changes the vendor’s business model, and only the head of the business unit can make that call.
Why I wrote this
As long as every customer has its own version, the vendor pays out of its margin for adaptations that are never billed and bears the cost of every compliance effort alone. A common product built with the customers turns this around: effort depends on the size of the product, not on the number of customers, and every customer gets what the vendor does best.