Legacy Software Modernisation: Where Microservices Fit

Legacy software modernisation works best in increments, replacing parts of a product while the old system keeps running. Microservices are one way to break it up, but only at a granularity the domain and the team can carry, and moving to the cloud without changing the architecture removes none of the technical debt. Zoosh Digital's view: start small and grow one piece at a time.

As software applications and products grow, and business priorities tend to block keeping up with the changes in technology, technical debt creeps in and accumulates. The term is “a metaphor, coined by Ward Cunningham”, and the debt makes a product increasingly difficult to maintain.

The technical debt spiral, and why it cannot be deferred forever

Technical debt compounds, because each shortcut slows the next change. In Martin Fowler's explanation of the metaphor, “The extra effort that it takes to add new features is the interest paid on the debt.”

The product becoming more rigid and development slowing down are not the only symptoms of the process of getting into debt.

First, things start to become tightly coupled and changes in one place impact other places. Later, people will add “clever” solutions to some difficulties caused by this to keep up with development speed, which increases fragility. Introducing such hidden meanings and relationships means the “tribal knowledge” increases, which either slows down development or increases the number of bugs and makes maintenance more difficult. The tribal knowledge also makes onboarding new people more difficult, so the business relies more and more on current developers. It's easy to get stuck with the status quo, limiting innovation and not even doing maintenance properly, leading to components and third-party elements getting outdated. Eventually, the whole framework or even the coding language may get outdated, and the company will face difficulties motivating current developers or to find new ones. The system collapses into a black hole.

Individual stories differ, but the sequence tends to run in this order. As the problem spirals out of control, it becomes more and more difficult to get back on the right track. Dealing with it may be avoidable for some time, but it can't be deferred forever. An ERP spirals the same way, through what Zoosh Digital's guide to moving an on-premise ERP to the cloud calls “tightly coupled customisations that make migrations difficult”.

Modernisation techniques: why incremental usually beats a big-bang rewrite

A legacy product is usually modernised more safely in increments, with old and new running side by side, than by a single rewrite and cutover. Microsoft's Azure Architecture Center calls this the Strangler Fig pattern: pieces of functionality are replaced gradually, while “The original system can continue to exist for an extended period of time during the migration effort.”

There are techniques that can be applied at various stages of the process to salvage the product. There may be different ways forward: start improving it bit by bit, swap out some parts with new managed services, separate major pieces but treat them as black boxes first, redesign how internal components communicate with each other, and the list goes on.

Redesigning and rewriting everything with a big bang is typically a last resort. Microsoft recommends the pattern especially when “replacing large systems, key components, or complex features introduces risk”. It might not suit when requests to the old system cannot be intercepted, its source code cannot be accessed, the system is small and simple to replace whole, or the original must be decommissioned quickly.

Otherwise, the practical form is a modernisation programme which can produce results in increments. For application modernisation, Zoosh Digital's guide to side-by-side development around an ERP gives the sequence: “start small, launch a single low-risk integration or app first, then expand iteratively as confidence and internal capability grow.”

The iterative approach de-risks the potential issues of a sudden go-live, and also gives the team time to learn and adapt to the new concepts, languages, frameworks, techniques and services. The current team and their product knowledge is still critical, and this approach will be welcomed as an opportunity rather than as a threat.

Running in the cloud is not the same as being built for it

Cloud infrastructure alone does not change how an application is built: the Cloud Native Computing Foundation (CNCF) defines cloud native by loosely coupled systems, not by where they run.

Using the cloud itself is not enough, as we can run even a monolith in the cloud. The CNCF's Cloud Native Definition v1.1, approved in February 2024, covers public, private and hybrid cloud, and describes “loosely coupled systems that interoperate in a manner that is secure, resilient, manageable, sustainable, and observable.” DORA's research says of architecture outcomes: “It's possible to achieve these outcomes with mainframe technologies. It's also possible to fail to achieve them even when using the latest, most trendy technologies.”

Smaller, loosely coupled components with clear responsibilities change several things:

• The blast radius shrinks, on Microsoft's condition: one failing microservice leaves the rest running “as long as any upstream microservices are designed to handle faults correctly”.
• Teams “can pick the technology that best suits their service”, Microsoft notes.
• “Services can be scaled independently”, it adds.
• Each app “can be developed, deployed and maintained separately”, in Zoosh Digital's integration mindset guide.
• Onboarding and handovers get easier when each component has one clear job.

The price, in Microsoft's microservices guidance: “Each service is simpler, but the entire system as a whole is more complex.”

Managed services, like a managed database, message queue or monitoring, can also reduce complexity and the overall size of the product. Microsoft Dynamics 365 Business Central online is itself built from such parts: Microsoft describes it as “a multitenant service, comprised of multiple microservices running on the Microsoft Azure cloud ecosystem”, using Azure services such as Azure Functions, Key Vault and Service Bus.

Microservices, not taken literally: what they cost and when not to use them

Microservices are “small, independent, and loosely coupled components that a single small team of developers can write and maintain”, in Microsoft's microservices architecture guide: they trade simpler services for a more complex whole, which pays off for complex, fast-changing domains run by mature teams.

There is no one size fits all: the right tool needs to be applied for the job. Stating all big applications should be split up into small “micro” services would be wrong. The amount of functionality (the mass of our system) remains the same, so having a million asteroids flying around instead of a single black hole might make no sense.

The guidance backs that caution: model services around the business domain, “Avoid creating overly granular services, which can increase complexity and reduce performance”, and keep together functions likely to change together. Microsoft's overview of architecture styles sets the clearest limit: microservices suit “complex domains that require frequent changes and innovation”, and because “Success requires mature development and DevOps practices”, they are more suitable for organisations with advanced technical capabilities.

Zoosh Digital's guide to bespoke software development takes the same line: a cloud-native build is “frequently over-specified: not every system needs cloud-native architecture, and building it where you do not need it is a way to spend money on engineering you will never use.”

Eventually, there might be one or a few central stars (core services, like an ERP, a CMS or a main backend service) with planets (authentication, invoice generation) in orbit. Small satellites (serverless functions) orbit a planet with moons (managed services), connected by synchronous and asynchronous inter-planetary radio channels (service discovery, middleware, a service bus or message queues).

While the analogy with a solar system might not be perfect, it highlights that there are many services and tools in the toolbox when it comes to designing a modern, sustainable IT product or system.

Containers on Azure, and what is retiring

Containerisation is a huge help reaching the destination, but needs to be applied with a smart design to end up having the right solar system. As of October 2026, Microsoft's comparison of Azure container options notes that “many teams prefer to start building container microservices with Azure Container Apps.” Container Apps, a serverless platform, “doesn't provide direct access to the underlying Kubernetes APIs”; teams that need them use Azure Kubernetes Service (AKS), where Microsoft recommends AKS Automatic “For most new workloads”. Azure Spring Apps entered a three-year retirement period on 17 March 2025 and will be retired on 31 March 2028; Microsoft recommends Azure Container Apps and AKS as the replacement services.

When the central star is an ERP: building beside Microsoft Dynamics 365 Business Central

When the core service is an ERP such as Microsoft Dynamics 365 Business Central, new services sit beside it and talk to it through its APIs, so “the ERP remains the single source of truth” and its core stays untouched, as Zoosh Digital's integration mindset guide puts it.

Microsoft's integration overview for Business Central calls the REST API stack “The recommended way to use web services for Business Central”. Connect apps should use “Microsoft Entra/OAuth v2 authentication” in production; Basic Auth access keys have been deprecated and unsupported in Business Central online since October 2022. Business events, still in preview, notify and trigger external systems when actions happen in Business Central. Extensions define functionality “as an addition to existing objects”.

Zoosh Digital's guide to what makes a good ERP system describes modern systems built around “a strong, flexible core that can be extended with specialised apps and integrations”. Its guide to the three layers of Business Central integration treats integration as its own workstream, with its own design, testing and maintenance.

Questions to settle before breaking up a legacy product

Four questions decide whether a legacy software modernisation programme should introduce microservices, and one set of measures shows whether it works.

1. Which business priority is the architecture meant to serve? Microsoft's assessment guidance starts here.
2. Does the team have the DevOps practice and distributed-systems skills the style requires?
3. Can requests to the old system be intercepted, and is its source code accessible?
4. Which functions change together, and should therefore stay together?

For the measure, DORA's software delivery performance metrics are five, in two groups: throughput (change lead time, deployment frequency, failed deployment recovery time) and instability (change fail rate, deployment rework rate).

Where Zoosh Digital fits, and where it does not

Zoosh Digital is a Microsoft Dynamics 365 Business Central implementation and technology partner based in Ireland, helping mid-market organisations across the UK, Ireland and Europe design, build and run ERP and bespoke software systems that fit how their people actually work. Its published ERP scope includes ERP architecture and system planning, its bespoke and custom software development sits alongside Business Central, and its Azure infrastructure for Business Central and custom systems follows a stated focus on “clarity and long-term stability, not over-engineering.” Where a microservices programme does not fit, because a product is small and simple to replace whole or nothing in it needs independent deployment, Zoosh Digital recommends one well-structured application, and that is the advice you should expect.

FAQ

What is technical debt?

Technical debt is Ward Cunningham's metaphor for deficiencies in a software system's internal quality, treated like a financial debt. In Martin Fowler's explanation, the extra effort it takes to add new features is the interest paid on that debt.

How is legacy software modernised without a full rewrite?

Legacy software modernisation without a full rewrite replaces pieces of functionality one at a time while the old system keeps running, which Microsoft calls the Strangler Fig pattern. Microsoft notes it may not suit a small system that is simple to replace whole.

What are microservices?

Microsoft defines microservices as small, independent, and loosely coupled components that a single small team of developers can write and maintain, and warns that the system as a whole becomes more complex and needs a mature DevOps culture.

Is a monolith always worse than microservices?

No. DORA notes that loosely coupled architecture outcomes, such as teams deploying independently, can be achieved with mainframe technologies and missed with the latest ones. Microsoft says microservices suit complex domains that require frequent changes and innovation, and need mature development and DevOps practices. Outside those conditions, Zoosh Digital's view is that a well-structured monolith remains a valid choice.

How big should a microservice be?

Microsoft advises modelling microservices around the business domain and avoiding overly granular services. Functions likely to change together should be packaged and deployed together, and each service should stay small enough for a single small team to write and maintain.

Closing thought

The aim is not a galaxy of tiny services but a solar system in which each body has a reason to be where it is, and the first move is usually one small piece pulled out of the black hole. If your product is on that spiral, talk it through with Zoosh Digital, and you may hear that your product needs a modular monolith, its debt paid down where it hurts most.

Referenced sources

• Martin Fowler. Technical Debt (21 May 2019). martinfowler.com/bliki/TechnicalDebt.html.
• Microsoft Learn, Azure Architecture Center. Strangler Fig pattern. learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig.
• Cloud Native Computing Foundation, Technical Oversight Committee. Cloud Native Definition v1.1 (approved 26 February 2024). github.com/cncf/toc/blob/main/DEFINITION.md.
• DORA. Loosely coupled teams. dora.dev/capabilities/loosely-coupled-teams.
• Microsoft Learn. Service overview for Business Central online. learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/service-overview.
• Microsoft Learn, Azure Architecture Center. Microservices architecture style. learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles/microservices.
• Microsoft Learn, Azure Architecture Center. Architecture styles. learn.microsoft.com/en-us/azure/architecture/guide/architecture-styles.
• Microsoft Learn, Azure Architecture Center. Microservices assessment and readiness. learn.microsoft.com/en-us/azure/architecture/guide/technology-choices/microservices-assessment.
• Microsoft Learn. Azure Container Apps overview. learn.microsoft.com/en-us/azure/container-apps/overview.
• Microsoft Learn. Comparing Container Apps with other Azure container options. learn.microsoft.com/en-us/azure/container-apps/compare-options.
• Microsoft Learn. What is Azure Kubernetes Service (AKS)? learn.microsoft.com/en-us/azure/aks/what-is-aks.
• Microsoft Learn. Azure Spring Apps retirement announcement. learn.microsoft.com/en-us/azure/spring-apps/basic-standard/retirement-announcement.
• Microsoft Learn. Integration overview for Business Central (for architects and developers). learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/integration-overview.
• Microsoft Learn. Get started developing Connect apps for Dynamics 365 Business Central. learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-develop-connect-apps.
• Microsoft Learn. Business events on Business Central (preview). learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/business-events-overview.
• Microsoft Learn. Developing extensions in AL. learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-dev-overview.
• DORA. DORA's software delivery performance metrics (5 January 2026). dora.dev/guides/dora-metrics.