Five years ago, we saw technological due diligence in an industrial merger as a checklist exercise: licence counts, software versions, server status. Validate the infrastructure and move on. Today we know that was validating the skeleton and ignoring the nervous system. The uncomfortable truth is that most mergers fail not because the software was bad, but because no one asked whether the software was capable of supporting the real operation of the company being bought.

The mistake everyone makes: confusing what is written with what works

We walked into a textile factory in the Vale do Ave in June 2023. Merger approved, systems integration scheduled for August. On paper, both companies used "modern" ERPs. In reality, one of them had 47 undocumented customisations accumulated over 12 years — processes no vendor had any record of, routines a retired employee kept in his head, reports that only worked on Tuesdays because an Excel macro triggered an overnight job.

No auditor had seen this. The consultants who did the initial technical due diligence had requested access to the production environments, received credentials from an IT manager, run a vulnerability scan and left. What they did not do: sit down with the warehouse manager, the planning lead and the shift supervisor to understand what the ERP actually did.

A technological due diligence that does not validate the gap between the documented process and the process the factory uses every day is a due diligence that saw nothing.

The first step is to validate the operation, not just the software. Sit down with the end users — not with the IT managers — and ask them to describe a complete work cycle: from receiving an order to sending the debit note. Where does the ERP intervene? Where do they step out of IT and into Excel, paper or parallel systems? Each interruption is an operational risk the merger will inherit.

Data integration: the invisible cost no one budgets for

When two different ERPs coexist within the same company — something that happens in 70% of Portuguese industrial mergers within the first 12 months — data integration is not an IT problem. It is a business problem that IT has to solve.

Imagine a distribution company that buys a competitor. The acquired company uses QAD Adaptive, the acquirer uses a generic ERP. Both have tables for items, customers, suppliers. They look the same. They are not. One item code is numeric with 10 digits; the other is alphanumeric with 12. One has a "category" field the other does not. One syncs prices in real time; the other updates daily. In a rapid integration scenario, this is not addressed — a "good enough" mapping is created and everyone hopes it works. Three months later, the warehouse is full of picking errors because the item code was translated incorrectly, sale prices are wrong for 2,000 SKUs, and the sales force is receiving incorrect commissions.

In due diligence, this means requesting a data report — not a diagram. How many items does the acquired company have? How many categories? What is the daily volume of stock movements? What is the data integrity: how many orphan records, how many empty fields, how many duplicates? This is not a question you ask a CIO — it is a question you ask the operations lead, with subsequent technical verification.

Security and compliance: what you inherit and what stays exposed

The Decree-Law No. 65/2025 transposed the NIS2 Directive in Portugal, extending cybersecurity obligations to medium and large companies across 18 critical sectors, including manufacturing. A merger does not suspend those obligations — it multiplies them. Suddenly you have two network perimeters, two sets of controls, potentially two levels of maturity.

The risk is direct: the acquired company had 60% cybersecurity maturity; the acquirer had 85%. After the merger, if you do not integrate the policies and controls, you are left with a hybrid perimeter where the worst level contaminates the best. A server on the acquired side that has been unpatched for 8 months is an entry point into the acquirer's network. In 2024, CERT.PT recorded 2,758 cybersecurity incidents in Portugal, a 36% increase over 2023, with around 78% occurring in private entities — and SMEs are the disproportionate target, present in 88% of the data breaches analysed.

In due diligence, this means requesting a security posture report. ISO 27001 certifications? Recent audits? What is the state of patch management? What is the level of logging and monitoring? Does the company have a contracted cybersecurity service or does it depend on internal IT? This is not paranoia — it is a regulatory obligation. And a failure here is not a 6-month integration problem; it is a permanent operational risk that Portuguese and European regulation will scrutinise.

The hidden cost: the team that will do the integration does not exist

Here is the reason why most systems integrations in Portuguese industrial mergers fail or slip by 6-12 months. Technical due diligence validates the software. But no one asks: who is going to implement the integration? And with what resources?

A typical industrial SME has one IT manager and perhaps two technicians. A merger requires, over 6-9 months, dedicating 1-2 FTE (full-time equivalents) to the integration alone. That means the IT manager will be away from day-to-day operations. Who puts out the fires? Who supports users when the system slows down at month-end? The answer is: no one, or the user is left waiting while the warehouse supervisor phones the office to say that picking has stopped.

In due diligence, this means drawing up a concrete resource plan. How many person-days will the integration cost? Who will do it — the IT manager, an external consultant, a combination? If it is contracted externally, what is the real cost (not the initial proposal, but the real cost after scope changes)? If it is internal, what is the impact on current operations? And — this is critical — what is the risk that the project slips because the internal team was diverted to put out operational fires?

A systems integration without a resource plan is an integration destined to fail.

What to validate: a practical roadmap

So, what should be on a real technological due diligence checklist?

  • Process mapping. Sit down with the end users. Ask them to describe a complete work cycle. Where does ERP MULTI or the system in question step out of the game? Every exit is a risk.
  • Data audit. How many records? What is the integrity? How many duplicates, orphans, empty fields? This determines the real integration effort.
  • Security posture. Certifications? Patch status? Logging? Monitoring? This is not optional — it is a regulatory obligation under DL 65/2025.
  • Resource plan. How many person-days? Who does it? What is the impact on operations? This determines the real timeline, not the timeline written in a proposal.
  • Technical documentation. Customisations? Parallel integrations? Macros? Routines that "no one knows how they work"? This is the hidden risk that will surface six months later.

And there is one last thing no one validates: organisational culture. But that is another article — read here how the ERP does not solve the culture.

What we have seen over 35 years is that the mergers that work are not the ones that had the best software. They are the ones that asked hard questions early, found honest answers, and budgeted for the real cost of integration — not the cost written in a consulting proposal or a sales slide-deck.

Frequently asked questions

What is technological due diligence in an industrial merger?

It is the technical validation of a company before acquisition. It goes beyond counting licences and checking servers — it should assess whether the software actually works in day-to-day operations, identify undocumented customisations, data integration gaps and security risks that the acquiring company will inherit after the merger.

What is the most common mistake in technological due diligence?

Confusing what is documented with what works in practice. Many auditors run vulnerability scans and leave, without talking to end users about real processes. A factory may have a "modern" ERP on paper, but use 47 undocumented customisations, parallel Excel and routines only one employee knows.

How do you validate the real operation during due diligence?

Sit down with end users — warehouse managers, planning leads, shift supervisors — and ask them to describe a complete work cycle, from receiving an order to sending the debit note. Identify where they step out of the system into Excel, paper or parallel systems. Each interruption is an operational risk the merger will inherit.

What is the invisible cost of data integration in mergers?

When two different ERPs coexist, the data looks compatible but is not. Item codes may have different formats, fields may be empty, categories may not match. Without proper handling, this causes picking errors, incorrect prices and wrong commissions three months after the merger.

What should you ask about data in due diligence?

Request a concrete data report: how many items, how many categories, daily volume of stock movements, data integrity (orphan records, empty fields, duplicates). This question should be put to the operations lead with subsequent technical verification, not to the CIO.

How does NIS2 affect technological due diligence in mergers?

Decree-Law No. 65/2025 extended cybersecurity obligations to medium and large companies across 18 critical sectors, including manufacturing. A merger multiplies these risks: two network perimeters, two levels of maturity. If you do not integrate controls, the worst level contaminates the best and creates entry points into the acquirer's network.

What is the hidden cost no one budgets for in an integration?

The team that will do the integration. A typical industrial SME has one IT manager and two technicians. A merger requires 1-2 FTE dedicated for 6-9 months to the integration alone. This means day-to-day support is left unprotected. In due diligence, a concrete resource plan should be drawn up and the real cost of external integration calculated, if needed.