A client's CTO once told me they were "eighteen months away from being ready for AI." That was three years ago. They're still eighteen months away. In the meantime, they've spent those three years making the IBM box slightly less embarrassing, and shipped exactly zero AI features.
We've built the opposite playbook. Not by ignoring the legacy, but by designing around it from day one with AI-readiness as a first-class constraint, not a future ambition.
The migration fantasy is costing you more than the COBOL
These conversations almost always end the same way: “We need to replace the core system first.” It sounds like the safe plan. But in reality it often becomes a comfortable reason to delay shipping anything for years.
Because here’s what’s true in most large banks (and many other enterprises): the legacy systems aren’t “temporary.” They’re deeply embedded, they run critical processes, and they’ll likely still be around in 5+ years. You do not rip out the engine of a plane in flight because a newer model exists.
What actually happens when you try: in April 2018, TSB migrated its corporate and customer systems to a new platform. The data migrated successfully; the platform immediately failed. The result was a £62 million regulatory fine, over 225,000 customer complaints, and a CEO resignation. TSB had three years of planning, 85 specialized subcontractors, and full board oversight.
The failure was not a resourcing problem. It was an architectural one, they tried to replace a system they didn't fully understand, on a timeline driven by politics rather than engineering reality.
So when we walk into these situations, we don’t start with “replace the core.” We start with a simpler, more pragmatic decision: assume the core will stay, and design a way to ship around it.
In one mid-size consumer credit bank we’re working with - COBOL/RPG on IBM Power, General Ledger, CIF, Loan Management, Payment Processing - we made an early decision to treat the IBM box as a trusted, stable data source and build around it. That framing changed everything about what we could ship in sprint zero. And it’s the same framing that makes the AI layer viable.
From there, we build a controlled layer around the system of record: clear integration contracts, a connector surface we can observe and operate, and a delivery path that lets teams ship value while modernization continues in parallel, instead of waiting for a “perfect” future platform that keeps moving further away.
Why “end-to-end” matters (and why org charts miss the point)
A lot of transformation programs get stuck in the wrong framing: “we need a frontend partner” and “we need a backend partner.” That split looks tidy on a slide. In practice, it often creates a delivery gap right where regulated transformations are hardest: the space between a legacy system of record and a production product that people can safely depend on.
The result is predictable:
- UIs that demo well but can’t be trusted in production because the integration contract is vague
- “AI initiatives” that never leave pilot because the data arrives too late, too messy, or without governance
- A dependency chain where nobody owns the whole outcome, only their piece of the stack
In these environments, “end-to-end” doesn’t mean “one vendor does everything.” It means someone is accountable for the delivery surface where value is made real:
- Clear integration contracts (inputs, semantics, error cases)
- Event/data flows designed for timeliness, not convenience
- Observability and operating model for non-deterministic systems
- Build and run discipline: shipping is only half; operating safely is the other half
This is where transformation succeeds or quietly dies, and it’s why the “frontend-only” label is so often a false economy.
The integration layer is the product
Technical section → skip if you're not in the weeds. If you don't work directly with engineering teams, feel free to skim this one. There's a TL;DR version at the bottom.
Most teams talk about the bridge between "old systems" and "new cloud stuff" like it's temporary glue. But that "glue" is exactly where modern products - and AI features - succeed or fail. AI isn't blocked by the model as often as people think. It's blocked by what surrounds the model: whether you can get the right data out of legacy systems, whether that data is consistent and understandable, whether it arrives in time to be useful, and whether the whole setup is reliable enough that the business dares to depend on it.
That's why the integration layer isn't just plumbing. It becomes the front door to your legacy systems. It's where you define what the data means, what's allowed, and what happens when something breaks. So it needs to be treated like a real product: it needs ownership, reliability targets, monitoring, and an explicit roadmap.
Teams that get this right don't wait for a migration to be finished before they ship. They ship by investing in the connector first, and then everything else compounds.
👀 TL;DR: That boring middle layer that connects your old systems to your new ones? That's the thing that decides whether your shiny new AI feature actually works. Build that part well. If you treat it like a real product, not a stopgap, you can start shipping things now, instead of waiting years for "the big migration" to finish.
What AI-native actually means and why most organizations have it wrong
This is the section most people in our industry need to sit with. "AI-native" has become shorthand for "we have a ChatGPT integration." It is not that. 😬 Let me be specific about what it means at the infrastructure level, because this is where Nimble's work over the last three years has sharpened into a distinct point of view.
AI-native architecture has three technical requirements that have nothing to do with which model you use:
Event-driven data flows. AI models are useless on stale data. If your signals (transaction behavior, document uploads, credit events, clinical observations) are available only in overnight batch, you cannot build real-time AI features. The first infrastructure question we ask on every engagement is: where does the event boundary sit, and how close can we get it to the source system?
Clean, owned integration contracts. An AI model receiving inconsistent, undocumented inputs produces inconsistent, undocumented outputs. The integration contract between the legacy system and the AI layer is not a technical detail. It is the product specification for every AI feature built on top of it. When we surface customer data, loan state, and payment history from the COBOL system through defined Db2 REST interfaces, we are writing the spec for what the AI can know and when.
Observability built for non-determinism. An LLM's output is not a database query. You cannot unit test it into predictability. What you can do is build the logging, tracing, and human-review workflows that let you catch when it's wrong and understand why. This is different from standard APM tooling, and most platform stacks don't have it out of the box.
The 2025 DORA report confirmed what we've seen on the ground: AI acts as a multiplier of existing engineering conditions, not a shortcut past them. High-quality internal platforms are the single strongest predictor of an organization's ability to unlock AI value. If your integration layer is a mess, adding a language model makes it a faster mess.
What this means in practice: the AI layer we're designing for the consumer credit bank (Azure OpenAI Service with EU data residency, Document Intelligence for KYC, behavioral fraud signals) is viable precisely because the three conditions above are met. The COBOL system surfaces data through defined interfaces. The event pipeline is as close to real-time as the source system permits. The observability layer is being built alongside the AI features, not retrofitted after them. This is not accidental. It is the architecture we designed for before writing a single AI prompt.
Nimble has spent three years building this capability specifically for complex, regulated enterprises. The hospital engagement proved that AI-native is possible on top of legacy clinical systems. The bank engagement is proving it for financial services. The pattern is repeatable because the underlying architecture is the same: clean contracts, event-driven pipelines, platform-encoded compliance, human oversight at the right boundaries.
Platform engineering is the unlock, not a nice-to-have
Kelsey Hightower, at PlatformCon 2025, put it plainly: "Platforms aren't magic APIs. They're agreements between humans about how work gets done." This is the sentence most engineering leaders skip past on their way to evaluating tooling. The platform is not the tooling. It is the set of decisions that have been made so that individual developers don't have to make them again.
The 2025 DORA report found a direct correlation between high-quality internal platforms and an organization's ability to unlock AI value. 90% of organizations have adopted at least one platform, but quality varies enormously and the gap shows up exactly where you'd expect: in how quickly AI features move from prototype to production.
In a regulated environment (hospital, bank, insurer) the platform has to encode the compliance constraints, the data residency rules, the audit trail requirements. When it does, AI features that would otherwise take quarters to clear compliance review can be built and deployed in weeks, because the guardrails are in the platform, not in a PDF that someone might read. This is one of the structural advantages Nimble brings to enterprise engagements: we've built these platforms enough times to know which compliance constraints need to be first-class platform concerns and which ones can be handled at the application layer.
What this means in practice: for both our hospital and bank engagements, sprint zero delivers CI/CD, the on-prem Kubernetes cluster, the integration bridge, and the observability stack. Not because it's a nice foundation. Because without it, every AI feature is a one-off → impossible to audit, impossible to scale, and one regulatory review away from being shut down.
The regulated industry AI friction is real, but most teams are solving it wrong
There is legitimate compliance complexity in deploying AI in healthcare and financial services. EU AI Act obligations for high-risk systems, GDPR constraints on data, the Digital Operational Resilience Act's requirements for financial services; these are not theoretical. They have real engineering implications that teams building in consumer or SaaS contexts simply don't encounter.
But the common response "we'll wait until the regulatory picture is clearer" consistently costs more than the compliance work itself. Teams that sat out 2024 and 2025 waiting for regulatory clarity are now a full productivity cycle behind peers who made pragmatic choices about where AI tooling runs and where it doesn't.
The pragmatic answer is architectural, not procedural. Use AI coding assistance freely on the BFF layer, the CMS integration, the frontend: the parts of the stack that don't touch regulated data. Keep human review on anything touching the integration bridge to core banking or clinical systems. Build the observability to prove the boundary holds. This is not a compromise. It is the correct design.
What this means in practice: we run AI coding assistance freely on React, Node.js, and Payload CMS work. The IBM App Connect Enterprise configuration and the Db2 REST service definitions are reviewed by engineers. The line is not arbitrary → it maps exactly to where regulated data begins. Three years into this approach across hospital and financial services contexts, it works.
We know where the line is, how to document it for regulators, and how to explain it to a board.
The organizations that ship are the ones that decided
There is no clean version of this problem. There is no migration that removes the complexity. The IBM box will be running in five years. The integration layer will still be there. The question is whether you treat it as a liability to be hidden or an asset to be engineered.
The organizations shipping AI features in complex, regulated environments right now are not the ones who finished their cloud migration. They are the ones who decided, early, that the connector between the old world and the new one was worth building well, with owned contracts, observable pipelines, a platform that encodes the compliance constraints, and a team that treats integration as a product.
Nimble made that decision three years ago. Not as a thesis, but as the only way we could actually ship for the kinds of clients we work with: A hospital running a 15-year-old EPD. A bank running COBOL on IBM Power. Organizations where the stakes of getting the integration wrong are measured in patient data and regulatory fines, not sprint velocity.
If your team is still treating the IBM box as the problem, you're solving the wrong equation.
.jpg)
