How to absorb a company's data without breaking the one you already have.
Acquiring a company is one thing. Acquiring its data is another.
You don't just inherit customers, employees, contracts, and revenue. You inherit their EHR. Their billing system. Their spreadsheets. Their dashboards. Their definitions. Their weird quarterly reports. Their three-year-old Python script that apparently nobody owns but absolutely cannot stop running.
And none of it was designed to work with your company.
Why would it be? Their systems were selected for their business. Their metrics were defined for their leadership team. Their reporting evolved around the questions they needed to answer.
Then the acquisition closes, and suddenly the board wants one number. One revenue number. One patient count. One referral conversion rate. One view of the business.
That's where things get interesting. We've worked through this problem with healthcare organizations combining systems, consolidating business units, and trying to build a data foundation that can survive the next acquisition too. Here are a few things we've learned.
The first step isn't choosing Snowflake vs. Databricks or deciding what your enterprise data model should look like. It's reconnaissance.
Get access broadly:
Then start mapping. What comes in? What goes out? What runs every day? What breaks regularly? Who owns it?
And importantly:
Which data flows make money?
This is one of the easiest things to miss in healthcare. Manufacturer data contracts. Partner feeds. Contractual reporting. Files sent to pharma partners. Reports required by lenders, payers, or other counterparties.
On one engagement, we discovered recurring contractual data deliveries that appeared on essentially no centralized inventory. We found them because we kept asking questions and, frankly, pestering people. The people who know those processes exist are often nowhere near the data team.
A broken internal dashboard is annoying. A missed contractual data delivery can cost you money. Know the difference before you start ripping things apart.
It's vocabulary. Ask two acquired healthcare companies what an "active patient" is and you might get three answers. The same goes for:
We've worked with organizations in essentially the same business, serving the same kinds of patients, where basic operational terms meant completely different things. Neither company was necessarily wrong. Their definitions had simply evolved around different workflows.
This is why throwing everything into one lakehouse doesn't magically create a single source of truth. You can centralize two contradictory definitions just as easily as you can centralize two databases.
And acquisitions tend to reveal another uncomfortable truth: the acquiring company may not have had consistent definitions to begin with. Finance has one definition. Operations has another. Sales has a third.
The acquisition didn't create the problem. It just made it impossible to ignore.
If you're going to acquire repeatedly, solve this once
This is where an acquisition strategy becomes a data strategy. Build a canonical model for the concepts your business depends on:
Patient. Provider. Location. Encounter. Referral. Therapy. Payer.
Then create a repeatable input layer for acquisitions. Instead of rebuilding your enterprise model every time you buy a company, each acquired system gets mapped into the model you already have. That's an important distinction.
Your fourth acquisition shouldn't feel like your first. It should mostly be another mapping exercise.
This is probably the lesson we've learned most painfully.
Don't spend six months modeling the entire acquired company before giving leadership anything useful.
We've tried versions of that.
It doesn't work.
Instead, ask:
What question does leadership need answered right now?
Then work backward.
For one provider organization, that question was referral performance.
Which providers are sending us patients?
For which therapies?
How many referrals are converting?
Where are we losing them?
We didn't start by modeling every possible domain in the business. We built what was necessary to answer those questions.
The first version was in Excel.
That's okay.
The goal wasn't to win an architecture award. The goal was to get a correct answer in front of the people running the company.
Once the logic was understood and trusted, we moved it into durable data models and BI.
There are foundational entities you'll almost always need. Provider and location, for example, tend to show up everywhere.
Build those well.
But don't confuse building a foundation with building everything.
Here's a fun way to produce a beautifully engineered, completely wrong dashboard:
Take a classification that changes every quarter and apply today's version to three years of history.
We've done something close to this.
A client maintained an internal list that classified products according to strategic priority. We built historical reporting against it before realizing those classifications were regularly reassigned.
Suddenly last year's numbers were being interpreted using this quarter's business rules.
Not ideal.
The fix was straightforward: preserve the history and model the classifications as a slowly changing dimension.
The rework wasn't.
So whenever you inherit a reference table, ask:
Does this change?
And then:
When it changes, do we keep the old version?
Pay particular attention to things like fee schedules, payer groupings, product classifications, territories, provider rosters, organizational structures, and location mappings.
The dangerous data isn't always the complicated data.
Sometimes it's the spreadsheet somebody updates every quarter.
During an acquisition, the numbers are going to move.
That's normal.
The mistake is allowing executives to discover that on their own.
We've found a few simple practices dramatically improve these projects.
On one engagement, we started running a recorded demo every other Friday.
Here's what shipped.
Here's what works now.
Here's what's next.
Here's why we're doing it in this order.
It completely changed the temperature of the engagement.
Executives had somewhere to ask questions. We got feedback before spending another month building. And stakeholders could actually see progress instead of receiving a status report saying that pipelines were "80% complete."
Create a Slack or Teams channel.
If an executive notices a number that looks strange, they should be able to ask about it.
Fast feedback is particularly valuable during integration because you're constantly discovering business rules that were never documented anywhere.
From the outside, two requests can sound nearly identical:
"Can you add another date to this report?"
"Can you add the newly acquired business to this report?"
One might take an hour. The other might require ingesting another source system, mapping providers and locations, reconciling definitions, validating financial totals, and rebuilding part of the semantic layer.
Show people that.
Most executives are reasonable about complexity when they can see it.
This is the part that matters most.
If you're acquiring one company, you can brute-force your way through a lot.
If you're acquiring two to five companies every year, you can't.
At that point, M&A integration isn't a project.
It's a product.
You need a repeatable way to:
Each acquisition should make that machinery better.
The first one might be painful.
The second should be easier.
By the fifth, you should know what questions to ask before the deal even closes.
That's the difference between a company that happens to have completed several acquisitions and a company that has actually built an acquisition engine.
Data systems are living organisms.
There is no final state where the data platform is "done." New systems arrive. Contracts change. Business definitions evolve. Someone buys another company.
Design accordingly.
And:
Build the foundation now so you can move fast later.
There's a tension in every integration between answering today's urgent question and building infrastructure for the next three years.
You need both.
Move quickly enough that the business gets value now.
Build carefully enough that you don't start over after the next acquisition.
That's the job.
Midwest Data designs, builds, and operates production-grade healthcare data systems for organizations dealing with complex, fragmented data — including multi-site providers, specialty pharmacy and infusion organizations, and value-based care companies.