Monolith to Microservices Migration, Step by Step

Many established software products started as a single application: one codebase, one database and one deployment. That design is often the right one for years. Problems appear as the product and the team grow: a small change needs a full release, one slow feature affects everything, and teams wait on each other to deploy. A monolith to microservices migration splits the application into smaller services that can be built, deployed and scaled independently. Done well, it speeds up delivery. Done badly, it multiplies complexity without solving the original problems. This guide explains when a migration makes sense, how to do it incrementally, how to move data safely and which mistakes to avoid, with a worked example.

Should you migrate at all?

Microservices are a means, not a goal. Before planning a migration, write down the problems you want to solve and check whether splitting the application is the best fix:

ProblemMicroservices help?Often a simpler fixReleases are slow and riskySometimesAutomated tests and a deployment pipelineOne component needs far more capacity than othersYesScale that component separately if possibleMany teams block each other in one codebaseYesClear module boundaries inside the monolith firstThe application is slow overallRarelyProfiling, caching and database tuningThe code is hard to understandRarelyRefactoring and better module structure

A well-structured monolith, sometimes called a modular monolith, solves many of these problems with far less operational overhead. If your organisation cannot yet run automated deployments, monitoring and on-call support for one application, running twenty services will be harder still.

Planning a monolith to microservices migration incrementally

The safest approach is incremental. The strangler fig pattern, described by Martin Fowler and in AWS Prescriptive Guidance, puts a routing layer in front of the monolith and moves one capability at a time into a new service. Requests for that capability go to the new service; everything else still goes to the monolith. Over time the monolith shrinks until it can be retired or kept as a small core.

A typical sequence looks like this:

1. Put a proxy or API gateway in front of the monolith, so routing can change without clients noticing
2. Choose a first capability with clear boundaries and modest risk
3. Build the new service, with its own deployment pipeline and monitoring
4. Route a small share of traffic to it, compare results, then route everything
5. Remove the old code path from the monolith
6. Repeat with the next capability

Good first candidates are capabilities with few dependencies on the rest of the code, such as notifications, document generation, search or reporting. Poor first candidates are the core transactions everything else depends on.

Drawing service boundaries

Boundaries should follow business capabilities, not technical layers. "Invoicing", "catalogue" and "customer accounts" make good services. "Database service" and "validation service" do not, because almost every change would touch them. A useful test: can one team change and release this service without coordinating with others for most changes? If not, the boundary is probably wrong.

Keep services fairly coarse at first. It is easier to split a service later than to merge services that turned out to be too small.

Data is the hardest part

Splitting code is relatively easy; splitting a shared database is not. Each service should own its data, but the monolith's tables are usually connected by joins, foreign keys and shared transactions.

Common techniques include:

• Moving a set of tables to the new service and giving the monolith an API to read them
• Keeping a read-only copy of data in another service, updated through events
• Running both writes for a period, with reconciliation to catch differences
• Replacing cross-service transactions with steps that can be retried or compensated

Plan the data move for each capability as carefully as the code. Reconcile counts and key values after each step, and keep a way back until the new service has proven itself.

Platform foundations you need first

Each new service adds deployments, logs, configuration and failure modes. Before the first service goes live, put in place:

• Automated build, test and deployment pipelines for every service
• Containers or another consistent packaging approach
• Centralised logs, metrics and tracing with correlation IDs
• Configuration and secrets managed outside the code, in line with the Twelve-Factor App principles
• Health checks, timeouts and retries between services
• A clear owner for each service

Orchestration platforms such as Kubernetes help run many services, but they add their own learning curve. A managed container service is often enough for the first few.

Worked example: extracting invoicing from a monolith

Suppose a B2B software company runs a monolithic web application on a single relational database. Invoicing causes most of the release pain: billing rules change monthly, and each change requires a full release of the whole application. The team decides to extract invoicing first.

PhaseWorkDuration (planned)Exit check1Add an API gateway in front of the monolith2 weeksAll traffic flows through the gateway with no errors2Build the invoicing service with its own pipeline6 weeksPasses the same test cases as the monolith3Copy invoice tables to the service; sync changes both ways3 weeksDaily reconciliation shows zero differences4Route 10% of invoice requests to the new service2 weeksError rates and totals match the monolith5Route all invoice requests; monolith becomes read-only for invoices2 weeksNo reconciliation differences for 14 days6Remove invoicing code and tables from the monolith2 weeksMonolith tests pass without invoicing

The gateway routes by path, so moving traffic is a configuration change, not a release. During phase 4, the team compares invoice totals produced by both systems for the same orders and investigates every difference before increasing traffic. The durations are planning estimates for this hypothetical example; real timelines depend on the code and the team.

After the migration, billing changes ship in the invoicing service alone, without touching the rest of the application. The team then reviews whether the next pain point justifies another extraction or whether a modular structure inside the remaining monolith is enough.

Common migration mistakes

• Splitting into many tiny services at once
• Sharing one database between services indefinitely
• Starting with the most critical, most connected capability
• Skipping monitoring and tracing until problems appear
• Rewriting everything from scratch instead of migrating incrementally
• Treating the migration as a purely technical project with no business milestones

A migration also changes how services connect to other business systems; our guide to business systems integration covers integration design that lasts. Staged rollouts with clear exit checks work the same way for business software, as our guide to custom ERP implementation shows.

Frequently Asked Questions

When should we migrate from a monolith to microservices?

When specific problems, such as teams blocking each other or one component needing separate scaling, cannot be solved by better structure and automation inside the monolith.

What is the strangler fig pattern?

An incremental approach where a routing layer sends requests for one capability at a time to a new service, while the monolith handles the rest, until the old code can be removed.

How long does a monolith to microservices migration take?

It depends on the size of the application and how many capabilities you extract. Each extraction is usually planned as its own project with clear exit checks.

Do we need Kubernetes for microservices?

Not necessarily. Managed container services can run a small number of services well. Orchestration platforms become more useful as the number of services grows.

Plan your migration with us

We help teams decide whether to migrate, design service boundaries and move capabilities out of monoliths safely. See our custom app development services, or talk to us about your application.

About the Author

Manav Sharma is the founder of Insyrge and a CRM solutions architect. He works across Zoho, Salesforce, HubSpot, Odoo and more, designing the CRM setups, integrations and automations that keep sales and operations teams working from the same data.