Migrating Data Models with AI: When It Accelerates and When It’s a Risk

How long would it take you to migrate dozens of reports tightly coupled to their source, without ever pausing development, and with certainty that the translation is correct?

ÁLVARO GONZÁLEZ-IGLESIAS
Data Engineer

Imagine you have a set of reports that already works, that answers real business needs, and that connects directly to the source without any control layer in between — and now you have to build a data platform on top of it. How do you approach that data model migration without slowing down what’s already in production? Could AI help you migrate dozens of reports tightly coupled to their source, without pausing development, and with certainty that the translation is correct? And, more interestingly, where does it make sense to lean on a language model (LLM), and where doesn’t it?

These questions, among others, are what I try to answer in this article, where I share my real experience migrating data models with AI.

The Invisible Gravity: Knowledge Silos and Duplicated Work

The starting scenario is more common than it seems: each report had its own direct connection to the source and its own data model. This wasn’t a design mistake — it was the natural result of solving specific problems with the resources at hand. But as the system grows, that’s when the real cost shows up.

The problem is that the full knowledge of each chain lives in the person who built it: they know what data flows through, how it’s transformed, and what business logic was applied along the way. If that person isn’t available, the report becomes a black box nobody dares to touch. That’s a knowledge silo, and it’s exactly the kind of obstacle worth avoiding whenever possible.

The second consequence is purely operational. When each report is tied to its own connection, logic isn’t inherited — it’s rewritten. So when a business rule changes, you have to update it everywhere it appears, with no guarantee that all the copies end up in sync. The effort multiplies, and consistency becomes an act of faith — something we already experienced when integrating fragmented data from dozens of acquisitions into a single platform.

Against that backdrop, a centralized approach flips the equation:

• You work it once: the data is processed, documented, and validated in a single place.
• You use it many times: any report or BI tool consumes that same source.
• Knowledge stops being personal: it lives in the platform, not in the head of whoever built it.

Knowledge that lives only in one person isn’t an asset. It’s a dependency.

ÁLVARO GONZÁLEZ-IGLESIAS
Data Engineer

In this context, centralization isn’t an aesthetic preference — it’s what separates a scalable platform from a set of reports that only grows in debt.

The New Orbit: Centralizing Without Pausing Development

The goal was clear: a centralized platform with control and governance over information, where data has a single source of truth. Once that destination is defined, the hard part is getting there without shutting down what already works.

And here’s the constraint that shapes the entire project: you can’t freeze development while you build the new architecture, because the business keeps asking for reports and nobody’s going to wait months for the platform to be ready. The migration isn’t a project with a clean cut between before and after — it means building a new platform in parallel until it catches up with the one it’s replacing, which, in the meantime, keeps moving forward too.

That means you need functional parity before you can retire anything: the new system has to produce exactly what the old one produces, until you can replace it without anyone noticing the change — except for what improves behind the scenes. Until you reach that parity, both worlds coexist, and with every week of migration, the gap between them can widen. The architecture stops being a purely technical matter — just like when a decoupled architecture reduces time-to-market in complex environments — and becomes the piece that speeds up or slows down everything else.

It’s as much a speed challenge as a technical one, because if migrating each model by hand takes as long as building it from scratch, you never catch up with a moving target. That’s when the operational question comes up: how do you speed up model translation without sacrificing the control and governance that are precisely the reason for migrating in the first place? That’s where AI comes in, with a very specific fit.

Migrating Data Models with AI: Translation with Objective Validation

Migrating a model directly to the new platform is, for the most part, mechanical: analyze a schema, understand its structure, and map it to the target architecture. It’s repetitive, tedious, and eats up time that could go toward harder problems. It’s exactly the kind of task where a language model really multiplies your output.

I gave Claude the report schemas — never the data. In other words, the language model had to work from structure rather than content. That decision is the crux of the exercise, but first, it’s worth explaining why the speed gain was real and not an illusion.

The key is that we started from a verifiable validation target. The old report — the one currently in production — acts as the source of truth: I don’t need to review every translation decision step by step, because I have a known reference result to compare behavior against. The criterion is simple:

1. Claude translates the schema to the new platform.
2. I run the new model against real data, month by month.
3. I compare the output with that of the old report.
4. If they match, the translation is correct. If not, I know exactly where to look.

This changes the nature of the work, because validation stops being an exhaustive manual audit and becomes a result check. Not because mapping schemas and rebuilding transformations is trivial, but because the cost of verifying drops sharply once you have something to compare against.

And there’s a benefit I didn’t expect: by comparing the new model against real data, the process surfaced things that would normally go unnoticed in regular development — latent bugs in the old models, fragile spots, or places where performance could be gained. It’s something anyone who has rebuilt a legacy platform recognizes immediately. What would otherwise require a separate audit-and-optimization team fell out here as a byproduct of the translation.

I didn’t just win the migration. I gained a complete picture of the real state of the models I was migrating.

ÁLVARO GONZÁLEZ-IGLESIAS
Data Engineer

AI didn’t design anything — it translated fast and, along the way, exposed the terrain. The decisions about what to do with what it exposed stayed with me and the team.

When AI Is a Tool and When It’s a Risk

AI worked here because the input was structural, not sensitive. A table’s structure doesn’t compromise anyone’s data protection, and I gave the model schemas, not data. Feeding in real information changes the nature of the problem, and thinking “it’s already anonymized” isn’t enough.

Even though providers like Anthropic don’t use the data you send them to train their commercial models, the risk isn’t just about data leaving your perimeter — it’s more subtle than that: a model can make inferences across fields that seem unconnected. A poorly obfuscated identifier, or a combination of attributes that are harmless on their own, is enough for it to reconstruct context you never meant to reveal. And as Spain’s data protection agency (AEPD) warns in its own anonymization guide, the same capabilities used to anonymize can be used to re-identify: partial obfuscation gives a false sense of security.

That’s why the question of when to lean on AI comes down to a fairly clear distinction:

• Where it works: structural, repetitive tasks with a verifiable validation target and no sensitive data involved. There, AI is an accelerator with very little risk.
• Where it doesn’t, or only with extreme caution: any process that loads sensitive information into an agent without a rigorous guarantee that nothing can be inferred from it.

AI is a double-edged tool and a multiplier: it amplifies good judgment into speed, and bad judgment into exposure. Responsibility never lies with the tool, but with the judgment of whoever decides what goes into it. It’s the same idea we defend when we talk about clean code with AI agents: AI changes the cost of execution, not the need for human judgment.

If you’re about to tackle a similar migration, before choosing the model or platform, decide what information can leave your perimeter and what can’t, so AI only touches the former. Then, find a validation target you can compare results against without reviewing every step by hand. With those two pieces in place, speed follows on its own — without compromising the control that justified migrating in the first place.