A migration plan usually starts with a diagram: old system on one side, new one on the other, an arrow connecting them. What that arrow hides is everything the old system depends on and everything that depends on it back, and in fintech that's usually where the budget and the go-live date quietly fall apart.
Nobody starts a migration project wanting to spend the first month mapping out plumbing. The new architecture is the interesting part, the reason the project got approved in the first place, and dependency mapping looks like busywork next to it. Then three weeks before cutover, someone finds out that a "deprecated" reporting job has actually been feeding a regulator's monthly submission all along. Or a partner bank's settlement file turns out to need a database column nobody planned on keeping. We wrote about this same new-product-old-core problem in legacy infrastructure in fintech — this piece looks at how to get ahead of it before the scoping conversation even happens.
This is a composite sketch of how it typically plays out, not any single real project: a mid-sized e-money institution is six weeks into replacing a ledger system that's been running for over a decade, when a finance analyst asks why their month-end interest accrual report has suddenly come back empty. The report turned out to read from a table the new schema never included. Nobody had flagged it in any planning session, because nobody had gone looking for it. The fix itself took an afternoon, yet working out that the fix was needed, and rebuilding the go-live plan around it, cost five weeks. It's a fairly ordinary outcome once dependency mapping gets waved through as a formality instead of being treated as its own phase of the project.
Why Fintech Raises the Stakes
Every legacy migration carries dependency risk, and fintech carries more of it than most, for a simple reason: the system being replaced usually touches money that's already moving. A retailer's inventory system can go down for a weekend with an angry customer or two to show for it. A core banking system or a wallet ledger going down mid-settlement is a different order of problem: unresolved balances, failed KYC checks, and a conversation with a regulator that nobody wants to have.
That difference changes how dependency mapping has to be done. Treating it as a formality before the "real" work starts gets the order backwards; this phase is what tells you whether the real work is even safe to plan yet.
The scale of the problem shows up in the numbers. Only about 30% of banks that have undergone a digital transformation report successfully implementing their strategy, according to McKinsey. LegacyLeap's 2025 read of EY's analysis points to a specific, recurring cause behind that number: programs run into trouble when teams start rebuilding before they've mapped what the old system actually connects to.
The Five Types of Legacy System Dependencies
Hollinford's guide to mapping legacy system dependencies sets out five categories: data, integration, process, user, and infrastructure. None of this is a new idea. A system that has sat in production for years accumulates connections that nobody fully tracks, and Martin Fowler's writing on legacy displacement makes much the same point about finding the seams in a system before you disturb it. The NCSC's guidance on identifying critical assets argues something similar from a security angle: you can't manage the risk of something you haven't mapped. Two of the five categories below, data and process, would have caught the missing interest-accrual table in the ledger example before it caused a delay.
Data dependencies are about shared storage: a legacy core and a reporting tool, or two internal systems, reading from and writing to the same tables. This is where the ledger example lived. Nobody had touched the interest-accrual logic itself; the table it read from simply belonged to a schema nobody had flagged as shared.
Integration dependencies are the connections to other systems: APIs, SFTP file exchanges, webhooks, direct database links. A digital wallet alone might connect to a card processor, an AML screening vendor, a partner bank's settlement API, and an internal fraud engine — payment products rarely stop there. Each connection carries its own timing assumptions, and each one is a place where "the new system will just call the same endpoint" turns out to be false.
Process dependencies are missed most often, since nothing about them shows up in code or on an architecture diagram. A finance team pulls a saved query every month-end. An operations analyst prints a reconciliation report at a fixed time each day. None of that lives in documentation anywhere, and any of it can stop a migration cold if nobody thought to ask about it. A migration can be technically complete and still fail operationally because of a process like this.
User dependencies are about the teams, roles, and operational knowledge that rely on the legacy system, often for completely different reasons. Sales enters orders, finance runs month-end reports, operations checks balances and settlement status, each with its own critical usage windows the migration schedule has to work around.
Infrastructure dependencies sit one level down, in the scaffolding that keeps the system running day to day: server configuration, database engine version, scheduled jobs, certificates, licences. A nightly batch job pinned to a specific job-scheduler version doesn't just carry over into a new environment on its own, and certificates have a habit of staying invisible right up until a TLS handshake fails in staging.
Dependency Types at a Glance
What This Looks Like in a Payments Context
This structure, applied to a wallet or core banking migration, surfaces a specific set of things worth checking before a project gets scoped. Some map directly onto the five categories above. Others are fintech-specific enough to deserve their own line item.
Settlement and clearing connections. Does the current core rely on batch settlement windows, and does anything downstream assume that timing? A move to real-time processing can break reconciliation logic built around a daily file.
KYC and AML integrations. Where does identity verification data flow, and which systems read the output? A 2023 industry survey covered by FinTech Global found that 61% of banks couldn't fully share client profile data across systems for KYC reviews. That's the kind of gap that only shows up once someone traces the data flow end to end, instead of assuming the systems already talk to each other. This connects to how KYC, escrow, and external APIs typically wire together, which is worth its own read if the platform in question handles both.
Fraud and risk scoring. These systems often pull data points from places nobody lists in the official architecture diagram, simply because they were bolted on incrementally over the years.
Reconciliation and reporting exports. Finance and compliance teams frequently build their own extracts from a legacy system. These are the "shadow" integrations that tend to go undocumented until they break.
Licensing and scheduled processes. Interest calculations, fee accruals, and end-of-day jobs are often tied to specific software versions or scheduled tasks that need an equivalent in the new environment, and not just a copy-paste.
These threads take longer to trace than most project plans allow for, largely because dependency mapping isn't a single meeting. Someone has to open the actual configuration, sit with whoever owns the scheduled jobs, and follow the data from source to destination, instead of trusting an architecture diagram someone drew two reorganisations ago.
Why This Phase Gets Underestimated
This is also where migration timelines usually go wrong. Hollinford's analysis of realistic modernisation timelines puts the typical range for a comparable SMB migration at three to eighteen months. The gap between the optimistic end of that range and the eighteen-month reality rarely comes from the rebuild itself; more often it comes from the mid-project discovery of dependencies that should have been mapped at the start. Fintech adds a layer to that problem, because the discovery often happens inside a regulated process, where "we'll fix it as we find it" isn't an acceptable answer, as the ledger team above found out the hard way.
Real time spent on dependency mapping before a cutover date is committed pays for itself twice over. It keeps the schedule honest, and it gives compliance and risk teams something concrete to sign off on, rather than a promise that nothing important will break. We've written separately about why compliance teams trust a well-built wallet platform, and this phase is a large part of where that trust is actually earned.
A Working Checklist
Before scoping a core migration or a major wallet re-platforming, confirm the following, organised by the five categories above.
Data
Integration
Process
User
Infrastructure
Every one of these checks is simple to describe and tedious to execute, which is why teams under deadline pressure wave them through, and why the cost only shows up later, once the schedule already assumes nothing was missed.
Takeaway
A fintech core migration gets judged by its cutover date, but the outcome is really decided months earlier, in whether anyone actually traced what the old system connects to. The interest-accrual table that stalled the ledger migration above wasn't a technical failure; it was a dependency nobody had gone looking for. Mapping data, integration, process, user, and infrastructure dependencies before scoping the project won't make a migration fast, but the timeline the team eventually agrees to will be one they can actually trust.
Frequently Asked Questions
It depends on how well the current system is documented. For a relatively well-documented fintech platform, focused audit work can take several weeks. Environments with a long history of informal integrations, undocumented processes, or unclear ownership take considerably longer.
Ideally more than one person. Engineering can trace integration and infrastructure dependencies well enough on its own, but finance, compliance, and operations usually know about the manual workarounds and process dependencies that never made it into any diagram. Leave them out of this phase, and those are precisely the dependencies that get missed.
Up front, yes — it adds time before anything visible gets built. Overall, though, it tends to shorten the project, since it catches problems while they're still cheap to fix. A dependency found in week two of an audit costs a conversation. The same one found in week two of a cutover can cost weeks of rework.
Run the same exercise either way. What changes is how forgiving the timing is. A full replacement surfaces every missed dependency at once, at cutover, with no earlier phase to catch it. A phased or strangler-pattern migration tends to expose missed dependencies one component at a time, so a gap in one area rarely takes down the parts that have already moved.
Related articles
About the Author
