Three Products, One Platform: Consolidating Without a Big Bang
A European insurtech group had grown by acquisition: three products, three stacks, three customer records, sold as a suite but sharing nothing. The plan on the table was a 24-month all-or-nothing consolidation — and the CEO’s objection, "what ships during those two years?", was the one that kills most such programmes. Envion reframed the question: what must these products share, and what should stay separate forever? Six capabilities carried all the value; the rating engines stayed separate by design, removing a third of the plan and nearly all of its risk. Five stages sequenced against the commercial calendar delivered the first capability in month 4, €7.4M of cross-sell revenue, zero duplicate customer records, and ~70% of normal product velocity throughout.
The challenge
The group had grown by acquisition: a motor insurance platform, a property platform, and a broker portal, each with its own stack, its own database, its own customer record, and its own team. Commercially they were sold as a suite. Technically they shared nothing.
The costs were becoming visible in ways the board could see. A customer with motor and property cover existed twice, with no view of them as one relationship. Regulatory reporting was assembled by hand across three systems every quarter. Cross-sell — the entire thesis of the acquisitions — required an integration that didn't exist. And a new product launch meant building it three times or picking one platform and disappointing two customer bases.
The CTO's proposal was consolidation onto the motor platform, the largest and most modern, estimated at 24 months. The CEO's objection was straightforward: what ships during those two years? That's the right objection, and it's the one that kills most consolidation programmes — not because the target is wrong, but because nobody sequences the path against what the business needs in the meantime.
Decision path
Envion asked a different question first: what do these products actually need to share, and what should stay separate forever?
Consolidation is usually posed as all-or-nothing, and it almost never should be. The three systems were decomposed into capabilities and sorted into three groups.
Must be shared — the value of the group depends on it: customer and party data, policy record, document store, regulatory reporting, authentication, payments. Everything the board cared about traced to one of these six.
Should be shared eventually — real savings, no strategic urgency: notifications, claims intake, partner integrations.
Should stay separate — permanently: underwriting and rating logic. Motor rating and property rating share almost no domain concepts; the actuarial teams are separate; the regulatory regimes differ. Merging them would produce a system serving neither well and requiring both actuarial teams to agree on every change. The original 24-month plan had this consolidation in it, and it accounted for a substantial share of the effort and nearly all of the risk.
That reframe alone cut the programme materially. What remained was sequenced by business value rather than technical dependency.
Envion contribution
Five stages, each delivering something the commercial team could sell or the board could see.
Stage 1 (months 1–4) — unified party and customer: a shared customer and party service, with all three products writing to it via an anti-corruption layer while continuing to read from their own stores during transition. Delivers the single customer view and the cross-sell capability the acquisitions were bought for.
Stage 2 (months 3–7) — shared policy record: a canonical policy representation populated by change data capture from the existing systems, deliberately read-only at first. Delivers group-level regulatory reporting, removing a quarterly manual exercise the board had been asking about for two years.
Stage 3 (months 6–12) — shared document and payments: the clearest cost duplication, and low commercial risk.
Stage 4 (months 10–18) — strangle the broker portal onto shared services: the smallest product first, precisely because a mistake there is survivable.
Stage 5 (months 16–30) — property platform onto shared services. Rating engines untouched, by design.
The trade-offs were written down as decision records for the four choices that would be expensive to reverse — each stating what was being given up: eventual consistency of seconds in the policy record (in exchange for no source-system changes); anti-corruption layers everywhere (in exchange for independent migration schedules); shared services as services rather than a library (in exchange for three teams on three stacks being able to consume them); and rating staying separate (permanently forgoing unified rating efficiency, in exchange for removing the highest-risk component entirely).
Delivery
Each stage shipped against the commercial calendar rather than a technical master plan, with the anti-corruption layers letting each product migrate on its own schedule — no coordinated releases, no freeze.
The decision records became a working artifact: when someone asks why the policy record is eventually consistent, there is a document that says what was chosen and what it cost.
Outcome and evidence
Twenty-four months in: the first commercial capability had landed in month 4 instead of month 24, cross-sell revenue stood at €7.4M written, duplicate customer records fell from ~38% of the base to zero, quarterly regulatory reporting dropped from about three weeks of manual assembly to two days, and the product roadmap ran at roughly 70% of normal velocity throughout — instead of the expected freeze. Zero rating engines were consolidated, by design, and a new product launch now takes one build plus rating instead of three.
A trade-off that's been named can be revisited deliberately when conditions change. An implicit one just becomes a mystery that a future team resents.
| Metric | Before | After |
|---|---|---|
| Programme scope | 24 months, all-or-nothing | 30 months, 5 shippable stages |
| First commercial capability delivered | Month 24 (planned) | Month 4 |
| Cross-sell revenue | €0 | €7.4M written |
| Duplicate customer records | ~38% of base | 0 |
| Quarterly regulatory reporting effort | ~3 weeks manual | 2 days |
| Product roadmap delivery during programme | Expected freeze | ~70% of normal velocity |
| Rating engines consolidated | 2 (planned) | 0 (by design) |
| New product launch effort | 3× build | 1× build + rating |
Client feedback
What the client says about this engagement
“The version we'd planned delivered nothing for two years and then, in theory, everything. Oleg's version delivered the cross-sell capability in month four, which is what we'd bought these companies for.
The finding I hadn't expected was that we should never merge the rating engines — that was a third of the original plan and most of the risk, and his argument was that our actuaries would end up needing to agree with each other about everything, which is true and would have been miserable. The decision records are the artifact I've kept using. When someone joins and asks why the policy record is eventually consistent, there's a document that says what we chose and what it cost us.”
From the engagement lead
What I’d tell anyone considering this
“If you're consolidating platforms after acquisitions, sort capabilities into must share, could share, and should never share before you plan anything. The third category is where the savings are, because the effort you don't spend is free — and it's the category nobody creates. Consolidation programmes are written as though sharing everything is self-evidently the goal.
Then sequence by business value, not technical dependency. It's usually possible to reorder the work so something commercially useful lands in the first quarter, and doing so changes the political economy of the whole programme. A consolidation that has delivered visible value is very hard to cancel. One that's eighteen months from its first output is cancelled the moment the market turns.”
Evidence gate. This page publishes only what Envion's project records and client disclosure permissions support. Outcomes are added once verified against a baseline, a measurement period, and an approved source.
FAQ
Questions about this case
Facing a similar challenge?
Consolidating platforms after acquisitions? Sort must-share from never-share first — Envion sequences the path so something commercially visible lands in the first quarter.
Discuss a Similar ChallengeKeep exploring
Similar case studies
Executive Technology Leadership
Support for high-stakes product and AI decisions
Bring senior technology leadership into the business when the roadmap is unclear, delivery is at risk, an AI initiative needs stronger ownership, or the company needs an experienced technical voice before hiring a permanent CTO.
Discuss Interim CTO SupportCore responsibilities
- Align product and technology priorities with business goals and measurable outcomes.
- Review architecture, delivery risks, data foundations, security needs, and AI readiness.
- Lead internal teams and external partners through a practical execution plan.
- Clarify team structure, ownership, decision rights, and delivery cadence.
- Support investor, board, partner, and due-diligence conversations with credible technical judgment.
New experience
Prompt-to-Page — try it right here
Describe the landing page you want, in your own words. We turn it into a finished page and email you a private link in 5–10 minutes — no briefs, no calls, $0 to see the result.
- Describe what you want to create.
- We structure, write, and compose the page.
- You receive a private link when it is ready.
Start with a sentence — the interactive builder takes it from there.
Generate My PageSafe, respectful content only. No obligation.