Rewriting a production SaaS from scratch is a high-risk bet. The strangler fig pattern lets you migrate piece by piece, replacing legacy components while the old system keeps serving users — dramatically reducing the chance of a big-bang failure.
Map domains before writing code
Start with event storming or domain-driven design workshops to identify bounded contexts. Each context becomes a candidate service or module. Prioritise contexts that change frequently or have clear ownership — these deliver the most value when extracted early.
Document the current data flow and integration points. Legacy systems often have hidden coupling through shared databases or undocumented API contracts. Surface these before extraction to avoid nasty surprises mid-migration.
Feature flags as your migration harness
Route traffic to old or new implementations using feature flags. This lets you roll out to a percentage of users, roll back instantly if something breaks, and run A/B comparisons of old vs new behavior before committing to the new path.
Flags also decouple deployment from release. You can ship new code to production while keeping it dark, build confidence with internal dogfooding, then graduate to full rollout without a separate release ceremony.
Zero-downtime data migrations
Migrate data using the expand-contract pattern: first expand the schema to support both old and new shapes, backfill historical data in batches, switch writes to the new shape, validate read paths, then contract by dropping the old columns.
Use dual-write periods where both old and new schemas are written simultaneously so you can roll back reads to the old path if anomalies appear. Monitor row counts, checksums, and business metrics continuously during migration windows.
Key takeaways
- Strangler fig pattern replaces legacy components incrementally without big-bang rewrites
- Feature flags decouple deployment from release and enable instant rollback
- Expand-contract schema migrations enable zero-downtime database changes