I've gone through a number of acquisitions, and I've learned that looking for unexpected surprises is ultimately a waste of effort. Still, I often see teams assuming that if the systems are similar enough, then at least the early stages of integration should be straightforward, and that assumption doesn't last long once you actually start working with the data in the merged organization.
It's not just the systems, even if the underlying EHR is the same, there are multiple ways of operating a health system, and there are multiple entrenched ways that are not immediately visible and resurface when you start putting units next to each other, and you start running out of what seem to be the straightforward ways to align processes.
Everything down to the systems and structures being personnel and service lines should be readily apparent. I've been in that exact situation where at a high level, say platform, similar service mix, and even comparable size, there just isn't a way for a group to digest such a phenomenon when there are things like performance metrics that are unexplainably misaligned across sites, and the bad data narrative just complicates matters further.
It's usually something like length of stay or readmissions that is where it first becomes obvious, not because those are the only metrics that behave that way, but because those are visible, and people are conditioned to see those behave consistently, and once they don't, it forces a different kind of conversation that no one is really prepared to have that early.
What usually occurs is that everyone reconciles first, which is understandable, you check logic, walk through the calculations, check that nothing broke in the pipeline, and that recon is necessary, but it gets you very little when the issue is not the math, but the nature of the underlying work being done.
I remember one incident rather well where we kept circling a number that would not reconcile, and it took a long time when it shouldn't have to realize that we were looking at different operational decisions being played out in the data, not mistakes, just different approaches to patient flow that had been so ingrained in people's minds that they felt like standard operating procedure to the groups involved.
Once that clicks, the work changes whether you like it or not, because you're no longer involved in trying to fix something that is broken, you are involved in trying to make sense of something that was built on purpose, and those are two very different animals to deal with, particularly when the people who built it are still around and can answer questions as to the rationale behind the workings.
That is typically where the work required reaches the point where they cannot easily explain it to someone who hasn't experienced it. From the outside, it seems like once the systems are integrated, the work required should speed up. In actual fact, the opposite is true. Most of the work is spent explaining the differences between the systems, as opposed to actual, tangible work. If it is unexpected, then it is even more frustrating.
You can sense the difference in the way people respond to data when this occurs. There may not be an initially significant response, but small things, more questions, additional time spent validating, and then a bit of hesitation when someone is about to commit to a number. That sense of momentum is not technological in nature.
I've noticed teams try to respond to that by over-standardizing. There is a tendency for people to try to simplify the differences by saying, "choose a definition, align everything to it, and then we can get back to moving." I understand the desire to restore confidence, but it is an attempt to strip the process of any real context. This kind of thinking also leads to even more issues that are more difficult to identify and solve in the future.
During previous integrations there were times when everything aligned on paper, everything was consistent, the analytics were neat, and the closest people to the work were telling us it did not reflect what they were experiencing on the ground. That must not be a comfortable position to be in because you have lost both sides. There is no variation and there is no trust.
What helped in that case was not more technical work, but getting out of the data and getting into the operations. That is obvious in hindsight but it doesn't feel obvious when you are in the middle of it and trying to keep everything moving, and it involved spending time with teams who were not expecting to be involved in integration at that level.
Those kind of conversations do not have structure, they do not finish quickly, but they bring out the issues that are not documented anywhere, especially the informal decisions that people make every day that are not documented but drive the outcomes.
Once you see those patterns, the differences are no longer random. That is when the conversation shifts. It is not announced, it just shifts from trying to fix the data to understanding how the organization actually wants to function.
Not having visible changes does not mean this part remains unimportant. This part makes the difference as to whether the integration will work. It will determine if you will have to continue experiencing the same issues whenever anything new gets added.
Because all the preparatory work done before the first acquisition looks like project management, I no longer think of this as a project. As you have pointed out, once an acquisition happens, it behaves like an ongoing project. Every acquisition adds another layer of this, whether the organization is ready for it or not.
My observations show that, overtime, some organizations improve at managing a given complexity. This is not because of a reduction in the complexity, but because the organization has learnt the approaches to navigate through the complexity without a loss of confidence in the data. Their ability to work without losing confidence in the data is demonstrated by the speed at which the reach from, "this doesn't match," to, "this is why it doesn't match" without it dragging into a prolonged debate.
Having gone through it enough times to recognize what you're actually dealing with when the numbers don't line up the way you thought they would is where tools and architecture alone will not get you. It is not a common source to have the ability to operate from this place.