The 100-day data foundation

Where the data foundation sits in most hundred-day plans

Nowhere. Or in phase two, which often amounts to the same thing.

The standard hundred-day plan is a crowded document. Leadership assessment, quick wins, board cadence, the first real cut of the value creation plan, an integration workstream if an add-on is already in flight. Data infrastructure, when it appears at all, appears late: something to sort out once the urgent things are handled.

The order is backwards, and not for technology reasons. Every other workstream in the plan draws on the same underlying asset. Pricing work needs margin at contract or SKU level. Commercial excellence needs pipeline joined to revenue. Add-on integration needs somewhere to put the acquired company's numbers. Reporting to the deal team needs figures that reconcile. Each of those either waits for the data or proceeds on estimates and gets re-done later.

Which raises the question this piece is really about: if it gates that much work, why does it keep landing in phase two? Part of the answer is that until fairly recently, the entire category of technology assessment was treated as optional.

The layer that used to be optional, and the one arriving on top of it

Tech due diligence has been part of the toolkit for years, though it is still not universal. Plenty of firms run it as standard. Plenty of others commission it only when the target is obviously a technology business.

That instinct is defensible. Tech DD earns its fee most clearly on software assets, where the code, the architecture and the engineering team essentially are the product. In a distribution business, a clinic group or a manufacturer, technology is a cost centre rather than a profit centre, and a deep technical review can feel like an expensive answer to a question nobody is asking.

That calculus has been shifting, and a second layer has now arrived on top of the first. At SuperReturn International in Berlin this June, AI ran through the whole conference. EQT's recap put it plainly: AI has moved from experimentation to value creation, and companies are increasingly judged on whether they convert it into growth, productivity and margin. Ropes and Gray, writing up the same event, described diligence itself being reimagined, with value creation planning pulled forward to the very start of the process rather than treated as post-close work. In competitive processes where the winning bid pays full price, conviction in a specific plan is what justifies the number.

There is simple arithmetic underneath this. Bain's 2026 Global Private Equity Report calculates that today's entry multiples require roughly 12% annual EBITDA growth to hit historical return benchmarks, against about 5% in the previous cycle. Multiple expansion is not going to do that work. Operational improvement has to, and in traditional sectors the largest available lever currently runs through data and AI.

So the two layers answer different questions. Tech DD tells you what the company will cost you: technical debt, key-person dependencies, compliance gaps, unbudgeted capex. It is a downside question. An AI-focused assessment tells you what could be built: which processes are manual enough that automation changes their unit economics, where the proprietary data sits, what a redesigned operating model does to margin and how fast. That is an upside question, and it belongs before the price is committed.

Both, though, produce a judgement rather than a working system. Which is exactly the problem waiting on day one.

Diligence produces a picture, not a working system

Diligence gives you a view assembled under time pressure, from a data room curated by the seller, using whatever extracts management could produce during a live process. It is enough to underwrite. It is not enough to operate.

What operating partners need at day one is different in kind: the actual state of the business, from the actual systems, in a form they can trust and re-run next month. Not a snapshot someone assembled for the deal. A baseline.

And the data at hand on day one is usually worse than the diligence pack suggested. It is fragmented across systems that were never designed to talk to each other. Pieces are missing. Numbers that should reconcile do not. Definitions differ by site, by entity, by acquisition vintage, which is why so many initiative reviews stall on the discovery that the same KPI has four values depending on who pulled it.

So the first real job of the hundred days is not analysis. It is assembling something analysis can stand on. That work starts with an unglamorous question: where does the truth actually live?

What the baseline is made of

Usually in four or five systems and a dozen places that are not systems at all.

The CRM, for the sales motion in detail rather than in summary: pipeline by segment, cycle length, win rates, discounting behaviour, concentration risk. The accounting system, for financials at transaction granularity rather than management-report granularity, plus payment behaviour and cash conversion. The ERP, where the business is logistics, distribution or production: stock levels, inventory turns, fill rates, lead times, supplier performance. The service desk, for volumes, resolution times and the complaints that keep recurring, which is usually the cheapest map of operational failure anyone will hand you.

Then the sources that are not systems. Spreadsheets maintained by one person. Reports produced monthly by hand. Manual exports between tools that should have been integrated years ago. In a lot of traditional businesses these carry the numbers the company actually runs on, which means leaving them out produces a baseline management does not recognise.

Getting at all of it is harder than a plan document usually admits. Mainstream software offers a documented API and the job is straightforward. Older on-premise systems may have no usable interface, and the practical route is extraction at the database level, against a schema nobody has documented since the consultant who built it left. Some sources will only ever arrive as file-based feeds. Which method applies is a question to answer per source before committing to a timeline, rather than one to assume.

Access, though, only buys you raw material. Two harder problems sit between a pile of extracted records and a number anyone will act on, and they are the reason this work is not simply an integration project.

Two problems that decide whether any of it is usable

Who is who

The first is entity resolution: knowing that this record and that record are the same customer, the same patient, the same supplier, the same part.

Take a healthcare provider running tens of practices and acquiring local chains around it, a straightforward buy-and-build. The same patient visits two sites. Unless the records are reconciled, that patient exists twice, and so do their tests, procedures and bills. Industry research puts average duplicate rates inside healthcare organisations around 10%, with some running as high as 30%, and AHIMA specifically names M&A data consolidation as one of the causes: the problem gets structurally worse with every bolt-on. Matching across separate organisations is harder still. Work cited by Pew found that even when two organisations run the same EHR vendor, differences in how staff enter data can push match rates toward 50%. The cost surfaces as denied claims, duplicated tests and reconciliation labour.

Resolve the entity and you can lay out one complete treatment history in chronological order with every related service, test and cost attached. Where there were fragments, there is a record. Most companies do not know what this is worth to them, because the gap is invisible: staff stitch the records together by hand, it mostly works, and the omissions never get counted.

Worth being straight about this: cross-source entity resolution is the hardest custom part of any data foundation. Modern models handle it far better than they did two years ago, but it is scoped work with a real success rate rather than a checkbox. Anyone who promises it by default has not looked at your data yet.

What things mean

The second problem is quieter and gets skipped more often. Even with every record correctly matched, the business has no agreed definition of the things being counted. What is a customer: the buying entity, the site, the person on the contract? When does revenue land? What counts as an active account?

Consider a pan-European hardware distributor introducing a new service line, sold on subscription rather than per unit shipped. Within weeks of launch, hundreds of invoices are moving through a billing model the finance stack was never built for: recurring charges, mid-cycle upgrades, proration, partner margins on revenue that arrives monthly instead of on despatch. Somebody has to verify the charges are calculated correctly and collected. Most companies do this by hand and quietly fall behind.

The interesting part is not the invoice checking. It is that "revenue" now means two structurally different things inside one company, and every downstream number inherits the ambiguity. Aggregate the invoices, reconcile them against the other systems, and the errors become visible while they are still cheap to fix. But you cannot even define the check until somebody has decided what the recurring line is called and how it relates to the product line next to it.

That decision layer has a name: the semantic layer. It is the model of the business sitting above the raw tables, holding the objects (customer, contract, site, invoice), how they relate, and one agreed definition per metric. It is what makes a dashboard mean the same thing to two departments, and it is what makes AI answers trustworthy rather than merely fluent. An assistant pointed at raw schemas will write a syntactically perfect query against a semantically wrong understanding of your business and hand you the answer with total confidence.

Both problems share a property worth noticing: they are settled by people who know the business, not by tooling. Which makes the order of the hundred days a judgement call rather than a technical one.

A realistic arc for the first hundred days

Whatever the tooling, the shape of the work is fairly consistent.

• —
  Weeks 1 to 2 - inventory and access audit. Every source that matters, including the human-maintained ones. For each: who owns it, whether access can actually be granted, and by what method the data comes out. This is where hundred-day plans usually break, because the timeline gets committed before anyone confirms the 2009 ERP will let a service account read from it.
• —
  Weeks 3 to 6 - the first sources connected and landing. Typically the four or five that cover most of what was argued about at investment committee. Nothing is elegant yet. The change that matters is that data starts arriving on a schedule rather than on request.
• —
  Weeks 7 to 12 - a governed baseline and the first automated report. The transformation layer, one agreed definition per metric settled with the people who own those metrics, and a report that reaches the deal team without anyone assembling it. That last part is what changes behaviour, because it arrives whether or not somebody had time to prepare it.

One honest caveat, because the timeline is where this kind of writing usually oversells. Reaching a governed baseline inside a quarter assumes you are deploying proven components. Built from scratch, with a team being hired at the same time, this is a six to twelve month exercise, and pretending otherwise is how hundred-day plans lose their credibility in week nine.

There is one variation worth knowing about, where the situation allows it. The conventional order is warehouse first, definitions afterwards. Where the sources can be queried in place and somebody senior enough to settle definitions has real time in month one, it can pay to invert those two: model across the systems where they already sit before moving any data. Provisional answers arrive in days, and each question asked against that model tells you which metrics deserve permanent infrastructure instead of leaving you to guess. If that is worth a longer look, we covered the approach in its own post: Your semantic layer doesn't have to take a quarter. Where the reporting deadline is fixed, or access has to be negotiated system by system, the conventional order is the safer choice.

What matters in either case is smaller than a methodology: the definitions get settled by the people who own the numbers, rather than inferred from the schema by whoever happens to be building the pipeline. Skip that and the decision still gets made, just by default and by the wrong person.

Either route answers the timeline objection. Neither answers the other one.

"It is too early, the ops team is drowning"

This is the reasonable objection, and post-close it is usually true. The management team is absorbing new owners, a new board cadence and a new plan. Asking them to run an infrastructure programme in that window is a good way to see it deprioritised by week three.

The answer is that an overlay approach barely touches them. Read from the systems people already work in and change none of them: no ERP migration, no tool replacement, no retraining, no freeze on operational change. What the portfolio company has to supply is access and a handful of conversations about what the numbers mean. That is hours, not headcount, and the second item is the one that cannot be delegated to a vendor.

There is a fairness point too. The people doing the manual stitching are usually the ones the ops team can least afford to lose to spreadsheet work.

Five questions to ask at day 100

Suppose you accept the argument and start on day one. What should be true a hundred days later, and how would you know? These five tests work on your own team, an internal build, or any vendor including us.

1. 1.
   Can the key numbers be re-run without a person in the middle? If producing the pack still depends on someone's Tuesday, you have a report, not a foundation.
2. 2.
   Does each metric have one definition, and can you name the person who owns it? Unowned definitions drift back into plurality within two quarters.
3. 3.
   Is every figure traceable to a source system? Not "we think it comes from the ERP", but a path someone could follow in a diligence process.
4. 4.
   Does the source register state plainly what is not connected, and what it would take? A foundation with honest gaps is workable. One with unexamined gaps is a liability, because nobody knows which numbers are partial.
5. 5.
   Could the next add-on land on this, or would it start over? In a buy-and-build, this is the question that compounds. The second integration should be faster than the first and the fifth should be routine.

If the answers are yes, the rest of the hold period has something to stand on. If they are no, what you have is a dashboard, and dashboards built on unresolved data are how organisations acquire confident wrong answers.

A note on our own work

This is the sequence we run at Vecten: discovery that verifies extraction feasibility per source before any build commitment, then a governed foundation deployed in the client's own cloud, with the definition work done alongside the people who own the metrics.

The reason it fits a hundred-day window is that the components are already built. That is the whole of the advantage, and it is worth stating plainly rather than dressing up as a methodology.

The first hundred days are usually spent deciding what to change. They are better spent making sure the decision rests on something real.