A founder came to us convinced their aging monolith needed a full rewrite into microservices before they could scale further. After an audit, we talked them out of the rewrite and into an incremental migration instead — a decision that saved roughly a year of engineering time and avoided the "big bang rewrite" failure mode that kills a large share of these projects.
Why Full Rewrites Usually Fail
A full rewrite requires the team to build a new system while still maintaining and shipping features on the old one — effectively doubling engineering load for months or years. Feature parity gaps inevitably surface late, and by the time the rewrite ships, the business requirements have often moved. We've seen this pattern repeatedly across rescue engagements: the rewrite becomes the project that never quite finishes.
The Strangler Fig Pattern
Instead of a rewrite, we use the strangler fig pattern — named for the vine that gradually envelops and replaces a host tree. New functionality is built as microservices from day one, while an API gateway or routing layer incrementally redirects traffic from monolith endpoints to their new microservice replacements, one at a time.
# API Gateway routing configuration
location /api/v2/orders {
proxy_pass http://orders-microservice.internal;
}
location /api/v2/inventory {
proxy_pass http://inventory-microservice.internal;
}
# Everything not yet migrated stays on the monolith
location /api/v2/ {
proxy_pass http://legacy-monolith.internal;
}
The monolith keeps running and serving traffic for everything not yet migrated. Nothing breaks mid-migration because there's no single cutover event — each service extraction is independently deployable and reversible.
Choosing What to Extract First
We prioritize extraction candidates by two factors: change frequency (parts of the system the team modifies often benefit most from independent deployability) and coupling risk (parts of the monolith causing the most cross-team friction or deployment bottlenecks). We deliberately avoid extracting the most complex, tightly coupled component first — that's the highest-risk, lowest-confidence starting point.
Data: The Hardest Part of the Migration
Splitting application code is usually more straightforward than splitting the underlying data. A newly extracted "inventory" microservice needing data still owned by the monolith's database creates a distributed transaction problem. We handle this with:
- Database-per-service as the long-term target, with each extracted service owning its own data store
- Change data capture (CDC) during the transition, replicating relevant data changes from the monolith's database to the new service's database in near-real-time, avoiding a hard cutover on data ownership
- Eventual consistency acceptance — not every operation needs strict transactional consistency across services; we work with the client to identify where eventual consistency is acceptable versus where it genuinely isn't
Realistic Timelines
A full monolith-to-microservices migration for a mid-size application typically spans 6-18 months when done incrementally — much longer than a rewrite's estimated timeline, but with continuous feature delivery throughout, rather than a multi-month or multi-year freeze on new functionality while the rewrite catches up.
When a Monolith Doesn't Need to Become Microservices
Not every system benefits from this migration. If a monolith is well-organized internally (clear module boundaries, manageable deployment size, a small team that doesn't need independent service deployability), the operational overhead of microservices — service discovery, distributed tracing, network latency between services — can be a net negative. We say this directly when an audit doesn't support the migration, even though it's the more familiar consulting narrative to push.
Results
For the founder mentioned above, the incremental strangler fig approach let the team ship new features throughout the 10-month migration window, with zero full-system outages during the transition — a contrast to their original rewrite estimate of 12+ months with a feature freeze and a single high-risk cutover at the end.
Weighing a monolith migration or rebuild decision? Book a project diagnostic — 907-841-8407 or contact@rutagon.com.
Frequently Asked Questions
Is a full rewrite ever the right choice instead of incremental migration?
Occasionally, when the existing codebase has fundamental architectural or technology constraints that make incremental extraction impractical. But this is far less common than founders assume — a technical audit should confirm it before committing to a rewrite.
What is the strangler fig pattern?
It's an incremental migration approach where new functionality is built as independent services while a routing layer gradually redirects traffic from the old monolith to new services, one endpoint at a time, avoiding a single risky cutover event.
How do you handle shared data during a microservices migration?
Common approaches include change data capture (CDC) to replicate data during the transition period, moving toward a database-per-service model as the long-term target, and identifying which operations can tolerate eventual consistency versus requiring strict transactional guarantees.
How long does a monolith-to-microservices migration take?
For a mid-size application, incremental migrations typically span 6-18 months, depending on system complexity and how much of the team's capacity is dedicated to migration work alongside ongoing feature development.
Does every legacy monolith need to become microservices?
No. Well-organized monoliths with manageable deployment size and a small team can be a better fit than microservices, which add real operational complexity. A technical audit should determine whether the migration is actually justified before starting.