The problem
The client's ERP was a monolithic .NET Framework 4.6 application built over 12 years. Every deployment required a 4-hour manual process coordinated across three teams. Feature branches lived for months because merging to main meant scheduling a deployment window two sprints ahead.
TODO: copy from Zane — real pull quote from the client.
Our approach
We applied the strangler-fig pattern: standing up a new Azure-hosted service layer alongside the monolith, routing traffic incrementally, and retiring legacy modules one at a time.
Phase 1 — Assess and sequence
We audited the monolith over two weeks, producing a dependency graph and a ranked list of modules by isolation risk and business value. The client left that phase with a sequenced migration roadmap — no big-bang rewrite, no six-month planning phase.
Phase 2 — Extract the data layer
The database was the biggest coupling point. We introduced an event-driven layer using Azure Service Bus, allowing new services to publish and subscribe without touching the monolith's SQL schema. Existing integrations continued to work through the transition.
Phase 3 — AKS migration and cutover
We containerised each extracted service and deployed to Azure Kubernetes Service with horizontal pod autoscaling. The monolith stayed on its original VM until the final cutover — production was never at risk.
Outcomes
Deployment frequency went from once per sprint to on-demand. The infrastructure cost dropped by 60% as we right-sized workloads and eliminated on-premises servers.