“The best laid schemes o’ mice an’ men, gang aft agley.” Robert Burns wrote that in 1785, and it holds up remarkably well as a description of post-acquisition data migration.

Last year, healthcare provider Northwell Health acquired Nuvance Health, its 21st acquisition since Northwell was formed in 1997. Ahead of that deal, Northwell had already committed to a 1.2 billion dollar investment standardizing on the Epic EHR platform, combining more than 30 separate EHR sources into one. Northwell CFO Michele Cusack described the scale of that work bluntly: “It’s basically ripping out the electronic health record and our backend revenue cycle processes: essentially the central nervous system, and installing this new Epic platform across the organization.”

With that integration project already in flight, Northwell then closed on Nuvance, taking the combined organization from 18.6 billion dollars in revenue to a projected potential 24 billion dollars. It is not hard to imagine how the data migration team’s leadership felt when informed that their project had just gotten a great deal larger. The team was already working with EHR data from 21 hospitals and roughly 900 ambulatory sites, covering close to 2 million patients annually. Overnight, they were tasked with adding EHR data from an additional 7 hospitals and 150 more ambulatory sites, covering up to a million more patients each year.

Northwell’s Nuvance acquisition is an extreme example of live system drift, but the underlying lesson applies far more broadly: post-acquisition data migration projects very often expand in scope. In Northwell’s case, the driver was a strategic merger that happened to land in the middle of an already-running project. Many migrations expand in scope even without a mid-project acquisition, simply through discoveries made during initial scoping, or through findings that only surface several trial migrations in.

Even if your organization has no reason to expect it will add whole new companies to a project’s scope, it is worth planning as though scope will change, especially in the early stages, as data discovery and use case analysis deepen everyone’s understanding of the inbound data estate. That means a project plan should not begin with an inflexible target date. Build in periodic scope-adjustment checkpoints, and expect that date to move, sometimes dramatically.

Have you lived through a scope change on a migration project that reshaped the timeline in ways nobody saw coming at kickoff?

Originally posted on LinkedIn.