Monolithic to Microservices: When and When Not to Migrate

Martin Fowler has tracked microservices migrations for decades, and his findings are consistent: the teams that succeed almost always started with a monolith that outgrew itself. 

Uber, managing more than 2,200 critical services, learned that lesson at scale. Microservices deliver operational flexibility but they carry a complexity cost that grows with every service boundary you draw. AWS’s prescriptive guidance puts a sharper point on it, stating that premature decomposition is costly, especially when the domain is unclear.

The question for most engineering teams is whether they have the domain clarity, observability, and operational ownership to make that trade-off work. This guide helps you find out.

Monolith vs. microservices: Are you asking the right questions?

If you’re moving to microservices to go faster, you might be buying a lie. In a monolith, you deal with a big, messy codebase, but your feedback loop is often a single command. 

In a microservices environment, you’re likely stuck in a queue. When more than 100 developers are all pushing code, and every PR triggers a full web of integration tests, that queue has a $500,000 price tag or more in monthly CI time alone.

And those developers are sharing two or three environments between them, nowhere near enough for anyone to test their changes in isolation.

The questions worth asking, therefore, are more specific.

• What is your deployment contention? If two teams can’t ship without scheduling a meeting first, the architecture is failing, regardless of whether it’s a monolith or 200 services.
• What is the cost of a developer minute? Consider the engineering throughput of every developer sitting idle while a massive web of integration tests finishes its run across shared environments.
• What problem is your team trying to solve? Are you splitting services because the system can’t scale, or because the organization can’t coordinate? If it’s the latter, you’re solving a cultural problem with expensive technical overhead.
• Could a modular monolith get you most of the way there? Logical separation inside a single codebase eliminates the network overhead and latency penalties of distributed services, while still letting teams own their own domains cleanly. Gartner projects that 40% of enterprise applications will be integrated with task-specific AI agents by the end of 2026, up from less than 5% today. That’s a lot of new integration surface arriving fast. 

Everlane, for example, ran on a fully homegrown platform and integrated Shop Pay directly into its existing setup, capturing 15% of US transactions through Shop Pay within the first 30 days. 

That’s the blended model in action, and according to an IDC survey of 1,000 global enterprise retailers, it’s the most common architecture in production. Forty-five percent run a composable front end on a full-stack back end, compared to 27% fully headless and modular, and 29% on an all-in-one platform. 

Of those enterprises, 91% said low total cost of ownership (TCO) is important when evaluating any architectural change.

Why “more flexibility” is not enough reason to migrate

Microservices adoption has grown exponentially over the past decade and is on track to become an $8.33 billion market by 2032.

But this produces implementations that web developer Juan Quintana Gomez describes in Perficient as unnecessarily complex implementations, like “using a bazooka to kill an ant.”

The result is a distributed monolith, with all the operational complexity of microservices but none of the architectural benefits.

The specific failure mode is over-design: decomposition without a clear map of domain boundaries produces highly granular, entity-oriented services that result in circular dependencies, duplicated business logic, excessive events without meaningful semantics, and distributed flows that are difficult to debug.

Flexibility as a goal also dissolves on contact with reality. Even experienced architects like Martin Fowler working in familiar domains have great difficulty getting service boundaries right at the beginning, and refactoring functionality between services is significantly harder than doing the same inside a monolith.

The migration earns its cost only when you can name the specific constraint it removes.

What does monolithic architecture still get right?

Monolithic architecture describes a model of software design that involves building an application as a single, unified unit. The monolithic approach is traditional—dating back to mainframe-focused software development in the 1950s and 1960s—and many developers and companies have encountered monolithic applications and their limitations.

Advantages of monolithic architecture

Monoliths have a bad reputation, but there are still advantages to a monolithic design. 

In 2023, Amazon Prime Video’s engineering team published a case study on their video quality monitoring service, a tool that checks every stream for defects at scale. Their distributed microservices implementation hit a hard scaling limit at around 5% of expected load. After consolidating the components into a single process, infrastructure costs dropped by more than 90% and scaling capacity increased. 

Their conclusion was, whether to use microservices over a monolith has to be decided case by case.

Beyond performance and cost, there are three operational advantages that only become visible once they’re gone:

• Reduced overhead. Especially compared to a microservices approach, a monolithic architecture can require relatively little overhead. Monoliths can often be simpler than other approaches because the consolidated nature of a unified application tends to mean less management, coordination, and orchestration.
• Maintenance. Because all components of a monolithic application are housed in a single, unified codebase, debugging and testing tend to be more streamlined. When there are issues, developers often have an easier time tracing flaws, discovering bugs, and finding dependencies.
• Simplicity. Monoliths can offer a surprising level of simplicity for businesses in their infancy that are looking for simpler code management and deployment methods. However, this benefit quickly evaporates when your business requirements evolve and become more sophisticated.

Disadvantages of monolithic architecture

The disadvantages of monoliths are what have driven much of the interest in microservices and other architecture designs. 

In August 2008, Netflix experienced a major database corruption that took their entire service offline for three days. The monolith’s architecture—a single deployable unit running on a centralized Oracle database—created a single point of failure, and one corrupted database brought everything down simultaneously. This triggered Netflix’s seven-year migration to microservices on AWS.

The three structural disadvantages that drove that decision apply broadly to most enterprises:

• Inefficient development workflows. Monolithic applications, because they’re designed as a single unit, tend to create tightly coupled relationships between different components. Academic research on migration patterns consistently identifies scalability and maintenance as the primary drivers of migration, with teams citing the inability to change one component without cascading risk across the whole system.
• Expensive scalability. Monolithic applications can still benefit from cloud-based resource allocation, but scalability tends to be expensive, because resources have to flow through the entire application. Even if increased strain resulting from an uptick in users is focused on a particular part of the application, developers can’t allocate resources to that component alone.
• Shared technologies. In a monolithic design, applications share the same languages and primitives and tend to reuse much of the same tooling. The requirement to share these technologies sometimes results in inefficiencies as teams rely on technologies they wouldn’t have otherwise chosen. For example, if the main application is built in a stable, well-supported framework, the application’s fundamental features might benefit, while the ability to rapidly develop new features and experiences might suffer.

What does microservices architecture get right?

Microservices architecture describes a model of software architecture design that decomposes the components of an application into separate, isolated services that communicate with each other via API.

The three defining characteristics of microservices are:

• Individual technology stacks. Each service has its own codebase that can be managed by smaller development teams.
• Reliance on communication protocols. Each service communicates via an API layer, which is especially useful as the number of applications or services you’re using grows.
• Organized by business capability. The separation of services is decided by business capability, so each service is responsible for a relatively small portion or function of the overall application.

In the years since 2015, when companies were winning awards for microservices work, more organizations have adopted the design and, in many cases, found more disadvantages than anticipated. In some cases, companies have migrated back to a monolithic design or to a different architecture altogether.

Advantages of microservices architecture

The advantages of microservices architecture design come primarily from how it separates and isolates services. This emphasis on separation creates a loose coupling between different parts of an application at a level even a well-designed monolith likely can’t achieve.

• Flexibility and agility. By separating an application into services, companies make it easier for development teams to update each service. For example, Amazon deploys code every 11 to 12 seconds on average; a pace made possible by microservices architecture, where thousands of teams ship changes to their own services without waiting for anyone else. 
• Autonomy. Because each service is separate and uses a distinct codebase, development teams can be more autonomous and worry less about coordinating work across teams. At Uber, this was the primary driver as the engineering organization grew from tens to hundreds of engineers. The monolithic architecture tied the fate of teams together and made it difficult for them to operate independently. 
• Scalability. In a microservices-based design, developers can allocate resources only to the services that need them. Coursera, running on Amazon ECS, moved from deploying software changes in hours to deploying them in minutes once it shifted to a microservices model. Microservices, under sustained high load, demonstrate 36% faster response times and 71% fewer errors compared to monolithic equivalents.

Disadvantages of microservices architecture

The complexity that makes microservices powerful at scale is the same complexity that makes them expensive to operate before you’re ready for it.

• Increased maintenance costs. Every service needs its own CI/CD pipeline, its own monitoring, and its own on-call rotation. Dynatrace’s 2024 State of Observability report found that organizations run an average of 10 different monitoring and observability tools to manage applications, infrastructure, and user experience across their environments.
• Organizational complexity and overhead. The same Dynatrace research found that 88% of technology leaders reported an increase in the complexity of their tech stack over the prior 12 months, with 51% expecting that trend to continue. Further, Grafana Labs found 62 different observability technologies in use across respondents, with 70% of teams relying on four or more of them; a fragmentation that compounds the coordination problem rather than solving it. 
• Coordination complexity. Ideally, microservices require little coordination, because each service is exposed via API. But in reality, separate services have to reliably work in conjunction to form an application, and for many companies, it becomes a struggle to maintain cross-service dependencies and manage API versioning issues. The application, despite its decentralization, can end up being brittle.

Read more: Microservices: Advantages and Disadvantages (And Whether They’re Right For Your Business)

Why microservices are justified by team and deployment complexity

Martin Fowler’s read on Conway’s Law observes that a dozen or so people with deep, informal communication will naturally produce a monolith. And it’s only when the humans need organizing—into separate teams, around distinct business capabilities—that architecture decisions should follow. 

If the organization hasn’t actually restructured around service ownership, decomposing the codebase just moves the coordination problem from function calls to network calls.

Almost every successful microservices story started with a monolith that got too big and was broken up. Almost every system built as microservices from scratch ended in serious trouble.

Twilio Segment was a small team that built out 140 separate destination services, each with its own queue. Instead of enabling them to move faster, the team found themselves mired in exploding complexity. 

The postmortem from the Hacker News discussion cut to it: “This Segment team was 3 people and 140 services. Microservices are best at solving org coordination issues where teams step on each other. This is a case of a team stepping on itself.”

Monolith to microservices: An incremental migration process

A big-bang rewrite, where you freeze the monolith, rebuild everything as services, and cut over on a fixed date, is one of the highest-risk moves in software engineering. One example of this is HeartFlow’s nine-month migration that crashed on day one. 

The teams that get this migration right extract services from the edges inward and keep the monolith running throughout.

1. Start with bounded contexts and domain analysis

Microsoft’s Azure Architecture Center says that domain analysis comes first. You analyze the business domain to understand functional requirements, define bounded contexts—each containing a domain model that represents a specific subdomain—and only then identify microservice candidates from those boundaries.

That means two things:

• Identify bounded contexts. A payment means something different to your billing team than it does to your fraud team. If you build a single service that spans both, you’ve created a distributed monolith from day one.
• Enforce internal boundaries. Lock down the boundaries inside the monolith first, using module visibility rules and explicit interfaces. The discipline must exist before the distribution.

The most direct example of this is Shopify’s own engineering journey. In Shopify’s core monolith, there weren’t boundaries between different functionalities with over 2.8 million lines of Ruby code. For a new developer joining the shipping team, they had to know how orders were created and how payments were processed.

Shopify ruled out microservices as a solution, not because they couldn’t be built—but because the engineering team realized everything they liked about the monolith came from having all the code live in one place—while all the problems they were experiencing came from not having boundaries. 

Boundaries, not distribution, were the fix. They chose a modular monolith instead.

“As an example, we had a legacy tax engine that was no longer adequate for the needs of our merchants … before … it would have been an almost impossible task to swap out the old system for a new one. However, since we had put so much effort into isolating dependencies, we were able to swap out our tax engine for a completely new tax calculation system,” says Kirsten Westeinde, development manager at Shopify.

2. Use the strangler fig pattern instead of a big-bang rewrite

Martin Fowler coined the term in 2004 after observing strangler fig trees in Queensland. 

A vine germinates in the higher branches of a host tree, grows down to the forest floor, and eventually becomes self-sustaining. If the original host dies, it leaves behind a fig that mirrors its shape. He saw this as a precise metaphor for how legacy systems could be replaced—new services gradually wrap around the old system until the original can be decommissioned safely. 

The key constraint is code base access, because to implement the pattern, you must be able to intercept calls and redirect them to new services. 

Twilio Segment’s own engineering team used this logic when they applied the strangler fig pattern to their notification architecture. They built the new notification service alongside the existing one, used feature flag-based routing to move reads and writes separately, and maintained a dual-write pattern during the transition so both systems stayed in sync.

Read more: The Retailer’s Guide to Legacy to Digital Transformation (+ Examples)

3. Plan for proxy routing, anti-corruption layers, and rollback

The strangler fig pattern requires a facade between clients and the system. The facade acts as an intermediary, initially routing most requests to the legacy system. As new services are validated, routing shifts progressively. 

The anti-corruption layer (ACL) is the companion pattern. When features within the monolith need to call features that have been migrated as microservices. The ACL routes calls to the right service, acting as a facade or adapter that converts legacy calls into the newer interface, decoupling existing monolith callers from the migration.

Rollback needs to be designed in from day one. Each extraction should be an atomic improvement to the overall architecture, meaning the system is in a better state after every step, and can be reversed cleanly if a service proves unstable.

4. Handle shared data, data consistency, and database decomposition early

A shared database is considered an anti-pattern in microservices architecture because when services share a database, they lose the core properties that make microservices valuable: scalability, resilience, and independence. 

A schema change for one service can break another. The services are coupled through the database even when their codebases are separate.

Sam Newman’s Monolith to Microservices, the canonical text on this migration pattern, identifies database decomposition as the hardest part of the exercise.

Newman dedicates separate sections to splitting the database first, splitting the code first, and splitting both together, treating each as a distinct approach with different tradeoffs. 

• Database-first can reveal performance issues but may delay the benefits of the new microservice. 
• Code-first provides quicker improvements but risks incomplete separation if not followed by database decomposition.

For Shopify merchants, the shared data problem tends to surface across the stack. KPMG’s retail research found that 74% of retailers say data is their primary challenge, yet only 28% have achieved system-level data integration. That’s the distributed data anti-pattern in a commerce context; services that are technically separate but coupled through inconsistent, siloed data.

Shopify’s unified data model addresses this at the core. A cart is a cart whether created online or in-store via POS. Merchants running unified commerce on Shopify POS see 22% lower total cost of ownership compared to competitors, with the savings starting from eliminated middleware. 

Why do monolithic-to-microservices migrations fail?

Microservices tax complexity, which means if you haven’t automated your operational floor, the move to microservices will likely stall or fail within the first 12 to 18 months.

Here is why those migrations collapse.

Premature decomposition and unclear service boundaries

A distributed system is more difficult to fix because it requires teams to coordinate API changes, data migrations, and deployment schedules across teams without a common release cadence.

When teams decompose before understanding the domain, boundaries have to be redrawn repeatedly, each drawing carrying the full cost of a distributed system refactor.

There’s a simple sign that decomposition was premature: services that can’t be deployed without coordinating with other teams. The baseline test is independent deployability.

Weak observability, testing, and ownership

The Logz.io 2024 Observability Pulse survey found that 48% of organisations cite lack of team knowledge as the single biggest obstacle to cloud-native observability. And only one in 10 organizations reports having achieved full observability across their stack.

Services that can’t be tested in isolation can’t be owned in isolation either. When a test requires the full system to run, teams share the failure surface as well as the infrastructure.

Networked monoliths, shared databases, and cross-team dependency sprawl

Uber’s architecture became so difficult to manage that engineers internally referred to it as the Death Star: a web of tangled dependencies where changes in one service triggered cascading effects across dozens of others.

At that scale, the dependency graph becomes so dense that no single human can understand the impact of a single change.

If Team A optimizes a query by adding an index, they might accidentally slow down Team B’s write-heavy service. Here, you can’t perform a database migration without a synchronized deployment of every service that touches that table. 

This is the definition of a failed microservices strategy; if you have to coordinate deployments, you don’t have microservices.

When to rethink migration to microservices

If your current system is failing, determine if the failure is because of scale or neglect.

Signs the monolith should be improved before it’s split

Before you blame the monolith for your lack of velocity, look for these internal red flags. If these exist, a microservices migration will likely fail:

• Slow deployments because of testing gates and approval chains. The problem is the process, not the architecture. Microservices will multiply the number of deployment pipelines without fixing the slowness in any of them.
• The codebase has no internal boundaries. A codebase where every module reaches into every other module’s internals will produce the same coupling pattern across a network.
• The team doesn’t own on-call. Microservices require close collaboration between developers and operations to make sure provisioning and deployment happen rapidly, and to react quickly when monitoring surfaces a problem.
• The domain isn’t mapped. Extracting services before the domain is understood produces wrong boundaries, and wrong boundaries in a distributed system are expensive to fix.

For Shopify merchants, the equivalent warning sign is a fragmented homegrown platform that consumes engineering capacity that could be put to better use towards growth.

Carrier, the global HVAC and building solutions provider, was spending up to $2 million per ecommerce website and waiting up to 12 months to launch each one on their traditional monolith platform.

They were becoming a de facto tech company when their actual business was climate solutions. After migrating to Shopify, Carrier launched new ecommerce experiences in 30 days at around $100,000 per site, roughly 10% of the previous cost. They use Shopify’s modular commerce components as the foundation for OneCommerce, a central accelerator covering 80% of their shared enterprise commerce requirements.

“If you want lower TCO, rapid deployment, and a platform that is growing at a rate faster than you can develop it yourself, then I would encourage you to look at Shopify,” says Steve Duran, Carrier’s associate director of global commerce.

When is a modular monolith enough?

For Shopify merchants, the platform embodies this principle by design. A McKinsey report found that 35% of commerce technology projects failed to meet objectives, mainly due to overly complex systems and tools that couldn’t integrate.

Those who avoid that failure mode choose the right level of modularity for their operational maturity.

The specific features that make modular commerce work without distributing complexity:

Commerce Components by Shopify lets enterprise merchants adopt Shopify’s infrastructure selectively—checkout, Shop Pay, product catalog, B2B pricing, fraud detection—as discrete components that integrate into an existing tech stack. Rather than building those modules themselves, merchants connect Shopify’s pre-built, battle-tested modules with their preferred back-office services using flexible APIs.

Mattel runs its entire brand portfolio this way. Everlane uses Shop Pay on a composable front end alongside its existing back end without requiring a full platform migration.

Shopify Functions extends or replaces core back-end logic, discounts, payment methods, shipping rules, and cart validation without requiring a separate microservice. You run custom business logic at the infrastructure layer, not in a separate service you have to monitor.

Hydrogen, Shopify’s React-based headless framework with edge-deployed hosting via Oxygen, decouples the storefront without forcing merchants to own and operate the infrastructure underneath it. You get front-end freedom and can deploy presentation layers independently without having to build a distributed system to handle it.

Nour Hammour, the premium outerwear brand, rebuilt its storefront on Hydrogen and Oxygen and reported a 63% year-over-year increase in conversion rate and a 128% year-over-year increase in sales.

“What we love about Hydrogen is that it’s purpose-built for Shopify storefront development. We could use pre-built components like cart, pagination, and search, as well as ready-to-use code for products, collections data fetching, or automatic SEO schemas generation. Choosing Hydrogen literally saved us months of custom development,” says Tom Mittlener, senior developer at Nour Hammour.

Your stay vs. go migration decision matrix

How to evaluate the right commerce architecture for your business

The goal is to build a system that most efficiently bridges the gap between customer experience and back-end operations.

The framework below uses three filters—business capability, team maturity, and operational readiness—to get to that answer.

What does your architecture need to do?

Start with what the business needs the system to handle.

• Do different parts of the platform need to scale independently? A checkout that handles 40,000 transactions per minute during peak events has different infrastructure requirements than a product catalog that updates weekly.
• Do you run distinct business models on one platform—B2B and DTC, wholesale and direct retail, multiple brands with different pricing rules? Tony’s Chocolonely unified its DTC, B2B, and reseller operations on a single Shopify platform, achieving a 2.5-times faster site speed and double-digit revenue growth by consolidating them onto one composable platform with a unified data layer.
• Does your business need custom logic that your platform can’t handle natively? Shopify’s composable-by-default architecture is built to remove the friction that comes when complexity slows innovation. Shopify Functions handles that custom logic at the infrastructure layer.

Does the organization match the architecture?

Conway’s Law works in both directions. Small teams naturally produce monoliths. If you push a team that isn’t structured for independent service ownership into a distributed architecture, the architecture degrades to match the team, not the other way around.

• Can each extracted service be owned end-to-end by a dedicated team, including on-call? If two teams still need to coordinate deployments after extraction, the service boundaries are wrong, or the team structure hasn’t caught up.
• Do your engineers have experience designing for network failure, eventual consistency, and distributed tracing? These are distinct skills from application development, and the operational learning curve carries cost.

Shopify takes on that overhead while keeping ongoing costs lower, including hosting, security, updates, and unlimited scale. If you tried to achieve the same thing by integrating and managing microservices yourself, the costs would skyrocket quickly.

“Over three years, we grew 3,800%. We’re now a global omnichannel brand. Shopify Plus has scaled with us every step of the way, so we didn’t have to become a tech company,” says Joanna Griffiths, founder and CEO of Knix.

Is the operational floor in place?

Fowler’s three microservice prerequisites apply regardless of how strong the business case looks: rapid provisioning, basic monitoring, and rapid automated deployment. 

Composable platforms like Shopify make migration safer by helping businesses modernise without interrupting day-to-day operations, but only if the migration itself is phased, observable, and reversible at each step. That’s the strangler fig pattern applied to platform choice.

Adopt Shopify’s composable building blocks incrementally, prove each step in production, and expand the footprint only when the previous layer is stable.

For Shopify merchants, the filter output maps directly to the platform configuration.

• Low-maturity teams with business complexity are best served by Shopify Plus with Shopify Functions for custom logic, composable at the feature level without distributed infrastructure. 
• High-maturity teams that need to scale or have multi-brand complexity should evaluate Commerce Components. This lets you integrate Shopify’s checkout, catalogs, B2B APIs, and payments infrastructure into your existing stack.
• Most B2B companies should go for composable commerce over pure microservices, so they can have modular flexibility and easier integrations without managing dozens of independent services.

You can’t go wrong building on a platform that already powers more than 12% of all US ecommerce.