Every few months, a CTO somewhere reads an article about Netflix or Amazon and decides it’s time to break apart the monolith. Six months later, the team is exhausted, the delivery is stalled and the microservices architecture is somehow harder to maintain than what they started with.
This isn’t a story about microservices being bad, more about the wrong question being asked too early. The question most teams ask: How do we migrate from a monolith to microservices? The question that actually matters: Should we?
This guide covers the signals that make migration worth doing, the signals that say wait, and what an incremental migration actually looks like in production including a case study from a live healthcare application serving 1.8 million users.
What a monolith is and why starting with one is fine
A monolith deploys as a single unit: all business logic in one codebase, one database, one deployment pipeline. Early on, that simplicity has real value one place to look when something breaks, one deployment to manage, no distributed systems complexity to reason about.
According to Martin Fowler’s widely cited „Monolith First” principle, most successful microservices systems started as monoliths. The architecture becomes a problem only when the application outgrows it. That happens in specific, identifiable ways: scaling one component requires scaling the entire system, teams working on a shared codebase start blocking each other’s releases, deployments get riskier as surface area grows. These are the symptoms worth migrating for. Age of the codebase, team preference, and what competitors are doing are not.
When to refactor a monolith to microservices: 4 clear signals
1. Scaling bottlenecks are generating measurable infrastructure waste. One component needs 10x more resources than the rest of the application. In a monolith, scaling that component means scaling everything. According to a 2024 CNCF survey, 72% of organizations that successfully migrated to microservices cited independent scaling as the primary driver. Microservices let you scale individual services based on actual load the infrastructure savings compound over time.
2. Team coordination overhead is visibly slowing delivery. Multiple teams, one codebase. Every release requires synchronization across teams. When team boundaries and codebase boundaries stop matching, something has to give. Conway’s Law states that organizations design systems that mirror their communication structure if your team structure has changed but your architecture hasn’t, that gap will slow you down until it’s addressed.
3. Deployment risk has become a brake on release cadence. A small feature change requires a full regression test of the entire application. Teams delay releases, batch changes, and accumulate risk instead of shipping. Independent deployability, one service ships without touching the others solves this directly. If your team is doing fewer than one production deployment per week because of deployment risk, that’s a concrete signal.
4. A specific component needs a different technology stack. A data-intensive module that would perform better with a different database. A real-time feature that needs different infrastructure. A monolith forces one stack on every component, regardless of fit. This is where systems migration services become relevant moving specific components to environments that match their actual requirements.
When NOT to refactor a monolith to microservices
The team is small. Microservices introduce operational overhead: service discovery, distributed tracing, inter-service communication, multiple deployment pipelines. That a team of five to ten people will spend more time managing than building product.
Domain boundaries are still shifting. Wrong boundaries inside a monolith are cheap to fix. Wrong boundaries across independently deployed services require coordinated migrations. If the product is still evolving rapidly, wait until the domain model stabilizes.
There’s no concrete problem defined. „We should use microservices” is an architectural preference. „We’re losing 30% of infrastructure budget to scaling inefficiency” is a business problem. According to a 2023 InfoQ survey, 63% of teams that abandoned microservices migrations cited unclear business justification as the root cause.
You can’t write one sentence describing what will be better. If that sentence doesn’t come easily, the decision isn’t ready.
How to refactor a monolith to microservices: the incremental approach
Full rewrites fail. The history of software is full of „big bang” migrations that burned through budget, exhausted teams, and ended abandoned or descoped.
The pattern that works is the Strangler Fig, coined by Martin Fowler: extract services incrementally around the edges of the monolith while it continues running. The monolith shrinks as services take over its responsibilities. The system stays live throughout. Rollback is an option at every stage.
Our monolith refactoring service is built around this incremental pattern: no big bang rewrites, no maintenance windows for systems that don’t need them.
Step 1: Map domain boundaries before writing any new code. Understand which parts of the monolith have stable, clear responsibilities. These are extraction candidates. Modules with many dependencies on the rest of the system are not starting points.
Step 2: Extract the lowest-dependency service first. The goal of the first extraction is proving the pattern and building team confidence not solving the hardest problem. Success here makes every subsequent extraction faster.
Step 3: Enforce database ownership from day one. Each service must own its data. A „microservice” that shares a database with the monolith is a distributed monolith harder to reason about than what you started with, without most of the benefits.
Step 4: Build observability infrastructure before it’s needed. Distributed systems fail in ways monoliths don’t. Logging and tracing across service boundaries must exist before multiple services reach production not after the first incident.
Real-world monolith refactoring: the mySugr case study
In 2018, mySugr a diabetes management application used by 1.8 million people globally was acquired by Roche. The merger created an immediate technical constraint: mySugr ran on MySQL, Roche standardized on PostgreSQL. AWS’s Aurora 3 release added a hard deadline the existing setup would be unsupported by 2024.
The FireUp.pro team was brought in to execute a systems migration with significant constraints: a live production healthcare application with no tolerance for downtime, incompatible database systems and a compliance-sensitive data environment.
The approach: first, build an application branch that could run on both MySQL and PostgreSQL simultaneously. Not the final state – insurance. If the production migration hit a critical issue, reverting wouldn’t require a full rollback.
The technical gaps were real. MySQL handles SQL standards permissively: PostgreSQL is strict. DateTime precision differs MySQL accurate to the second, PostgreSQL to microseconds. FLOAT types behave differently. Case sensitivity works differently. Each gap required an individual solution, verified through two months of QA testing before the main switch.
The migration used Amazon Web Services Database Migration in two phases:
- Phase 1 – Initial load: Full copy of existing data
- Phase 2 – Continuous CDC migration: All changes captured from the moment of the initial load forward, eliminating the need for a maintenance window
Karl Spies, Backend Developer at mySugr, described the project: We did something similar to an F1 tire change, but while the car was still on the race track, in motion.
Result: 50% reduction in application maintenance costs. Nine months from proof of concept to production. Zero service interruption for 1.8 million users.
Read the full mySugr case study for the complete technical breakdown.
The real cost of a monolith to microservices migration
Development time and infrastructure are the visible budget lines. Projects consistently exceed estimates because of costs that aren’t visible upfront.
Testing infrastructure is the most common surprise. Distributed systems require integration tests across service boundaries that don’t exist at migration start. Proper test automation built before the first service goes live pays back this investment. Teams that skip this step discover it later, at higher cost.
Operational complexity scales with service count. Every new service adds a deployment pipeline, a monitoring configuration, and a new failure mode. DevOps capacity must scale with the architecture.
Developer onboarding gets harder before it gets easier. New team members need to understand multiple services and their boundaries. Documentation becomes load-bearing, not optional.
Network latency replaces in-process calls. For most use cases this is unproblematic. For high-frequency internal communication or tight latency requirements, it creates performance constraints that need to be designed around from the start.
A realistic migration budget accounts for all four. According to Gartner (2024), organizations that underestimate these hidden costs are 2.3x more likely to pause or abandon migrations mid-execution.
When external expertise makes a difference
Some migrations are within in-house capability, others aren’t. Not because the team lacks skill, but because domain complexity, migration risk, and ongoing product delivery create a workload too large to manage simultaneously.
External expertise adds measurable value in specific situations: regulated data environments where errors carry compliance implications (healthcare, fintech); teams without prior experience decomposing live production systems; underdocumented monoliths where domain boundaries aren’t clear internally; timelines that current team capacity can’t support without delaying core product work.
Our system refactoring services cover the full scope initial architecture assessment, domain mapping, incremental extraction, and production handoff. The pattern recognition from previous migrations shortens planning time and reduces the cost of unexpected problems.
FireUp.pro has delivered monolith refactoring and systems migration projects including healthcare applications with millions of active users. If you’re evaluating whether a migration makes sense for your system, talk to our team we’ll give you an honest assessment, not a sales pitch. See our monolith refactoring service and the mySugr case study for context.
