How We Migrated a $2B Fintech Payment System With Zero Downtime

When a $2B Fintech's Payment System Became Their Biggest Risk

A mid-stage fintech company processing $2B+ annually was watching their monolithic payment system slowly become a liability. Transaction failures were creeping up. Fraud detection was reactive instead of proactive. And every new feature took months to ship because engineers were afraid to touch the codebase.

This is a story many technology leaders recognize — a system that once worked perfectly is now holding the business back. But the solution isn't always a risky, expensive rewrite from scratch.

Why They Couldn't Just Rewrite

The engineering team estimated a full rewrite would take 12-18 months. During that time, they'd need to:

Maintain the existing system (which was already struggling)

Build the new system in parallel

Migrate data and users without downtime

Handle regression testing across thousands of edge cases

The risk was enormous. If the rewrite failed or took longer than expected, the business would be stuck maintaining two systems indefinitely. And in fintech, where uptime is everything, any disruption to payment processing could mean lost customers and regulatory issues.

The Strangler Fig Pattern: A Better Path

Named after the strangler fig tree that grows around a host tree and eventually replaces it, the strangler fig pattern is an incremental modernization approach. Instead of replacing the entire system at once, you extract services one at a time while keeping the old system running.

The key insight: you don't have to choose between "keep the old system" and "build a new one." You can do both simultaneously, gradually shifting traffic from old to new.

Phase 1: Fraud Detection Service (Weeks 1-6)

We started with the highest pain point — fraud detection. The existing system was reactive, catching fraud after transactions completed. We built a real-time fraud detection service using event-driven architecture that could analyze transactions as they happened.

Key decisions:

Deployed alongside the existing system with feature flags

Started with 1% of traffic, gradually increased to 100%

Built comprehensive monitoring to compare old vs new detection rates

Maintained instant rollback capability throughout

Result: Real-time fraud detection caught 40% more fraudulent transactions than the previous batch-processing approach.

Phase 2: Transaction Processing Pipeline (Weeks 7-14)

Next, we extracted the transaction processing logic. This was more complex because it was deeply intertwined with other system components.

Key decisions:

Migrated one transaction type at a time (ACH, wire, card, etc.)

Built validation checkpoints at each stage

Used event sourcing to maintain a complete audit trail

Implemented circuit breakers to handle failures gracefully

Result: Transaction processing time dropped from 800ms to 320ms — a 60% improvement.

Phase 3: API Gateway and Service Mesh (Weeks 15-20)

With individual services extracted, we needed a way to route traffic between old and new systems. We implemented an API gateway that could intelligently route requests based on feature flags and service availability.

Key decisions:

Used Istio service mesh for traffic management

Implemented circuit breakers and retry policies

Built comprehensive observability (distributed tracing, metrics, logs)

Created automated canary deployments for new services

Result: Seamless traffic routing with zero user-facing impact during migration.

Phase 4: Decommission Monolith (Weeks 21-24)

With all services running independently and traffic fully migrated, we decommissioned the monolith. This phase was mostly cleanup — removing dead code, archiving old data, and documenting the new architecture.

Key decisions:

Kept the monolith codebase archived for 6 months (just in case)

Migrated all monitoring and alerting to the new services

Updated runbooks and incident response procedures

Conducted architecture review with the team

The Results

| Metric | Before | After | Improvement | |--------|--------|-------|-------------| | Transaction processing time | 800ms | 320ms | 60% faster | | Fraud detection | Reactive (batch) | Real-time | 40% more fraud caught | | Deployment frequency | Monthly | Daily | 30x increase | | Downtime during migration | — | Zero | — | | Team confidence | Afraid to touch code | Shipping daily | Transformed |

Key Lessons for Your Modernization Project

1. Start With the Highest Pain Point

Don't try to modernize everything at once. Pick the biggest problem, fix it first, and use that success to build momentum. The fraud detection service was the perfect starting point because it had the highest business impact and the clearest success criteria.

2. Feature Flags Are Non-Negotiable

Every service extraction used feature flags to control traffic routing. This allowed us to test new services with a small percentage of traffic, compare results with the old system, and roll back instantly if something went wrong.

3. Validate at Each Step

Every service extraction had clear validation criteria before proceeding to the next phase. We didn't move forward until we were confident the new service was working correctly in production.

4. Keep the Old System Team Involved

The engineers who built and maintained the monolith were our most valuable asset during the migration. They understood the domain, the edge cases, and the business logic better than anyone. Their involvement was critical to the project's success.

5. Plan for the Long Term

The strangler fig pattern isn't a one-time project — it's an ongoing approach to system architecture. Once you've extracted services, you can continue to evolve and improve them independently.

Key Takeaways

The strangler fig pattern enables incremental modernization with zero downtime

Start with the highest pain point to build momentum and prove the approach

Feature flags enable safe, gradual rollout with instant rollback

Every service extraction should have clear validation criteria

The old system team is your most valuable asset during migration

Plan for ongoing evolution, not just a one-time migration

The results (60% faster processing, 40% more fraud caught) justify the investment

FAQ

What is the strangler fig pattern?

The strangler fig pattern is an incremental modernization approach where you gradually replace parts of a legacy system by building new services around the edges and routing traffic away from the old system. Named after the strangler fig tree that grows around a host tree.

How long does a strangler fig migration take?

Typically 3-6 months for the first major service extraction, with ongoing modernization over 12-18 months. The timeline depends on system complexity, team size, and how many services need to be extracted.

What are the risks of incremental modernization?

Risks include maintaining two systems temporarily, ensuring data consistency across old and new services, and managing the complexity of a hybrid architecture. These are significantly lower than the risks of a full rewrite.

When should you choose strangler fig over a full rewrite?

Choose strangler fig when the legacy system has valuable domain logic, when business continuity is critical, when the team is small or new to the codebase, or when a full rewrite would take more than 12 months.

How do you handle data migration during strangler fig migration?

Data migration happens incrementally as each service is extracted. New services use their own data stores, and data is synced between old and new systems during the transition period. Once a service is fully migrated, the old data can be archived.