Why London Market MGAs Are Replacing Legacy Platforms with Modular Architecture

A pattern is playing out across the London market that would have been unthinkable five years ago. Mid-scale MGAs — the £50M-to-£500M GWP operations that historically ran on monolithic legacy platforms because “that's what serious MGAs run” — are quietly, systematically moving to modular, API-first architectures. Not all at once, and not always through full replacement. But the direction is consistent enough to be a real market shift.

This piece is an objective look at what's driving the shift, what the modular approach actually offers versus what the monolithic incumbents actually offer, and what the practical migration path looks like — because “rip and replace” is the framing most MGAs correctly want to avoid.

The specific pain points driving the shift

The MGAs making this move are not doing it for architectural theology. They're doing it because specific operational realities have become untenable:

Change request economics

On a monolithic platform, a change to a workflow, a rating rule, or a document template is typically a change request billed by the vendor at rates ranging from £1,200 to £2,500 per day, on timelines measured in weeks. For an MGA launching two new product variants a year and adjusting an existing product monthly, this becomes a six-figure operational line item. Worse, the change-request queue at the vendor is competing with every other customer, so timelines are often outside the MGA's control.

On a modular platform where configuration lives with the MGA — workflows built in a visual builder, rating rules edited in a rules interface, templates versioned by the ops team — the same change is measured in hours, done by internal staff, without vendor scheduling.

Implementation timelines

Standard monolithic platform implementation for a mid-scale MGA runs 12 to 18 months. Modular platforms with pre-configured insurance workflows are typically live in 4 to 12 weeks. For an MGA that wants to launch a new product line, the calendar difference is 12 months of foregone premium.

Schema rigidity

Monolithic platforms are typically built around a fixed data model. Adding a field — a new risk classification, a new capacity attribute, a new endorsement type — often requires vendor development work. For an MGA that operates across specialty programs where each product has its own idiosyncratic requirements, this becomes a bottleneck on product design.

Modular platforms typically allow the MGA to extend the schema without vendor involvement, treating the platform as a substrate rather than a fixed system.

Integration cost

Monolithic platforms typically integrate through platform-specific interfaces that require vendor involvement to configure. Every new integration — to a fronting carrier, to a broker platform, to the market's central services — is a project. Modular platforms typically integrate through open APIs where the integration effort is measured in days rather than months.

Total cost of ownership

The published licence cost is only a portion of the total. When you add implementation, ongoing change requests, integrations, upgrades, and the operational cost of vendor dependency, monolithic platforms consistently come in at 3-5x the total cost of modular alternatives over a five-year window for mid-scale MGAs. The trade-off is that monolithic platforms provide more out-of-the-box for very large operations that can amortise the cost.

What the incumbents actually do well

To be balanced: monolithic legacy platforms remain the correct choice for some MGAs and are not being displaced universally. They still lead in:

• Deep out-of-the-box actuarial and reserving functionality for MGAs where these are strategically differentiating
• Established integrations with the market's central services where the vendor has done the integration work at scale
• Regulatory reporting depth across multiple jurisdictions where the vendor has invested in maintaining current reporting logic
• Stability and predictability for operations that have been running on the platform for a decade and value the continuity

MGAs whose core value proposition depends on these specific capabilities have a genuine reason to stay. The MGAs making the shift are the ones whose value proposition is elsewhere — product speed, distribution reach, specialty expertise — and whose platform choice is a means, not an end.

The three migration patterns that actually work

“Rip and replace” is the wrong framing. The MGAs migrating successfully are using one of three patterns:

1. Layered augmentation

The legacy platform stays as the record of transactions. A modular layer is added on top to handle document processing, workflow automation, audit trails, and modern collaboration. The MGA gets capability uplift without the migration risk. This is the fastest path — measured in weeks — but it's bounded by what the legacy platform allows the modular layer to do. See how this pattern also handles Blueprint Two readiness.

2. Product-by-product migration

New products launch on the modular platform. Existing products stay on the legacy platform until natural refresh points (system upgrade cycles, product refresh cycles, or specific triggers like a change of managing agent). Over 18-36 months, the balance shifts. Lower risk than a big-bang migration because each product carries its own contained project.

3. Line-of-business migration

A specific line of business (typically a specialty line with the least legacy dependencies) moves fully to the modular platform. Once operational learnings are captured, other lines follow. Common for MGAs that want to test the modular platform against a real production line before committing further.

The four questions to ask any vendor claiming to be modular

“Modular” and “API-first” are now marketing terms as much as architectural claims. The four questions that separate real modularity from repackaged monoliths:

1. Show me the API documentation. If it exists as a genuine public reference (endpoint-level, with authentication, versioning, and sample payloads) and integrations are done against it, the platform is API-first. If “API” means “we'll expose the fields you need via a data services team,” it's a monolith with an integration wrapper.
2. Show me a configuration change your customer made yesterday. Not “here's what customers can theoretically configure.” A change that customer support didn't touch. If the answer is “our services team makes those changes,” the platform is not configurable.
3. What's the release cadence? A modular platform releases continuously or on a fast cadence (weeks). A modernised monolith releases in named versions on a slow cadence (quarters).
4. What's in the base platform vs the modules? A genuine modular platform gives you a core plus the modules you need. A modernised monolith gives you everything whether you use it or not, and prices accordingly.

Where a layered approach usually lands first

For MGAs not ready to commit to a full migration, the operational areas where a modular layer typically delivers the fastest visible ROI:

• Document processing and extraction (the ACORD and submission-processing workflows)
• Structured collaboration around underwriting and claims decisions
• Compliance dashboards and evidence generation
• Bordereau generation with schema enforcement — see the bordereaux fix
• Modern audit trails with cryptographic integrity — see what auditors look for

The MGA solution page covers the specific layered capabilities. For the platform-level view, how a layered PAS approach works.

Bottom line

The shift from monolithic legacy platforms to modular architecture in the London MGA market isn't driven by architectural preference. It's driven by unfavourable change-request economics, unrealistic implementation timelines, schema rigidity, and TCO that no longer stands up to comparison. The MGAs making the shift are doing it pragmatically — layered augmentation first, targeted migration second, full replacement rarely.

The MGAs staying on incumbent platforms have specific and defensible reasons — actuarial depth, established integrations, regulatory reporting continuity. The MGAs staying because “that's what serious operations run on” are the ones most exposed to the shift.