We just got back from Gartner, where every conversation at our booth boiled down to the same thing: migrations are a mess, and everyone is drowning in a complexity of edge-cases. 

Everyone’s living in some version of the same nightmare: sprawling tech stacks, undocumented business logic, legacy systems glued together with brittle scripts.

The industry knows migrations are hard, but no one realizes just how uniquely hard each one is until they’re in the middle of it. The edge cases are what kill migration projects–not the big, obvious problems, but the weird, unpredictable ones that no tool or playbook can fully anticipate.

For many companies, that’s enough to keep them from migrating at all. We talked to teams who signed cloud contracts years ago but are still running primarily on their legacy stack. Why? Because the sheer complexity of their migration has kept them frozen in place. They know how quickly a single overlooked edge case can derail the entire project. 

Traditional automation and rule-based approaches have hit a wall. We’ve maxed out on the horizontal sprawl of edge cases. The only viable way forward is leveraging large language models (LLMs), which can navigate the web of dependencies, legacy systems, and unpredictable variations that define real-world migrations.

The one-size-fits-all illusion

Every migration feels like its own special version of hell. Technical debt, undocumented dependencies, and brittle workflows that no one fully understands? We’ve all dealt with that no matter the company, industry, or stack. 

Where migrations get truly painful, and personal, is in the edge cases. No off-the-shelf tool can account for the weird, tangled, one-off issues that emerge once you’re deep into a migration. These aren’t the big, obvious problems. It's the long tail of weird exceptions: things you didn’t anticipate, couldn’t plan for, and now have no clear way to fix. 

Unsurprisingly, that’s what we spent most of our time talking about at Gartner. Some of these probably sound familiar:

• 15 years of ETL pipelines in Informatica: A company has spent 15 years weaving ETL pipelines with Informatica, deeply embedding business logic in transformations that are now mission-critical but undocumented. They want to move to Snowflake or Databricks. How do you extract the logic without breaking the business?
• A database that’s become an application: The database is running an entire ecosystem of business logic inside stored procedures. Some are a decade old, written by engineers who have long since moved on. How do you untangle this mess without rewriting everything from scratch?
• A post-acquisition tech mess: A company has grown by acquiring others, each with its own tech stack. One runs SQL Server, another is on Oracle, and a third still clings to an on-prem PostgreSQL cluster. The mandate is to centralize on a single cloud platform. What could go wrong?
• No one knows what half the scripts do: They’ve been running for years, untouched, but someone somewhere depends on their output. Migrate too aggressively, and you’ll find out the hard way which ones actually matter.
• Regulatory landmines everywhere: A move to the cloud sounds great until you realize that certain workloads are subject to complex data sovereignty rules. Some data must remain in specific regions, some requires anonymization, and some is locked behind obscure regulatory gates that weren’t a problem in an on-prem world.

In each case, teams starting a migration start with a plan. But it’s the edge cases that turn it into chaos.

We’ve maxed out on horizontal sprawl

Every migration starts with a plan, and then the edge cases show up.

A tool that migrates Informatica workflows doesn’t understand the SQL stored procedures they interact with. A database migration tool won’t rewrite the brittle scripts feeding business dashboards. A refactoring framework might handle 80% of the code, but the last 20% drags the project into months of manual fixes.

So what happens when the tools run out? You throw people at the problem. A senior engineer who’s been through it before. A consultant who’s seen it all. A team grinding through manual fixes. Maybe it works. Maybe it drags on for another six months.

This is where we’ve hit the limit: humans + static tools = maxed out sprawl. Every new edge case requires another tool, another person, another workaround. It’s unsustainable.

That’s where LLMs change everything.

LLMs change the migration equation

Large language models offer a fundamentally different approach. Instead of rigid rule-based automation, they can reason across multiple layers of complexity.

They learn from documentation, code, metadata, and implicit patterns, allowing them to navigate the unpredictable nature of real-world migrations.

How LLMs change the migration equation:

Can AI really solve migrations? 

Everyone’s talking about AI, but most people at Gartner weren’t convinced it can actually fix migrations.

We get it. There’s a lot of valid skepticism around AI-powered anything especially since most “AI-driven” tools turn out to be glorified rule-based automation with a fancy label.

So can AI really solve migrations? Not the AI most people have seen so far. The real breakthrough isn’t just using AI to convert code faster. It’s AI that understands context, learns from feedback, and adapts to complexity – something static automation tools (and even experienced engineers) struggle with. 

That’s the difference between slapping AI onto a workflow and actually using AI to solve the problem.

Don’t AI-migration tools already exist?

Yes, but not all AI tools are created equal. We looked at some of the well-known options, and here’s where they fall short:

• They don’t validate actual data: They check schema structure, but they won’t tell you if data values are silently mismatched between source and target
• They apply static rules instead of learning: If the first conversion isn’t perfect, guess what? You’re manually fixing it
• They ignore ETL, stored procedures, and workflows: Which means they leave the hardest parts of the migration untouched

For enterprise-scale moves, you need AI that doesn’t just translate code but ensures that everything still works. Migrations without data validation are a black box, since teams must manually test every transformation.

In a world where every migration is unique, the only scalable solution is one that can reason about the uniqueness itself. Datafold’s Migration Agent does exactly that. 

Why we built Datafold’s Migration Agent 

This isn’t the first time we’ve heard these frustrations. Datafold’s Migration Agent (DMA) isn’t just a code converter. It’s a full AI-powered migration engine that handles SQL, stored procedures, ETL workflows, and value-level validation (also known as data diffing).

Instead of treating migrations like a one-time code dump, DMA actually learns and adapts, refining its translations until parity is achieved automatically.

If we didn’t get to chat at Gartner, let’s connect. Book time here.