The case against rip-and-replace AI: meeting your data where it lives

Most data migration projects are sold on a diagram that doesn't survive contact with the actual data. The diagram has clean boxes and clean arrows. The actual data has a column called cust_id_v2_FINAL that three teams use differently, a nightly job nobody owns, and a table that exists only because someone needed to fix a reporting bug in 2019 and never got around to deprecating it. Right now, that diagram is being aimed at every company trying to do something useful with AI.

The situation

The default sales motion in enterprise AI has settled into a familiar shape. To get value from AI, you're told, you need to consolidate your data into a modern platform. Move it off the legacy warehouse. Get it out of the on-prem systems. Land it somewhere that the AI tooling was designed for. Then you can build.

The pitch is clean because the alternative is messy. The alternative is your actual data estate, which has accumulated for fifteen or twenty years and reflects every acquisition, reorg, and emergency patch the business has lived through. Migrating that into a single new platform is presented as the cost of doing AI seriously.

For a small percentage of projects, that calculation is right. If the system of record is genuinely end-of-life, if the vendor is sunsetting support, or if the data model is so broken that no integration layer could paper over it, a migration is the project and the AI is the reason to finally do it. That's a real category. It's also a small one.

For most projects, the calculation goes the other way. The migration becomes the project. The AI work that justified it sits in a backlog while the team spends eighteen months reconciling schemas, rewriting business logic, and discovering that the lineage documentation everyone thought existed does not, in fact, exist. By the time the new platform is live, the original AI use case has either been deprioritized or solved by a vendor tool that didn't require any of this.

The misconception

A migration just relocates the problem, usually while breaking things, and then presents the bill.

The assumption underneath the rip-and-replace pitch is that the data is in the wrong place. Wrong system. Wrong format. Wrong warehouse. Move it, and AI becomes possible.

That's almost never the actual problem. The actual problem is that nobody has read the schema carefully in a long time. The lineage is undocumented. The business logic lives in stored procedures, in ETL jobs, in the heads of three engineers, and in a Confluence page last edited in 2021. The semantics of half the columns are contested between teams. The right question to ask any vendor pitching a migration is what specific thing in the data estate makes it necessary, and what specific AI capability is unlocked by it. If the answer is general — modernization, future-proofing, AI-readiness — the migration is the project and the AI is the justification.

Meeting your data where it lives means starting from the opposite premise: the data estate you have is the data estate you're going to keep working with, and the job is to build something that works against it as it actually exists. Not as it would exist in a redesign. As it exists today.

This is less satisfying than a greenfield. It does not produce a clean architecture diagram. It requires the AI work to accommodate the data estate rather than the other way around. It also tends to ship.

What this looks like in practice

The work is mostly integration work nobody finds glamorous: reading the schema, tracing the lineage, talking to the engineers who know which columns are reliable and which ones are decorative, then building an integration layer that lets AI systems query the data estate without requiring the estate to be rebuilt first.

The piece of this work that's getting harder to ignore is auditability. When a regulator asks how a model arrived at a decision, the answer needs to walk back to a system of record with a defensible audit trail. Integration approaches keep that system of record where it already lives, with the controls that are already in place. Migration approaches require rebuilding those controls in a new environment, and the rebuild is rarely complete on the day the model goes live. For mid-market and enterprise buyers in regulated sectors, that gap is the part of the project that wakes people up at night.

The trade-off

The trade-off is real, and worth naming.

Meeting data where it lives is slower to start than a migration project that ships a kickoff deck in week two. It requires a more senior client team to evaluate, because the value of the approach is legible mostly to people who have lived through a bad migration and know what it cost. It produces less impressive architecture diagrams. It does not generate the "we modernized our stack" headline that some leadership teams want from an AI initiative.

It also makes some vendors uncomfortable, because the pitch is harder. "We will work against the data estate you have" is a less exciting sentence than "we will build you a modern platform." The first one has earned us most of our enterprise relationships. The second one would have been easier to put on a website.

Rip-and-replace is the project that looks decisive in a board deck. Integration is the project that ships.