I have participated in and led enterprise-scale data migration projects for the financial services, real estate, homebuilding, and healthcare industries for the better part of three decades. I’m curious about ways to leverage AI to help improve outcomes in these large projects, particularly when they result from a significant acquisition event.

These are projects that involve moving and transforming business data from an acquired company into the acquirer’s existing systems. Such a project involves data from all critical functions including ERP, CRM, and HR. Almost always, additional bespoke and third-party systems are involved. Such projects require a large amount of business process reconciliation, as no two companies do things in exactly the same way, even if they happen to both be using the same ERP and/or CRM vendor platforms.

Where AI Actually Helps

There are some standard migration project tasks which are clear candidates for leveraging AI. First, AI can significantly accelerate repetitive generation of migration environment staging objects. In addition, AI can save a great deal of time during profiling of inbound source data. And finally, AI can perform a reasonable amount of necessary gap analysis at the data element level.

The repetitive generation of objects required in the migration environment has traditionally been the “cookie-cutter” work assigned to junior developers, freeing senior resources for profiling and more complex transformation logic. AI now does this work in minutes rather than days. And since the definitions for inbound data types are unambiguous, given a template, it can quickly generate several hundred migration objects and pipelines error-free.

AI is equally useful for accelerating source-data profiling. Beyond simple checks, such as flagging out-of-range values or identifying duplicate records, AI can be leveraged to catch subtler problems: for example, a shipped order with no corresponding invoice record, or a customer marked active with no transactions in years. These are violations that only surface once data is examined across multiple parts of the source system, against the business rules and expectations set during scoping.

Finally, AI can compare destination-system requirements against what’s actually available in the source and generate gap analysis quickly. For instance, it can flag that the source system has no place to store a required destination attribute. This surfaces both simple data-element gaps and, in some cases, process gaps that will require human deliberation to resolve.

These are real, valuable gains. Each week spent running systems in parallel has a real financial impact: doubled licensing and compute costs, plus systems drift, which is when business practices in either the source or the destination system change between project initiation and cutover, usually in response to changes in the business environment. These gains do shorten the calendar time before cutover, thereby lowering the cost of the migration itself. But staging, profiling, and gap analysis do not comprise the bulk of the work of a migration project. That work belongs to someone else.

Why the SME Work Doesn’t Shrink

As professional migration practitioners know, the largest amount of time spent in a migration project is by the Subject Matter Experts (SMEs) performing the bulk of the analysis and problem-solving during the project. They are tasked with:

  • Documenting all the business processes in a specific domain (such as accounts payable or new employee on-boarding) and the data elements involved in each process
  • Mapping known data elements from source to destination
  • Defining required transformations of inbound data to match usage in the destination system
  • Reviewing and resolving identified process-level gaps
  • Reviewing anomalies, edge cases and inbound use cases not present in the destination system
  • Creating remediation strategies for the above and documenting successful remediation during and after future trial migrations
  • Directing the creation and deployment of new data objects in the destination system to house in-scope data from source that has no current analog, as needed
  • Designing, conducting and directing User Acceptance Testing (UAT) for the trial migrations

That list, though, describes only the first wave of SME involvement. Successive waves follow once trial migrations begin, when SMEs weigh in on anomalies the original profiling didn’t catch, make judgment calls on cases that don’t fit the use-case catalog, and sign off on remediation before the next trial run. The size of these later waves has little to do with how well the first wave was executed: it’s a function of how well-aligned the two systems actually turn out to be, something that usually isn’t fully knowable until the trial migration is under way and the full set of in-scope data is being processed. When alignment is strong, these later waves can be modest. When it isn’t, which is the more common case, the cumulative time spent in this iterative remediation can match or exceed the time spent in the initial scoping, profiling, and mapping stages.

That structure holds through cutover as well. SMEs are present for the final go-live, running the last round of UAT and keeping eyes on the live process as it happens. This isn’t a rehearsal for something AI could eventually take over. It’s a role that has to be filled by someone who understands the business well enough to catch what’s wrong in the moment, in real time, with no trial run to fall back on.

There’s a second role AI can play that recurs at every hop along the migration path and again at cutover: technical validation. This consists of a predefined set of low-level comparisons of the actually-migrated detailed system data against what was expected based on the known source data. These tests must run and clear before SMEs invest time in UAT, since there’s no point testing whether the business can use data until it has been confirmed to have migrated cleanly. Running these checks has always been fast. Writing them hasn’t, and for a data team typically at full capacity for the life of the project, that work competes for hours they don’t have to spare. When AI writes the tests instead, that work falls off the critical path, not because the tests run any faster, but because generating them no longer competes for the data team’s scarce time. It’s still not UAT: technical validation confirms the data arrived correctly; UAT confirms the business can use it, and that judgment stays human.

It’s tempting to think a team of SMEs, data engineers, and business leaders could simply ask AI to resolve each challenge as it arises, and it’s even conceivable that AI would occasionally suggest the optimal answer. But the analysis and decision-making are still best performed by humans who know the business context intimately and understand, at a detailed level, how each system actually stores and uses its data. That work takes time: reviewing findings, collaborating and brainstorming on solution approaches, and testing with the data engineers until each issue is genuinely resolved, not just technically closed. Even when a company does turn to AI to “discover” a solution, prudence dictates that an SME-led team still has to review it thoroughly before it’s trusted, which erodes much of the time AI was supposed to save. Add it all up, across every domain and every wave, and this human work typically accounts for two-thirds to three-quarters of the total project timeline, expanding further whenever the source data is poor in quality or the two systems are structurally misaligned.

To reiterate: for most organizations, the gains stop there, with the repetitive object creation, profiling assistance, and gap analysis already described.

The One Real Exception

There is one partial exception to this pattern: an organization that has already built a well-designed, robust agentic-AI system for a given business domain, such as Accounts Payable. Because that system already operates the domain, it already “knows” the full set of requirements involved, not just at the level of individual data elements, but how a set of values, often spread out across multiple locations in the system, has to line up to constitute a valid instance of that business function. Fed the destination system’s requirements, this kind of AI can perform gap analysis at that same higher, structural level, rather than simply flagging missing or empty source attributes. This is the more robust gap analysis work that would otherwise fall to SMEs in the first wave.

For a single domain, or even a handful, having this work completed by AI is a genuine improvement over basic attribute gap analysis. However, the aggregate effect on the overall project timeline is still marginal, since most large-scale migrations touch dozens of business domains, and hundreds, if not thousands, of individual business processes. Whether this advantage stays incremental or becomes genuinely significant depends entirely on how much of the in-scope business landscape is properly covered by mature agentic AI: a narrow footprint yields a modest gain, a broad one could meaningfully compress the timeline.

Conclusion

AI genuinely accelerates certain technical corners of a migration project: staging, profiling, and increasingly, gap analysis. Every week saved is a material gain. But the largest part of the project will remain within the domain of SMEs and the humans supporting them, and any expectation that AI will cut a true enterprise migration’s timeline in half, or even close to it, is going to disappoint. What actually drives the timeline is SME availability, the degree of business-process alignment between the two organizations, and the quality of the source data. AI doesn’t move any of those.

That being said, the involvement of people with long experience in the enterprise migration trenches can also make a material difference. A specialized migration firm provides the experience complex migrations require: fine-tuned methodology, practitioners who have seen the standard challenges many times over, and the ability to operate across the full spectrum from the initial scoping through the final cutover and hypercare period. Engaging such a partner who also has the capacity to leverage AI for the gains described here warrants serious consideration.

What are you seeing in your own migrations? Where is AI genuinely helping, where isn’t it, and where would you push back on any of this? If you’re in the middle of one of these projects and want to compare notes, reach out.

Patrick Mundy is a co-founder of Rocketweave, a consulting firm focused on post-acquisition data migration. He has spent his entire career at the intersection of enterprise data and business process, bridging the gap between what organizations need their data to do and the technical architecture required to make it happen.

Originally posted on LinkedIn.