In April 2018, TSB migrated its customers onto a new IT platform. The data itself migrated successfully, but the platform immediately experienced technical failures, a significant proportion of TSB's 5.2 million customers were affected, and it took until December 2018 to return to business as usual. TSB paid £32.7m in redress, and regulators fined it £48.65m, finding that it failed to adequately organise and control the programme and to manage the risks of its critical third-party supplier.
The lesson isn't "never modernize". Keeping an aging core forever also has a price: slower product launches, rising maintenance costs, integration limits and growing security and compliance exposure. The lesson is that modernization is an architecture and risk problem before it is a technology problem. The real question is how to change the engine while the plane is flying.
This guide covers a layered target architecture, five modernization patterns and when to use each, and how to keep data consistent during migration. It also covers regulation as a design input, a safe rollout playbook and a phased roadmap.
In short
- Start with your constraints (uptime, regulation, data sensitivity, how well you understand the old system), not with a technology.
- Put an API and routing layer in front of the legacy core first. It gives you control over where traffic goes.
- Migrate one capability at a time, reads before writes, and channels before the ledger.
- Treat data synchronization as the central engineering problem.
- Design for auditability, resilience and reversibility from day one.
What "legacy" means in fintech
A legacy system is not just old code. It is a system that still does important work but resists change. Common signs include:
- COBOL, monolithic architectures or unsupported databases
- Difficulty integrating with APIs, cloud platforms or analytics tools
- High maintenance cost and a shrinking pool of people who understand the system
- Batch-oriented processing that can't support real-time payments, reconciliation or reporting
- Security and compliance gaps that patches can't close
Many of these systems are also proven and mission-critical, which is why wholesale replacement is so risky and why most successful programs are hybrid.
Five principles to settle before choosing a pattern
1. Reversibility. A big-bang cutover is a light switch: off, then on, with a dangerous moment in between. Aim for a dial instead. You should be able to move traffic from 0% to 10% to 100% and back to 0% within minutes, without data loss.
2. Small, frequent changes. Smaller releases are easier to test, debug and roll back. If your pipeline can't ship a fix quickly, fix the pipeline first.
3. Non-functional requirements first. Decide early whether you need strong or eventual consistency, what availability target applies, and what must be audit-traceable. These answers shape the architecture more than any framework choice does.
4. Auditability by design. If a customer disputes a decision, you should be able to reconstruct which events and rules produced it. In finance this is often a legal obligation.
5. Keep domain knowledge in the room. Legacy code often encodes business rules nobody documented. Every component you rewrite needs someone who can explain why the old code behaves as it does.
The target architecture
You rarely modernize by swapping one large system for another. Instead, you build layers around the legacy core and move capabilities out of it over time. From top to bottom:
| --- | --- |
|---|---|
| Channels | Mobile apps, web, partner APIs and back-office tools. |
| API gateway and routing facade | The single entry point. It handles authentication, throttling and versioning, and it decides whether each request goes to the legacy core or to a new service. This is your steering wheel for the migration. |
| Domain services | New services built around business capabilities (payments, onboarding, notifications), not technical layers. |
| Anti-corruption layer (ACL) | A translation layer, a concept from domain-driven design. It maps legacy formats (SOAP/XML, batch files, proprietary schemas) to clean domain models so legacy quirks don't leak into new code. |
| Legacy core | Remains the system of record for each capability until that capability is migrated and verified. |
| Event backbone | A streaming platform carrying domain events and change data capture feeds. It supports audit trails, reconciliation and analytics without hammering the core. |
| Cross-cutting concerns | Observability, security, CI/CD and compliance evidence, applied to every layer. |
Five modernization patterns and when to use them
| --- | --- | --- |
|---|---|---|
| API wrapping (facade) | The core is stable but hard to reach from apps and partners | Doesn't reduce legacy complexity or maintenance cost |
| Strangler fig | The system is large and business-critical, with identifiable seams | Long coexistence, routing complexity, data sync |
| Sidecar / parallel core | You're launching new products without touching the existing book | Two cores to run, and migration debt deferred |
| Replatform / refactor | Ancillary or non-core systems need better hosting and performance | Improves how it runs, not how it's designed |
| Full rebuild | The core is unmaintainable, its logic opaque, and extension no longer viable | Losing undocumented business logic |
API wrapping
Put a modern interface in front of the legacy core. Apps and partners talk to the new layer, and the core keeps processing as before. It is the fastest way to unblock integration, but the underlying maintenance burden stays.
Strangler fig
Named by Martin Fowler after vines that gradually replace their host tree, this pattern routes individual capabilities to new services while the legacy system handles everything else. Over time the old core shrinks until it can be retired. It works best with clear domain boundaries, good observability and a team comfortable with continuous delivery. It is a poor fit for tightly entangled code with no seams or for environments with little test coverage.
Sidecar or parallel core
Run a new cloud-native platform beside the legacy system and use it for new product lines while existing customers stay put. This suits embedded finance and new-market launches. The cost is running two cores, so decide up front what eventually happens to the old one.
Replatform and refactor
Move workloads to the cloud or restructure code without changing behavior. This is useful for reporting, CRM integrations and batch jobs. It cuts infrastructure cost but doesn't fix a fundamentally constrained design.
Full rebuild
Sometimes it's justified, but the code is the easy half. The real risk is losing knowledge of how the old system worked. Before writing anything, reverse-engineer the existing logic, document calculations and data flows, and build characterization tests that capture current behavior. Then rebuild in phases, validating the calculation core first.
An illustrative scenario
Imagine a payments firm whose batch-based core can't show customers real-time payment status. Rewriting the core would take years and put settlement at risk. Instead, the firm places a routing facade in front of the core, streams payment events through CDC into an event backbone, and builds a new status service on top of that stream. The core keeps processing payments untouched, and customers see live status within months. Later phases can move more capabilities out of the core, one at a time. This is a hypothetical example, but it shows the sequence: control first, read paths next, money-moving flows last.
The hard part: data and consistency
Most modernization failures happen at the seams, and the seams are mostly about data. During coexistence, two systems may each hold part of the truth.
- One system of record per data entity at any moment. Shift ownership explicitly, not gradually and implicitly.
- Avoid naive dual writes. Writing to two systems from application code fails in partial ways: one write succeeds and the other doesn't, leaving mismatched balances. Prefer change data capture (CDC) or the transactional outbox pattern to publish changes reliably.
- Reconcile continuously. Automated comparison jobs should flag discrepancies between old and new systems throughout coexistence, not only at cutover.
- Run in parallel before you switch. Keep the legacy system authoritative while the new component performs the same calculations in shadow mode. Compare results over a period that includes month-end or quarter-end, because edge cases often surface only then.
- Migrate reads before writes. Read-heavy capabilities such as statements, profile views and notifications are lower risk than money-moving flows, and they let you prove the pattern first.
Regulation and resilience as design inputs
Compliance shouldn't be a gate at the end of the project. Treat it as an architecture requirement.
- Inventory what applies. Depending on your market, this may include PSD2, GDPR, AML rules, PCI DSS, your local regulator's requirements and the EU's Digital Operational Resilience Act (DORA), which covers ICT risk management, incident reporting, resilience testing and third-party risk. Confirm the specifics with your compliance team.
- Design for evidence. Event-based audit trails, immutable logs and traceable decision paths make audits and customer disputes far easier.
- Manage third-party risk. TSB's regulators specifically criticized how outsourcing risk was handled. Define responsibilities, escalation paths and exit plans for every critical supplier.
- Involve compliance early. Modernization changes business processes even when features stay the same. Bring engineering, security, operations, legal and compliance into the change plan.
A safe rollout playbook
1. Fast, reliable pipelines. Build, test and release must be quick, because an incident fix is only as fast as your deployment. 2. Observability before migration. Logs, metrics, traces and alerts must exist first so you can see a regression when it happens. 3. Feature flags. Turn functionality on or off instantly without redeploying. 4. Gradual ramp. Internal users first, then 1%, 10%, 50% and 100% of traffic, with explicit success criteria at each step. 5. Shadow traffic. Replay real production requests against the new service to test logic and performance without affecting customers. 6. Instant, rehearsed rollback. If reverting takes hours, your dial is really a switch. 7. Cross-functional review. No single engineer can spot every risk, so review deployment plans with QA, security, operations, business and compliance.
A realistic roadmap
Timelines vary widely by institution, so treat this as a sequence rather than a schedule.
- Phase 0, discovery. Map dependencies, data flows and integrations. Document non-functional requirements and regulatory obligations. Capture baseline metrics and build characterization tests.
- Phase 1, foundations. Set up CI/CD, observability, the API gateway and routing facade, and the anti-corruption layer.
- Phase 2, first capability. Choose a low-risk, high-visibility, read-heavy capability. Run it in shadow mode, then ramp traffic gradually.
- Phase 3, core flows. Move payments and other money-moving capabilities, with reconciliation running throughout.
- Phase 4, decommission. Retire legacy components deliberately, with data archiving and retention planned up front. Many programs stall here and end up running two systems indefinitely.
Measure what matters. Track delivery metrics (deployment frequency, lead time, change failure rate and recovery time). These are often called "DORA metrics" in DevOps research, and they are unrelated to the EU's DORA regulation. Add business and risk metrics: incident rate, reconciliation break rate, time to launch a new product and cost to serve.
How to choose your pattern
Ask these questions in order:
1. Does the core still process transactions reliably? If yes, start with API wrapping and strangler fig rather than replacement. 2. Are there clear domain seams? If yes, strangler fig is viable. If not, invest in decomposition or reverse-engineering first. 3. Is the goal a new product rather than fixing the old one? Consider a sidecar core. 4. Is the core the ceiling, meaning unmaintainable and opaque? Plan a phased rebuild, starting with logic discovery. 5. Can you roll back within minutes at every step? If not, don't proceed to that step yet.
Common mistakes
- Treating modernization as an IT project rather than a business and risk program
- Choosing big-bang because phased migration feels slower
- Leaving non-functional requirements implicit
- Rewriting without the people who understand the old logic
- Underestimating the cost and duration of coexistence
- Having no decommissioning plan
- Leaving third-party and outsourcing risk unmanaged
Conclusion
Successful fintech modernization looks less like a launch event and more like steady engineering discipline. Put control in front of the legacy core, move capabilities in small reversible steps, keep data consistent through coexistence, and treat regulation and resilience as design inputs. If you're planning a program, start with a discovery phase that maps your dependencies, non-functional requirements and regulatory obligations before you commit to a pattern.
📌 Next Steps & Related Advisory Services
Looking to execute the strategies outlined in this guide? Connect with Peshal Bhattarai for hands-on advisory and managed execution:
- 🚀 Enterprise change management: Explore Digital Transformation Consulting
- 🚀 Fractional CTO advisory: Explore Technology Leadership Services