What problem does it address?
The platform cannot change safely or quickly enough. Release coupling, unclear service boundaries, and manual reconciliation make every change feel riskier than the last.
Constraints to respect
Live transaction processing cannot stop for a rewrite
Payment and security controls must remain in place throughout
The existing team must be able to operate the result
Each release needs a rollback path
What options should be on the table?
Big-bang rewrite
Strangler fig with incremental service extraction
Buy an off-the-shelf payment platform
Refactor the monolith in place
The recommended decision
Use a strangler fig approach. Start with the highest-risk boundary, keep the existing system authoritative until the new path is proven, and expand traffic only when the evidence supports it.
Outcomes to define and measure
A migration plan with reversible steps, a measured baseline, and a path to reduce release coupling without stopping payment processing. We do not claim client-specific results without written permission.
Related reading
The thinking behind this pattern
- Legacy Software Modernization: Rewrite vs Refactor Should you rewrite your legacy software from scratch or refactor incrementally? A practical comparison with an illustrative migration path and decision criteria. Read
- Microservices vs Monolith: Architecture Decision Guide Microservices vs monolith is a consequential architecture decision. Learn when to choose each, and why a modular monolith often wins first. Read
Want to apply this pattern?
Tell us about your systems and constraints. We will map the pattern to your situation and identify what needs to be verified first.