A merger brings together two general ledgers and two definitions of “customer.” A private equity portfolio multiplies that across every portfolio company. Either way, the messiness is expected. What decides whether the value gets realized is what happens next.
It usually begins well. The team profiles the data – what exists, how complete it is, where the obvious problems are – and comes away with a clear, shared picture of what they are dealing with. That is the right first move.
The trouble is the decision that tends to follow it. Once profiling is done, the instinct in almost every post-merger integration is the same: design the data model, lock it in, then move everything into it. It feels like the disciplined, sequential way to run the program.
After years of this work alongside financial institutions, the acquirers and private equity firms reshaping them, and the consulting teams that advise both sides of a deal, I have come to believe that instinct is backwards. Locking the model in before the data has had a chance to inform it is exactly what makes the model fragile.
Here is what I would want any deal team to hear: when you are consolidating data from multiple systems, treat your first data model as a working draft – something to run against, not something to commit to. The work that happens between that draft and the final model is not a delay. It is what makes the model hold up.
What data profiling shows you, and what it hides
Data profiling reveals a first picture is real, and it is worth having. What it cannot show you is where the real risk lives.
Profiling describes your data at face value, and face value is rarely the whole story. It will not tell you whether the “customer” in one system is the same thing as the “customer” in another. It will not tell you whether two numbers that are supposed to match actually reconcile. And it certainly will not tell you how each system arrived at the figures it shows – the business logic that quietly shapes every number is invisible in a profile. It is part of why data migrations are almost always messier than teams expect.
So if you build a model on the profile alone, you are building on a description of the data, not an understanding of it. The assumptions you could not see become the assumptions baked into the model. And they surface later – when the data sets are combined, during reconciliation, during the first reporting cycle when a number comes out wrong – at the most expensive possible moment to fix them.
The work in between is the model's foundation
The steps between profiling and finalizing the model each answer a question the model depends on. None of them require the model to be locked first. In fact, they are what tell you what the model should ultimately be.
Each of these either confirms an assumption or replaces it with evidence. By the time you have worked through them, the model is no longer a design exercise built on what you hoped was true. It reflects what the data actually is: what entities exist, how they relate, what logic governs them, and where the gaps are. That is a model you only have to build once.
Of those six, business logic is the one deal teams are least equipped to answer – because in an acquired company the logic was written by people who do not work for you, in systems you have never operated. When the acquired estate includes a mainframe or AS/400, that logic sits inside COBOL, RPG, or PL/1 that may not have been documented in decades. Contextual Data Lineage reads that code directly and surfaces the calculations, conditional branches, and dependencies behind each number, so the model reflects how the acquired business actually works rather than how the deal team assumed it did. It is the same gap that causes most mainframe exit projects to fail: code that can be described but not explained.
In private equity, the problem repeats – and compounds
A single acquisition is one version of this problem. A private equity portfolio is the same problem many times over, with a reporting obligation stretched across all of it.
Each platform investment and every add-on arrives with its own chart of accounts, its own customer definitions, its own operational history. The instinct to standardize is right – portfolio-level visibility is the entire point. But a model locked around the first platform company becomes the model every subsequent add-on has to be forced into, and the forcing is where the reporting breaks. What looked like a clean standard turns into a growing pile of exceptions nobody wants to own.
Carve-outs invert the same problem. Instead of combining data that was never designed to be combined, you are separating data that was never designed to come apart – shared reference data, allocations that assume a parent structure, logic that silently depends on entities that will not exist after close. Either way, the working-draft principle matters more in a portfolio than in a single deal, not less: the model has to survive contact with the next acquisition, and the one after that.
How Zengines accelerates post-merger integration work
This is the work our Turnkey Data Migration Platform was built for. It runs the stages above as fast, AI-assisted dry runs rather than manual projects: it profiles and classifies each source automatically, predicts how the fields in one system line up with another, flags the reference-data and quality conflicts that would otherwise surface late, and reconciles the numbers across systems so you can see exactly where they diverge. Much of that work – the mapping, the fixes, the reconciliation – can be driven by a business analyst rather than scarce engineering resources, which matters when a deal team is moving fast. And because the platform keeps active metadata tying every step together, a decision you make in one place stays visible everywhere it matters.
Because each pass takes hours instead of weeks, you can run the work as a series of fast experiments: see what the combined data actually looks like today, test an assumption against it, adjust, and run it again. Every pass teaches you something the model will eventually need to reflect.
Why this matters more in the age of AI
Combining systems used to be about reporting and operational efficiency. Increasingly it is also about whether your data can support what comes next. A combined data set built on assumptions is not just risky for a financial report – it is not a foundation you can trust for AI, or for any other decision system you put on top of it. Data you can explain is data you can rely on. The investigation work is what earns that trust; the model is simply where it gets recorded.
So when the instinct is to lock the model in and march toward it, I would gently push the other way. The fastest path to a model you can trust runs straight through the work everyone is tempted to defer.
Let the data refine the model
If you are leading an integration after an acquisition or across a portfolio – or advising a client through one – the lowest-risk move is not to lock the model in and hope it holds. It is to start running the data through it early and let what you learn refine it. That is exactly what we built Zengines to do. If you would like to see what your combined data actually looks like before you finalize the model, let's talk.
Frequently asked questions
What is post-merger integration?
Post-merger integration is the work of combining two organizations after a deal closes – systems, processes, people, and data – so the combined entity operates as one and delivers the value the deal was built on. The data workstream is usually the longest pole: until the two data sets can be combined and trusted, reporting, system decommissioning, and synergy capture all wait on it.
How do acquirers integrate automation with legacy platforms post-merger?
The obstacle is rarely the automation itself – it is that the acquired platform's business logic is undocumented. Before automating anything against a legacy system, an acquirer needs to know how that system calculates what it calculates. Reading the logic directly out of the code (COBOL, RPG, PL/1) turns an opaque platform into one that automated mapping, transformation, and reconciliation can safely run against.
What is a post-merger integration tool?
In the data workstream, it is a platform that profiles both companies' source systems, predicts how their fields map together, surfaces master-data and quality conflicts, and reconciles the combined numbers – so the integration can be run as fast, repeatable dry runs rather than a single manual project with one chance to get it right.
When should the final data model be locked?
After the investigation work, not before it. Profiling, master-data alignment, reconciliation, schema conformance, and business-logic comparison each replace an assumption in the model with evidence. Locking the model first means those assumptions surface during reconciliation or the first reporting cycle instead – the most expensive moment to change them.