Detailed, anonymised examples of complex software modernisation, architecture and engineering leadership work.
These case studies focus on the situation, constraints, decisions and delivery approach. Client and employer names are deliberately omitted.
Case study: Modernising a 30-year-old lending platform
The situation
A business-critical loan and lease management platform had evolved over approximately 30 years. Its core application was written in VB6, supported by older .NET Framework 4.0 WCF and SOAP services. Earlier versions had been designed to work with Microsoft Access as well as legacy versions of SQL Server.
The platform continued to support active customers while financial products, regulations and customer expectations changed around it. Modernisation therefore had to progress alongside commercially important customer delivery.
The challenge
The platform contained decades of lending behaviour, customer-specific functionality and operational knowledge. A wholesale rewrite would have introduced considerable business and delivery risk.
- A tightly coupled desktop monolith
- Nightly batch processing
- Multiple languages and development models
- A desktop deployment model that complicated releases
- Continuous demand for customer and regulatory changes
- Bespoke customer branches and product versions
Some high-value customers had historically received dedicated branches containing bespoke developments. This increased platform divergence and reduced the engineering capacity available for coordinated modernisation.
My contribution
I provided technical and engineering leadership across teams totalling approximately 15 to 20 engineers and QA specialists.
- Led teams moving capabilities from VB6 into modern .NET
- Made architectural decisions about separating functionality from the monolith
- Identified capabilities that could be extracted safely
- Supported the move towards a consistent .NET and Azure engineering stack
- Challenged reliance on nightly batch processing
- Sequenced modernisation alongside ongoing customer commitments
- Guided the transition from desktop software towards a web platform
The approach
We adopted an incremental strangler fig approach rather than attempting to replace the entire platform at once.
Selected capabilities were moved from VB6 into modern .NET components and Azure-native services. Azure Functions provided independently deployable processing for focused workloads, while Azure Service Bus introduced asynchronous messaging between capabilities.
Payment processing was a key example. Older processing patterns were progressively replaced with webhook and event-driven integrations using Azure Functions and Service Bus. This reduced direct coupling with the monolith and supported more responsive, resilient processing.
Moving towards a common .NET and Azure stack made new development easier to understand and maintain. The next stage focused on progressively replacing desktop capabilities with a React application backed by .NET 10 REST APIs.
Outcome
The programme established a credible route away from a 30-year-old VB6 platform without relying on a high-risk rewrite.
Moving selected capabilities into modern .NET, Azure Functions and Azure Service Bus reduced the number of technologies engineers needed to work across. It also created clearer service boundaries and introduced independently deployable, event-driven processing.
Payment processing began moving towards webhook and message-based integration, reducing direct dependency on the desktop monolith and older batch-oriented processes.
The work also provided the architectural foundation for replacing the desktop application with a React and .NET 10 web platform. The programme remains in active development and has received approval for a dedicated three-month delivery phase.
The result is more than a technology upgrade. The organisation now has a controlled modernisation strategy that protects existing lending operations while progressively improving development, integration, resilience and deployment.
