Monolith to Microservices Migration

When to Migrate

Not every monolith needs to become microservices. Consider migrating when you see these signals: deployment frequency is bottlenecked by coordination between teams, scaling requires scaling the entire application when only one component actually needs it, different parts of the system have fundamentally different reliability or performance requirements, or team autonomy is impossible because everyone works in the same codebase.

Do not migrate because microservices are trendy. A well-structured monolith deployed by a team of 15 engineers is often simpler, cheaper, and more reliable than a distributed system.

The Strangler Fig Pattern

Named after the strangler fig tree that grows around a host tree and eventually replaces it:

1. Place a proxy (API gateway or reverse proxy) in front of the monolith. All traffic flows through this proxy.
2. Identify a bounded context to extract. Pick one that is relatively self-contained, has clear data ownership, and changes frequently.
3. Build the new service alongside the monolith. The service owns its own database from day one.
4. Migrate data from the monolith's database to the new service's database. Use dual-write during the transition, then switch reads, then stop writes to the old table.
5. Route traffic at the proxy layer from the monolith to the new service. Use feature flags for gradual rollout.
6. Delete the old code from the monolith once the new service is stable (typically after 2-4 weeks of production traffic).
7. Repeat for the next bounded context.

Data Migration Strategy

Data migration is where most teams get stuck. The key principles:

• Each service owns its data. No shared databases, period. If two services need the same data, one owns it and exposes it through an API or events.
• Use Change Data Capture (CDC) to stream changes from the monolith's database to the new service during the transition period. Tools like Debezium make this practical.
• Accept eventual consistency. In a distributed system, some data will be stale. Design your services to handle this (idempotent operations, compensation transactions).
• Foreign keys across services do not exist. Replace them with service-level references: store the ID and call the owning service when you need the data.

The Shared Library Problem

Monoliths often have "common" libraries that contain business logic, data models, and utility functions. When you extract services, each service pulls in this shared library, creating hidden coupling. The fix: split the shared library into two buckets. Pure utilities (string formatting, date parsing) can stay shared. Anything containing business logic or data models must be duplicated into each service. Accept the duplication. It is the price of independence.

Migration Timeline

Realistic timelines based on industry experience:

These timelines assume you already have CI/CD, containerization, and basic observability in place. If you do not, add 3-6 months for platform readiness.