Learn how CDL transformed its Policy Administration System to unlock speed, modularity, and cloud-native execution.
Overview
Founded in 1977, CDL (Cheshire Datasystems Ltd.) is a leading UK financial services technology (insurtech) company. Often described as “the veins of the UK insurance industry,” CDL powers roughly 60% of all UK insurance quotation traffic, processing over one trillion transactions every year. Its systems sit behind the nation’s most widely used price comparison websites. Nearly every consumer shopping for home or car insurance touches CDL technology.
The policy app powering CDL’s business
CDL’s Policy Administration System is a mission-critical application that manages the policies and transactions driving the UK personal lines insurance market, covering consumer-focused products. Originally built as a classic three-tier Oracle application, the policy application has expanded to over a million lines of code and now supports the majority of CDL’s transaction volume.
With more than 100 engineers dedicated to its development and upkeep, the policy app represents both CDL’s strength and its modernization challenge. It’s the backbone of the business, but also a massive, tightly coupled system. The question became: How do we evolve a monolith of this scale without disrupting the trillion-transactions per year it powers?
Unraveling a “big ball of mud”
The policy app was the definition of a “big ball of mud.” Builds stretched to 90 minutes, releases could take weeks, and modernization efforts often stalled before they began. To change this, CDL moved aggressively to the cloud—containerizing on AWS Fargate, adopting PostgreSQL on AWS RDS, and modernizing pipelines with GitLab SaaS CI/CD.
The impact was real: release cycles accelerated, builds were cut in half, and engineers began acting with confidence, backed by data and rollback safety nets. CDL did everything right—modernizing infrastructure, embracing automation, and adopting open source wherever possible:
- Containerization & Fargate → eliminated patching, enabled elastic scale
- Oracle → PostgreSQL → freed engineers from licensing and vendor lock-in
- Managed RDS databases → DBAs shifted from maintenance to optimization
- Modern analytics stack → standardized ETL, sped up customer engagements
- DevOps evolution (Garrett + Jenkins → GitLab CI/CD SaaS) → enabled blue-green deployments, reduced fear of change, broke analysis paralysis
But despite these wins, complexity at the core of the app persisted. Long-tenured engineers held tribal knowledge essential to progress, and when one left, entire analysis cycles collapsed. Attempts to decouple or extract services repeatedly slipped back into analysis paralysis.
CDL had reached the cloud—but not cloud-native agility.
“Just because you’ve moved to the cloud doesn’t mean you’re cloud-native. We did five of the six things AWS recommends, and I’d still say we had half the value left on the table.”
Matthew Eisengruber, Head of Architecture, CDL
The turning point
To break through, CDL deployed vFunction. Agents were connected to a performance-test environment, combining static and runtime analysis. Within a day, the vFunction architectural modernization platform produced a domain map of the policy app—surfacing dependencies, hidden flows, and service candidates that had taken months to identify manually.
For the first time, the team had evidence instead of assumptions. They could simulate the extraction of a component and immediately see the dependencies to break, calls to adjust, and cycles to address.
“Where we were stuck in analysis paralysis, vFunction let us run a scenario in hours. Instead of saying, ‘we think this is how it works,’ we could see exactly what needed to be done.”
From to-dos to execution with Amazon Q Developer
The tasks (to-dos) generated by vFunction became more than lists—they became execution prompts. Using vFunction’s MCP integration, CDL engineers copied auto-generated architectural prompts directly into Amazon Q Developer, already deployed across the organization.
This workflow allowed engineers to validate AI-assisted changes in their IDEs, such as dead-code removal or boundary cleanup. Developers no longer had to know every dependency before starting; they simply validated and refined the AI’s output.
As Matthew described it:
“For us, having that level of visibility into the architecture — and being able to feed it straight into Amazon Q Developer — completely changes the game. It’s not just analysis anymore; it’s execution. The team can see the issues, act on them, and actually measure the impact.”
What’s next
With vFunction and Amazon Q Developer, CDL is building a repeatable modernization loop. The team maps and simulates candidate components, generates actionable to-dos and GenAI prompts, and uses Amazon Q Developer to accelerate refactoring. They track improvements in release cycles, build times, and cost efficiency while scaling governance to prevent new coupling and maintain clean service boundaries, ensuring modernization remains an ongoing, self-sustaining process.
