Modernizing a core platform is easy to describe in architecture diagrams. The difficult part is deciding what to change first, how to separate tightly coupled capabilities, and how to keep data moving while the old and new environments coexist.
That was the challenge behind The Unlimited’s platform modernization.
The insurer’s core application had evolved into a tightly coupled monolith. Documentation was limited, several operational processes were manual, and years of technical debt had made enhancements slower and riskier. The system also ran on on-premise infrastructure that constrained future scale and carried higher maintenance overhead.
The modernization therefore had to solve more than an infrastructure problem. It required a controlled shift in architecture, service boundaries, deployment, integration, and operational visibility.
The first step was understanding the system before changing it
The team did not begin by immediately breaking the monolith into services.
With minimal documentation available, Cygnet.One and The Unlimited first worked with business users to understand how the platform operated at an operational level. This discovery happened before new code was written.
That mattered because service decomposition depends on understanding more than source code.
A core insurance platform carries business behavior across areas such as product management, collections, communications, customer management, and lead management. Separating those capabilities without understanding how they interact can simply move complexity from one large application into several smaller ones.
The modernization therefore started with business processes, operational behavior, and system dependencies before moving into implementation.
The architectural shift was from one core to independent services
The target architecture replaced the monolithic application with a cloud-native microservices platform hosted on Microsoft Azure.
Core functions including product, collections, communications, customer management, and lead management were separated into independent services. Each service followed a single-responsibility approach, making individual capabilities easier to enhance, scale, and extend.
The architecture used:
- Azure Kubernetes Service to host the microservices
- Azure Application Gateway for routing and authentication
- RabbitMQ for asynchronous communication between services
- Microsoft Dynamics 365 as an integrated CRM environment
- Azure Monitor and Application Insights for observability
- Azure SQL within the cloud data layer
The architecture diagram in the approved case study shows mobile, web, and CRM applications entering through the cloud API gateway. Requests are routed to the appropriate services, while an asynchronous messaging layer connects services and supports CRM synchronization. Centralized monitoring and logging provide visibility across the platform.
This matters because microservices alone do not create a better platform. The surrounding routing, messaging, observability, data, and deployment mechanisms determine whether the architecture can operate reliably as the number of services grows.
The transition happened in phases
One of the most important engineering decisions was avoiding a single replacement event.
For much of the modernization, the legacy and new platforms operated side by side. Capabilities were moved progressively while the two environments continued exchanging data.
The implementation progressed from the base architecture into individual microservices and then into their integration as a complete platform.
This created a controlled transition path.
Instead of forcing the entire system across one technical boundary at once, the team could establish the new architecture, move selected capabilities, maintain data exchange, and continue expanding the new platform in stages.
For complex enterprise systems, this pattern reduces the number of simultaneous changes that need to be managed during modernization.
Service boundaries followed business capabilities
The way the monolith was decomposed is another important part of the architecture.
The services were organized around recognizable business functions such as:
Product | Collections | Communications | Customer | Lead Management
That creates clearer ownership than dividing a system purely around technical layers.
A product capability, for example, can evolve independently from collections or communications. Changes to one area do not require the entire application to move through the same release cycle.
This is one of the practical advantages the new architecture introduced. The approved case study specifically notes that independent services made the platform easier to enhance and faster to release.
Asynchronous messaging reduced direct service dependency
Breaking a monolith into smaller services also introduces a new challenge: communication between those services.
The Unlimited’s architecture uses RabbitMQ as an asynchronous messaging layer. Rather than requiring every service interaction to happen synchronously, services can exchange information through messaging while remaining independently deployed.
The same messaging layer also supports synchronization with the CRM environment.
This is an important architectural distinction. A microservices platform that recreates tight dependencies through direct service calls can carry many of the same coupling problems as the monolith it replaced.
Asynchronous communication gives services more separation while supporting the data exchange required across the platform.
Observability became part of the architecture
Distributed systems create more operational components to monitor.
The modernization therefore included Azure Monitor, Application Insights, and centralized logging to provide visibility into system health across the platform.
This is an important part of the engineering story because observability cannot be treated as an operational add-on once an application has been decomposed.
With multiple independently running services, teams need visibility across requests, integrations, messaging, and service behavior. Otherwise, architectural independence can make production issues harder to trace.
By including monitoring and centralized logging within the platform design, the team created the operational visibility required for a distributed architecture.
What this modernization pattern shows
The Unlimited project surfaces several practical principles for teams considering a similar move from a monolithic platform.
Start with operational understanding.
The first major task was discovery. The team worked with business users to understand how the platform actually operated before making architectural decisions.
Decompose around meaningful capabilities.
Product, collections, communications, customer, and lead management became independent services rather than remaining inside one tightly coupled application.
Create a transition architecture, not only a target architecture.
The old and new systems had to coexist and exchange data while the migration progressed. The engineering challenge therefore included the path between architectures, not simply the final state.
Design operations into the platform.
Messaging, monitoring, logging, routing, and deployment were part of the architecture itself. They were necessary components of running independent services at scale.
The result was more than a change in architecture
The modernization replaced the legacy monolith with a cloud-native microservices platform and established a stronger foundation for The Unlimited’s insurance operations.
Field teams can capture policy data without a constant internet connection and synchronize it when connectivity returns. Manual, paper-based processes are supported by digital workflows, and the platform is positioned to accommodate future customer growth without the fixed capacity constraints of the previous on-premise environment.
The platform also gives the teams a foundation they can continue extending as new requirements emerge, rather than repeatedly starting over.
For enterprise modernization teams, that may be the more useful architectural lesson from this case.
A target architecture matters. The transition architecture, service boundaries, and operating model required to reach it matter just as much.
Author
Yogita Jain
Content Lead
Yogita Jain leads with storytelling and Insightful content that connects with the audiences. She’s the voice behind the brand’s digital presence, translating complex tech like cloud modernization and enterprise AI into narratives that spark interest and drive action. With a diverse of experience across IT and digital transformation, Yogita blends strategic thinking with editorial craft, shaping content that’s sharp, relevant, and grounded in real business outcomes. At Cygnet, she’s not just building content pipelines; she’s building conversations that matter to clients, partners, and decision-makers alike.