No IT Department? How to Map an Acquired Company in 5 Days

You have closed on a company with fewer than fifty people. The first operational walkthrough turns up no chief information officer (CIO), no IT manager, no documentation owner — just an external break-fix supplier who resets passwords, and one person who knows how the business actually runs. The operating system of the company you just bought is that person's head and a folder of Excel files.

Mapping it is not an inventory exercise. The systems are the easy part. It is a knowledge-capture exercise, and it can be done in five working days if you go after the exceptions rather than the org chart.

What the post-merger IT guides map, and what they leave out

Almost every guide that ranks for post-merger IT integration maps assets: endpoints, software-as-a-service tenants, privileged accounts, licence counts, email and domain cutover, and the scope of the transition services agreement (TSA — the contract under which the seller keeps running certain functions for a fixed period after close). That is the correct checklist when the target has an IT function to hand over. It is close to useless when the target has none, because at this size the asset inventory closes in an afternoon and answers nothing you needed to know.

Due diligence (DD — the pre-signing examination of the target) told you what the company earns. The asset inventory tells you what it runs on. Neither tells you how it runs: why the person in customer service opens a spreadsheet before confirming an order, which customers are priced differently for reasons nobody wrote down, or what happens when a supplier ships a partial delivery. That knowledge is not in a system. It is in one person's head, and it is a material part of what you bought.

Your deadline is in the deal documents, not in a behavioural pattern

You do not have to guess when the knowledge leaves. Read the agreement you signed. Earn-out periods, post-closing consultancy arrangements and transition agreements all carry end dates, and those dates are the outer limit of your access to the undocumented. Every buyer knows their own date. Very few treat it as a project deadline.

Cristian Iosio, Head of Business Development and M&A at Gruppo Coesia, put the risk plainly at CUOA Finance Day 2026: after closing, “il rischio di perdita di competenze rilevanti è elevato” — the risk of losing relevant competence is high. He attaches no timeline to it, and neither should you. Your contract already supplies one.

The second constraint is capacity. “Lack of dedicated resource to drive the integration programme” was the top implementation risk in AlixPartners' 2025 EMEA post-merger integration survey, selected by 65% of respondents, ahead of communication (46%), leadership engagement (41%), governance (35%) and retention (29%). In a small-target deal that resource problem has a very specific shape: the only person who could write the process down is the person currently running it, and integration is their fourth priority behind shipping, invoicing and customers.

Why there is nothing to inherit: Eurostat and Politecnico di Milano

At this size, the absence of documentation is the norm rather than negligence. It is a structural feature of small European companies, and the statistics are unambiguous enough that you should plan for it before the first walkthrough rather than discover it during.

Eurostat's 2025 figures on the integration of internal processes put ERP software use at 41% among enterprises with 10 to 49 employees, and 69.9% among those with 50 to 249. Roughly three in ten mid-sized European firms therefore run without an ERP at all, and only 53% of EU enterprises use any specialised e-business software. Where there is no system of record, there is no process to read out of one.

Staffing tells the same story. Eurostat's 2024 data shows ICT specialists employed by 14.04% of small enterprises against 78.44% of large ones. The Politecnico di Milano's Osservatorio Innovazione Digitale nelle PMI (small and medium enterprises), in its 2025-26 edition, found that one company in three still has no IT lead at all — internal or external — that 59% report a shortage of specialists, and that only 19% adopt advanced digital solutions in a structured way.

And small does not mean simple. The Secret CFO, writing a first-person account of his own acquisition of a business with roughly $1.5m in revenue, found pricing and customer administration running on “a horrible network of 20-year-old Excel files and manual pricing cards”. Flattening it took two virtual assistants nearly three months. His conclusion — “small doesn't mean simple” — is the right expectation to bring to day one.

Step one: the Exception Ledger

Do not map the documented process. Map the deviations from it. The Exception Ledger is a single table, built by sitting with the people who run a workflow and logging every real departure from the official path, how often it happens, and who absorbs it today. It is the fastest route to the knowledge that is actually at risk, because the exceptions are precisely the part nobody ever wrote down.

The scale of that gap is measurable. Research published as arXiv preprint 2107.13066 documented a single multinational generating more than 900,000 distinct process variants in one year across more than 60 activities. That is what “we have a documented process” looks like when you measure execution instead of intent — measured from that company’s own event logs. A fifty-person target will rarely have any of that.

The entries are mundane and always specific: someone re-keys orders by hand every week because two systems disagree on a product code; a discount is applied manually because it was agreed on a phone call years ago; a delivery note is reconciled against a paper file. Each line is a candidate for automation, a training gap, or a liability you have just acquired. You will not get them from an interview about “the process”. You get them by watching the work and asking what happened the last time it went wrong.

Step two: the AI Boundary Map

For every step in the ledger, classify it as one of three things — a model, deterministic code, or a human — and write the reason next to it. This is the single document that stops an integration programme from buying an artificial intelligence platform for a problem that was a lookup table.

In one SUPALABS engagement covering a European manufacturer's order-handling workflow, three of eleven steps genuinely needed a model. That is one engagement, not a benchmark, and it should not be read as a ratio that holds everywhere. It is worth stating because it is the opposite of what a platform sale assumes.

Step three: the covenant not to touch the gestionale

You map and automate on top of the existing systems, through their application programming interfaces (APIs). You do not replace the ERP, the gestionale (the Italian term for the management system a company runs its operations on), or the vertical tool the business has used for a decade. Nobody sanely migrates an ERP in the first hundred days after close.

The reason is scheduling, not sentiment. An ERP migration is the single riskiest project available to an integration team, it runs in quarters rather than weeks, and the people who would have to drive it are the same people whose availability is capped by the deal documents. Put it on the critical path and you convert a knowledge-capture problem into a systems programme — and the knowledge walks out while you are still in requirements. Build additively and the mapping work survives whatever you decide about systems in year two.

The five-day agenda you can hand to your integration lead

Five working days is enough because you are not building a model of the whole company. You are capturing what one or two people know. Depth of observation is what makes the week work: it is spent alongside the people doing the work, not in a data room reading policies that describe a company that does not exist.

Day five is the test that matters. If the person who runs the business reads the ledger back and corrects nothing, the ledger is wrong. Corrections on the final day are the deliverable, not a setback.

If the acquired business already has an external IT supplier

A managed service provider (MSP) will handle the asset side competently and will not touch the process side — not because they are bad at it, but because it is not in their contract. Knowing exactly where that line falls stops you paying twice for one half and nothing for the other.

What the Big Four will propose here, and why it does not fit

The large consultancies will bring four workstreams: assess AI maturity, prioritise use cases by return on investment (ROI), deploy on a governed hyperscaler platform, then upskill staff and stand up a centre of excellence (CoE). Every one of those workstreams is competently run by people who know what they are doing. The problem is that they are the same four workstreams the last three acquirers bought.

A framework identical across every client cannot tell you what is different about the business you just bought — and difference is the entire reason you paid what you paid. The unique part of a fifty-person target is not its maturity score. It is the handful of undocumented exceptions that let it hold a customer relationship a larger competitor cannot.

The stakes are not theoretical. EY's analysis of 236 deals of US$500m or more between 2010 and 2023 found median integration costs of 3.5% to 10.1% of target revenue depending on sector. And the reporting gap that follows is documented: in research by Accordion with Wakefield Research covering 100 private equity seniors and 100 portfolio-company chief financial officers, 92% of sponsors believed their reporting demands were reasonable, while 26% of the CFOs agreed. That gap is not an attitude problem. It is what happens when reporting is demanded of processes nobody has written down.

What happens after the five days

The mapping sprint produces the ledger, the boundary map and a prioritised shortlist. From there the work is roughly a six-week build on top of the systems already in place, covering the two or three exceptions that cost the most and are safest to automate, with an evaluation suite behind it: a golden dataset, per-step pass rates and a monthly accuracy report. Every automated action is written to a decision log with its inputs, its confidence and its approver, so an integration lead can answer “why did it do that” in front of a board rather than in front of a vendor.

It starts with a free 30-minute qualification call; everything after that is quoted per engagement. You can see how the sprint and the build fit together on the embedded operators page, what the engagement patterns look like in our work, and how engagements are structured on pricing.

Frequently asked questions

How do you document a company's processes when nobody has written anything down?

You do not interview people about the process — you watch the work and log the exceptions. Sit with the two or three people who actually run a workflow and record every real departure from the official path: what triggers it, how often it happens, who absorbs it today, and what it costs when it goes wrong. The exceptions are the part that was never documented, which makes them both the knowledge most at risk and the shortest route to understanding how the business really operates.

Can we map and automate operations without touching the acquired company's ERP?

Yes, and in the first hundred days after close that is the only sensible approach. The work is built on top of the existing systems through their APIs: the ERP, the vertical tool and the spreadsheets all stay where they are. An ERP migration is the riskiest project available to an integration team, it takes quarters rather than weeks, and the people who would have to run it are the same people whose availability is capped by the deal documents.

How long does it take to map operations after an acquisition?

Five working days is enough for one core workflow in a company of this size, because the goal is not a complete model of the business — it is capturing what only one or two people know. The week produces an exception ledger, a per-step decision on what should be a model, deterministic code or a human, and a prioritised shortlist of what to automate first.

The acquired company already has an external IT supplier. Isn't this their job?

A managed service provider covers the asset side well — devices, backups, licences, access, email and domain cutover — and does not touch the process side, because it is not in their contract. They can tell you which systems exist and who has access. They cannot tell you why a customer is priced differently, which orders get re-keyed by hand, or what one person does when a supplier ships a partial delivery.

How much of an acquired company's process should actually be automated with AI?

Far less than a platform vendor will tell you. In one SUPALABS engagement covering a European manufacturer's order-handling workflow, three of eleven steps genuinely needed a model; the rest were better served by deterministic code or by leaving a person in place. That is a single engagement rather than a benchmark, but the discipline generalises: classify every step as model, code or human, and write the reason, before anyone signs a platform contract.

What do we actually get at the end of the five days?

Three artefacts: an exception ledger listing every real deviation from the documented process with its frequency and who absorbs it, an AI boundary map classifying each step as model, deterministic code or human with the reasoning attached, and a prioritised shortlist of what to build first. They are written to be handed to an integration lead and read by someone who was not in the room.

Sources & References