Monolith to Microservices: When to Make the Move

Updated 7 November 2026 · Standard formula, shown below

This article helps you decide when to migrate a monolithic application to microservices. You’ll learn the key triggers that justify the move, the costs and risks involved, and how to approach the transition. The answer is: migrate when your monolith’s structural limitations actively slow down independent team velocity, scaling, or reliability, and you have the organizational maturity to handle distributed systems.

What Is a Monolith and What Are Microservices?

A monolith is a software application where all components—user interface, business logic, data access—are packaged and deployed as a single unit. This is the default architecture for most new projects because it’s simple to develop, test, and deploy. Microservices, by contrast, break the application into small, independently deployable services, each owning its own data and communicating via APIs (usually HTTP/REST or messaging).

Microservices are not a silver bullet. They introduce network latency, distributed data management, and operational complexity. Many teams adopt them because they’re trendy, only to find they’ve traded a manageable monolith for a distributed mess. The decision should be driven by concrete pain points, not fashion.

Signs You Should Consider Moving

Here are the most common triggers that indicate a monolith is becoming a bottleneck:

Team scaling issues: If you have multiple teams working on the same codebase, merge conflicts and coordination overhead become constant. Microservices allow each team to own a service end-to-end.
Independent deployment needs: When one small change requires a full regression test and coordinated release across the entire app, microservices can let you deploy a single service without affecting others.
Scaling bottlenecks: If a specific feature (e.g., image processing) consumes disproportionate CPU/memory, you must scale the entire monolith. Microservices let you scale only the needed service.
Technology constraints: A monolith typically forces a single language and framework. If a new service would be much easier in a different language, microservices allow that.
Reliability issues: A bug in one module can crash the whole application. Microservices isolate failures, but they also add network failures and partial failures.

These are all valid reasons, but they must be severe enough to justify the operational overhead.

When NOT to Move

You should probably stay with a monolith if:

Your team is small (less than ~10 developers) and the codebase is manageable.
Your application is simple or has low traffic.
You don’t have dedicated DevOps or infrastructure expertise.
Your domain is highly cohesive and changes are usually cross-cutting.
You’re a startup that needs to iterate fast; a monolith is faster to build and change.

Many successful companies (e.g., Shopify, Basecamp) run large monoliths for years. The cost of microservices—distributed tracing, service discovery, CI/CD pipelines, container orchestration—can easily exceed the benefits for a small team.

How to Approach the Migration

Never do a ‘big bang’ rewrite. The safest path is incremental extraction, often called the strangler fig pattern. Start by identifying the most painful module (the one that causes the most deploys, bugs, or scaling issues) and extract it into a service.

Identify boundaries: Use domain-driven design (DDD) to find bounded contexts. For example, in an e-commerce app, ‘inventory’ and ‘shipping’ are likely separate contexts.
Extract one service at a time: Create a new service that replicates the module’s functionality. Move the data first (or use a shared database temporarily), then redirect the monolith to call the service via API.
Freeze the old module: Once the service is live, remove the old code from the monolith.
Repeat: Continue with the next module, but only if the pain persists.

This approach minimizes risk and lets you stop at any point. You might extract just one service and keep the rest as a monolith—that’s perfectly valid.

Common Problems and Misconceptions

One common misconception is that microservices are ‘more secure’ or ‘faster.’ In reality, they add network overhead and a larger attack surface. Another is that microservices mean ‘no shared database.’ While each service should own its data, you’ll often need to replicate or synchronize data across services, which is complex.

Other frequent issues include:

Distributed transactions: ACID transactions don’t span services. You need sagas or eventual consistency.
Testing complexity: Integration testing across services is harder than testing a monolith.
Operational burden: You need monitoring, logging, and tracing for each service.
Team coordination: APIs become contracts that need versioning and governance.

Costs and Trade-offs

The move is expensive. Estimate the cost in engineering time, infrastructure, and training. You’ll need:

Containerization (e.g., Docker) and orchestration (e.g., Kubernetes).
Service discovery, API gateways, and load balancers.
Distributed tracing (e.g., Jaeger) and centralized logging.
CI/CD pipelines per service.

These are not trivial. A team that spends 20% of its time on infrastructure will be slower to deliver features. The trade-off is that you gain independent scaling and team autonomy, but you lose simplicity.

Alternatives to Microservices

Before committing, consider these alternatives:

Modular monolith: Keep a single deployment unit but enforce strong module boundaries. This gives you some of the benefits (clear ownership, testability) without the distributed complexity.
Service-based architecture: A middle ground where you have a few coarse-grained services (not dozens of microservices).
Just refactor the monolith: Sometimes the problem is poor code structure, not the architecture. Improving the codebase may solve the pain.

These options are often more cost-effective and less risky.

Frequently Asked Questions

How do I know if my monolith is ‘too big’?

There’s no magic line. Look at concrete metrics: time to deploy, frequency of merge conflicts, time to onboard new developers, and how often a change in one module breaks another. If these are consistently bad and refactoring doesn’t help, consider extraction.

Can I move just one part of a monolith?

Yes. The strangler fig pattern allows you to extract a single service and keep the rest as a monolith. This is often the best approach—you only pay for the complexity where you need it.

What’s the biggest mistake teams make?

Starting the migration without a clear pain point. Many teams move to microservices because they think it’s ‘best practice,’ then spend months on infrastructure instead of features. Always start with a specific problem.

How long does a typical migration take?

It varies wildly. A single service extraction can take weeks; a full migration can take years. It’s not a one-time project—it’s an ongoing process. Plan for at least 6-12 months for a medium-sized application.

Do microservices require Kubernetes?

No. You can deploy microservices on simple VMs or serverless functions. Kubernetes helps with orchestration but adds significant complexity. Start with simpler options if you’re new.

What is the ‘distributed monolith’ anti-pattern?

It’s when you have microservices that are tightly coupled—they share a database, call each other synchronously in a chain, and must be deployed together. This gives you all the downsides of microservices with none of the benefits. Avoid it by respecting service boundaries and using asynchronous communication where possible.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.