Monolith to Modular Platform Migration
Strangling a 9-year-old Rails monolith without a single user-visible outage
A Series C SaaS client
A Series C SaaS had a Rails monolith that started in 2016 and never got refactored. Deploys were a 90-minute ritual, every team blocked every other team, and the database was the only source of truth for things like permissions, billing, and audit. They had tried a microservices migration before and failed, ending with three half-extracted services and more complexity than they started with. I led the second attempt as a strangler-fig, with a strict rule: every extraction had to leave the system simpler than we found it, or it didn't ship. Eighteen months later, the monolith was 40% of its original size and the team was deploying 22 times a day with no Friday-night freezes.
Representative architecture study. Patterns, trade-offs and approach reflect engagements I take on; specific metrics and clients are illustrative.
Results
What changed, in numbers
The metrics the engagement is measured by.
<6 min
Deploy Time
from 90 minutes
22/day
Deploy Frequency
from 4/week
0
Outages
across 14 cutovers
-38%
p95 Latency
on extracted services
Challenge
What was broken
The monolith was the bottleneck on every metric that mattered. Deploys took 90 minutes and frequently rolled back. New hires were productive at 8 weeks, not 2. A noisy tenant could brown out everyone else. SOC 2 controls were pinned to the monolith's release cycle, so any compliance work blocked product. The previous extraction attempt had left scar tissue: leadership needed proof this one would actually work before committing the team to another year of migration.
Solution
The shape of the fix
A patient, evidence-driven strangler-fig migration, behind feature flags, with parallel-run validation for every domain. Eight services extracted, two extractions deliberately killed, zero customer-visible outages, and a monolith that finally fits in an engineer's head.
Approach
How I tackled it
The concrete moves that took the project from broken to shipped.
Started with a 4-week diagnostic: bounded contexts, ownership map, and a ranked list of what to extract first based on coupling and pain
Extracted the audit-log service first, the lowest-risk, highest-leverage piece, to rebuild trust in the migration model
Adopted a strict strangler-fig pattern: dual-write, backfill, shadow read, cutover, decommission, with feature flags at every step
Stood up a service-template generator so each new extraction came with CI/CD, IaC, observability, and SLOs preconfigured
Ran weekly migration reviews with engineering leadership and explicitly killed two extractions that weren't paying off
Decommissioned the legacy monolith code path only after 30 days of clean parallel-run, never on faith
Outcomes
What shipped, and what it changed
Measured results from the engagement, told as a story rather than a scoreboard.
Reduced deploy time from 90 minutes to under 6 minutes on the new services and 18 minutes on the slimmed monolith
Increased deploy frequency from 4 per week to 22 per day across the platform
Cut new-engineer time-to-first-PR from 8 weeks to 9 days
Held customer-visible incidents to zero across 14 production cutovers
Reduced p95 API latency by 38% on the extracted services versus the original monolith paths
Stack
Technologies used
Linked entries open the technology page with related studies, playbooks, and notes.
Services
How I helped
The specific services involved in this engagement. Each links to a deeper breakdown.
Lessons
What I would tell the next team
The takeaways I carry into every similar engagement.
Strangler-fig migrations only work if you're willing to kill extractions that aren't paying off, sunk cost is the enemy
Extract the boring, high-leverage piece first (audit logs, in our case), the trust you build pays for the harder ones
Parallel-run validation is the deliverable, never cut over on faith
Related
Other studies you might recognize
Engagements with overlapping problem shapes, industries, or stacks.
Have a similar challenge?
If any of this looks like the project on your desk, the conversation is the cheapest part. You can also browse other saas work or the full service list.