Migration Path — Four Phases
Section 5 of Agentic Banking Architecture: A Practitioner's Guide
Every post in the series that led to this guide generated the same question: how do you get there from here?
No bank is going to switch off its applications and replace them with agents overnight. The transition will take years. But it's not the transition most people imagine — running two parallel stacks, legacy and agentic, side by side. Instead, the legacy applications will be transformed gradually to align with the agentic target state.
Phase 1: Wrap the Legacy
Expose the functionality and data of existing applications to agents as tools — using MCP or similar protocols. The applications don't change. The agents call them the way a developer calls an API.
This is where most banks are starting today, and it delivers value immediately: agents can orchestrate across applications that were never designed to work together. A customer onboarding agent can call the KYC system, the account opening system, and the document management system in sequence, handling exceptions and routing edge cases — without any of those systems being aware of each other.
The investment is modest: define tool interfaces for existing systems, deploy an agent orchestration layer, and start with high-value processes where cross-application orchestration is currently manual or fragile.
Phase 2: Migrate the Logic
New products and services are built as pure agentic processes rather than application features. Over time, more of the investment goes into agent logic and less into application enhancements.
The business logic in the applications starts to look like a constraint — hardcoded rules that limit the configurability of the agentic layer. Teams begin stripping business logic out of the applications and replacing it with agent-driven processing. The credit assessment that was hardcoded in the lending system becomes a credit policy managed through the policy codification pipeline.
This is the phase where organisational changes will start to take place. The team that maintained the lending system's business rules now maintains lending agent policies. The skills are different. The tooling is different. The deployment cadence is faster. See Section 10: The People Transformation for how this plays out.
Phase 3: Thin the Applications
As business logic migrates out, the applications flatten. What's left is data access — CRUD operations on the underlying stores. The application that used to be "the lending system" becomes a thin data service that agents call to read and write lending data. It no longer contains credit assessment rules, pricing logic, or approval workflows. Those live in agents.
At this point the application is barely an application. It's a data access layer with a legacy user interface that some internal users may still prefer. The economic case for maintaining it weakens as agents handle more of the workflow.
Phase 4: Dissolve into Ledgers
in this final step, the thin data services are replaced by shared ledger services — golden source data stores that multiple agents access directly. The "lending data service" becomes entries in a shared financial ledger and a shared customer ledger. There's no lending database because there's no lending application. There's just data, organised by domain, accessed by agents through standard services.
This is the target state described in Section 4. Not every system will reach Phase 4 — some legacy constraints, regulatory requirements, or vendor dependencies will keep certain applications alive longer. But the direction of travel is consistent.
Two Implications
The legacy application advantage
As noted in Section 4, the banks running legacy in-house core systems may now have an ironic advantage. They own the code. They can expose it as tools, strip out logic, and flatten to data services on their own terms. Banks locked into vendor packages need their vendor to cooperate - and the vendor's incentive will be to keep the business logic inside the product.
Transformation programme redirection
Banks currently running large application replacement programmes don't need to stop. But their goal should change. Instead of replacing one silo with a better silo, redirect the programme towards thinning the application - exposing its functionality as tools, extracting the business logic, and preparing the data for migration to shared ledgers. Same budget, different destination.
Current State of Industry
Most banks are in early Phase 1 — wrapping selected systems and running pilot agents. A few are in late Phase 1, with production agents orchestrating across multiple wrapped systems. Very few have entered Phase 2 for any meaningful business domain.
The deterministic-to-probabilistic spectrum in Section 6 provides a framework for deciding which processes to migrate first. Start at the predictable end of the spectrum, where agents generate deterministic code and the governance requirements are lightest. Build confidence, capability, and institutional trust before moving to the adaptive end.
This section expands on ideas first published in Part 5 of the LinkedIn series. The discussion focused on migration sequencing, the legacy application question, and whether current modernisation programmes should be redirected.