The technology rarely kills a deal. What it does is arrive three months later as a cost nobody put in the model.
IT due diligence establishes what a target actually runs, what it costs to keep running, what it would cost to integrate and what liabilities come with it. The findings that matter are usually licensing, key person dependency, undocumented systems and security debt that has to be paid immediately.
- What existsEstablished rather than described
- What it costsRun rate, plus what was deferred
- Integration costModelled, not estimated afterwards
- Same frameworkSo target and acquirer are comparable
Eight areas, and the last three are where the surprises live.
What actually exists, rather than what is documented
Systems, platforms, cloud environments, applications, devices and the infrastructure underneath. Established from billing, directory, network and identity evidence rather than from a document pack, because the document pack describes the estate as somebody understood it at the point it was written for a different purpose.
The genuine run rate, including what is not in the IT budget
Cloud consumption across every payment route, software subscriptions procured by business functions, support contracts, and anything charged to a card rather than to a cost centre. Shadow spend is normal rather than exceptional, and in smaller targets it is frequently a material proportion of the true technology cost.
Deferred maintenance, which is a liability rather than a finding
Unsupported operating systems, hardware past end of life, software versions no longer receiving updates, and certificates or contracts expiring shortly after completion. These are not opinions about quality. They are dated obligations that transfer with the business, and they belong in the model rather than in a risk register.
Licensing and entitlement exposure
What the target is entitled to, what it has assigned, and what it has configured. Capabilities in use whose entitlement was assumed rather than verified transfer to the acquirer along with everything else, and they surface at the first true-up rather than during the transaction unless somebody looks for them deliberately.
Key person dependency, which is the most common real finding
How much of the environment only one person understands, whether anything is documented well enough for somebody else to operate, and whether that person is staying. In smaller targets this is frequently the single largest integration risk, and it is invisible in any document pack because the knowledge is precisely what was never written down.
Contracts, terms and what does not transfer
Support agreements, cloud commitments, software terms and managed service arrangements, specifically what happens to each on a change of control. Some transfer, some require consent, some reprice and some terminate. That distinction is a commercial question that IT can identify and that legal and finance then have to decide on.
The integration path, costed rather than assumed
Whether the identity estates can be merged or must coexist, whether devices can be re-enrolled in place, and what each option costs. Microsoft describes multitenant organisation capability for organisations with more than one Entra instance, and cross-tenant synchronisation as a one-way service letting users reach resources without an invitation or consent prompt in each tenant.
Security position, assessed on evidence rather than assertion
Against the same eighteen controls used for the acquiring organisation, so the two can be compared directly. The purpose is not to grade the target but to establish what has to be remediated before the environments are connected, because connecting first and assessing afterwards inherits every weakness immediately.
Whether devices can be re-enrolled in place, or have to be wiped, is a cost line in the integration model.
It looks like a technical detail during diligence and behaves like a project during integration, and it is entirely knowable in advance.
- Microsoft publishes the factory reset requirement per enrolment method. Reset required for iOS and iPadOS, macOS, and three of the Android Enterprise corporate modes. Not required for Windows, Linux, Android Enterprise personally owned devices with a work profile, and Android device administrator.
- So a target with a fleet of Macs and iPhones, moving to the acquirer management platform, is a wipe and rebuild exercise per device with data migration, user communication and a support surge attached. A target running Windows is not.
- Microsoft also notes that devices enrolled with another management provider must be unenrolled from it first, and that unenrolling typically does not remove the features and settings that were configured. Residual configuration therefore persists on the platforms that are not wiped, which is a different problem in the same area.
- None of this is difficult to establish during diligence. All of it is expensive to discover during integration, and the difference between the two is a line in a model rather than a surprise in month three.
Four things a technology diligence should produce and often does not.
We establish the estate from evidence, not from the pack
Billing routes, directory and identity records, network evidence and external discovery. A document pack describes the estate as somebody understood it when writing for a different purpose. Evidence describes it as it is, and the gap between the two is consistently the first substantive finding in a mid-market target.
We produce a number, in the form the model needs
Run rate including spend outside the IT budget, deferred maintenance as dated obligations rather than as observations, and integration cost by option. A diligence report that describes risk without costing it leaves the transaction team to translate, and the translation is where the estimate becomes optimistic.
We assess key person dependency explicitly
How much of the environment exists only in one person head, whether the documentation would let anybody else operate it, and whether that person is staying. In smaller UAE targets this is frequently the largest single integration risk, and it is the one that converts a technical finding into a deal term.
We produce a day one plan, not only a report
What must be true at completion, what can wait, what has to be remediated before the environments are connected, and what the integration options cost. That is the artefact that gets used after signing, and it is the difference between a report that informed the price and one that also informs the first hundred days.
Six transaction situations where technology diligence changes the outcome.
A group acquiring a smaller UAE business
The most common case. The target runs a small estate competently, largely through one or two people, with documentation that describes intentions rather than reality. The findings that matter are key person dependency, technology spend outside the IT budget, and the integration cost of a device fleet that may need rebuilding.
A buyer acquiring a business with client data obligations
Where the target holds client or personal data under contractual or regulatory obligations, those obligations transfer. Establishing what data exists, where, who can reach it and whether any exposure is already present is materially cheaper before completion than as an inherited problem afterwards.
An investor assessing technology as part of a wider review
Where technology is one workstream among several, the useful output is a small number of quantified findings in the form the model uses, rather than a comprehensive technical description. Run rate, deferred obligations, integration cost and the two or three risks that would change the plan.
An acquisition where operational technology is in scope
Plants, facilities and production environments carry technology with longer lifecycles, tighter change constraints and frequently no documentation at all. Assessing it needs a different approach from corporate IT, and its deferred maintenance is usually both more expensive and more consequential.
A carve-out where systems must be separated rather than merged
The harder version of the problem. What the carved-out entity depends on from the parent, what transitional service arrangements are required, how long they run and what standing the entity up independently costs. Diligence here is as much about separation cost as about the estate itself.
A post-completion review where diligence was not done
Entirely recoverable and worth doing quickly. The same assessment run after completion produces the same findings, with the difference that the price is fixed and the findings become an integration budget question rather than a valuation one. Doing it in the first quarter is considerably better than in the first year.
How UAE acquirers handle technology in a transaction.
| Feature | Assessed on evidence | Reviewed from the document pack | Technology not assessed |
|---|---|---|---|
Estate established from evidence | Yes | From documents | No |
True run rate known | Yes | The stated figure | No |
Deferred maintenance quantified | Yes | Partly | No |
Licensing exposure identified | Yes | Rarely | No |
Key person dependency assessed | Yes | No | No |
Change of control terms flagged | Yes | Sometimes | No |
Integration cost modelled | Yes | Estimated after | Discovered |
Security compared on the same framework | Yes | No | No |
Day one plan exists at completion | Yes | No | No |
Surprises in month three | Few | Several | Many |
Ten findings, and what each one means commercially.
| Finding | What it means commercially | |
|---|---|---|
| Systems not in the document pack | The estate is larger than modelled, and so is the run rate | |
| Technology spend outside the IT budget | True cost is higher than the figure provided | |
| Unsupported platforms in production | A dated remediation obligation transferring with the business | |
| Entitlement that cannot be evidenced | A cost that appears at the first true-up after completion | |
| Key person dependency | Retention becomes a deal term rather than an HR matter | |
| Contracts affected by change of control | Consent, repricing or termination, each with a value | |
| Apple or Android device estate | Wipe and rebuild per device during integration | |
| Residual configuration after unenrolment | Cleanup effort on the platforms that are not wiped | |
| Security gaps against the same control set | Remediation that must precede connecting the environments | |
| Undocumented integrations and interfaces | The most common cause of an integration overrunning |
Five steps, compressed to whatever the transaction timetable allows.
- 1
Agree what the transaction actually needs to know
A valuation input, an integration plan, a risk view for the board, or all three. That determines depth and emphasis. A review scoped as a general technology assessment produces a comprehensive document, and a review scoped around three specific questions produces answers the deal team can act on.
- 2
Establish the estate from evidence, fast
Billing routes, directory and identity, network, external discovery and whatever management platforms exist, alongside the document pack rather than through it. The gap between the two is recorded explicitly, because how large that gap is tells you as much about the target as its contents do.
- 3
Quantify cost, obligation and exposure
Run rate including technology spend outside the IT budget, deferred maintenance expressed as dated obligations, licensing and entitlement exposure, contracts affected by change of control, and any security or data protection exposure that transfers with the business.
- 4
Model the integration options
Whether identity estates merge, coexist or synchronise, whether devices re-enrol in place or require a rebuild given the published requirements per platform, what residual configuration persists after unenrolment from another management provider, and what each option costs in effort and elapsed time.
- 5
Deliver findings and a day one plan
A short set of quantified findings in the form the transaction model uses, plus what must be true at completion, what must be remediated before environments are connected, and the sequenced integration plan. Written so it remains useful after signing rather than only before it.
What acquirers ask about IT due diligence.
Fifteen items, and the gaps in the answers are themselves findings.
The estate
- An asset and application inventoryIts accuracy is a finding in itself.
- Cloud environments and who pays for themBilling finds what registers miss.
- Identity platform and directory structureIt determines the integration path.
- Device fleet by platformIt determines the re-enrolment cost.
- Network and connectivity arrangementsIncluding anything site-specific.
Commercial
- Total technology spend, all routesNot only the IT cost centre.
- Contract list with terms and end datesAnd change of control provisions.
- Licence agreements and entitlementsAgainst what is configured.
- Managed service arrangementsAnd what they actually cover.
- Committed cloud spendCommitments transfer.
People and risk
- Who runs what, by nameKey person dependency is the usual finding.
- What documentation existsAnd when it was last accurate.
- Recent incidents and their handlingBoth the events and the response.
- Outstanding audit or regulatory findingsThey transfer.
- Any known data protection exposureIt becomes yours on completion.
Ask what proportion of the target device fleet is Apple. That answer has a number attached.
Apple platforms require a factory reset to move to a new management platform. Windows does not. It is one question, it takes a minute, and it is the difference between an integration line item and an integration project.
Related Services
Explore more solutions that work great with this service
IT Audit Services Dubai
Assessment, technical test or certification, scoped properly
CIS Controls Assessment
Eighteen controls, assessed and re-assessed
Third Party Risk Audit
Who can actually reach your systems, and what to do about it
IT Consulting
Strategy, M&A IT due diligence, cloud, compliance advisory
Microsoft Licence Audit
Assigned, used and entitled, compared properly
Technology Roadmap
12 to 36 month IT plan, board-ready
IT Risk Assessment
A short register with an owner against every risk
Cloud Security Posture Audit
The real inventory, then configuration and identity