IT due diligence on a small acquisition: what to check before completion, and the first 90 days after

Background

Most IT due diligence advice is written for big deals with a data room and a team of advisers. Buying a clinic or a ten-person business is different. There's no data room. Whoever set up the IT may have left years ago, and the real answers are in a password spreadsheet and somebody's memory.

Acquisitions are part of my job as Head of IT at a healthcare group, from the buyer's side: the checks before completion, then bringing the people, data and systems across afterwards. The second half is why the first half matters. Anything you don't find before completion, you find during the integration, when it's yours and the clock is running.

This guide is the order I'd do it in. It assumes the business runs on Microsoft 365, because most small ones do, but most of it applies whatever they use.

Setup

Before completion: who controls what

Start with control, because everything else depends on it. If you can't prove who controls the domain and the tenant, you can't plan anything else.

• The domain and DNS. Which registrar, whose account, whose email address gets the renewal notices, when it renews. A domain registered to a former employee's personal account is common and fixable, but only before it lapses.
• The Microsoft 365 tenant. Who the Global Administrators are, and whether each one is a named, current person. Then ask the question in the one question that exposes an acquisition's real IT risk: everyone with admin rights, and why.
• Billing. Whose card or account pays for Microsoft 365 and every other subscription. If the card belongs to the seller personally, it stops the day they stop caring.

Before completion: licences, contracts and data

• Licences. What's assigned, what's paid for and unused, and when each subscription renews.
• Contracts that can't move. Software licensed to the seller's company name, contracts with change-of-control clauses, and anything that auto-renews for another year during your integration window.
• Where the data lives. Not where it's meant to live: where it is. Shared mailboxes, OneDrive folders of former staff, a practice system hosted by a supplier, a NAS in a cupboard, exports on someone's laptop.
• Security basics. MFA on every account, backups that have been restored at least once, devices nobody manages, and accounts for people who've left.
• For a healthcare provider: the DSPT. Its current status, the date of the last submission and any improvement plan. A business that's behind on it brings that work with it. The DSPT guide covers what's involved.

A prompt for turning what the seller sends into a gap list. Before you paste anything, take out names, patient details and the commercially sensitive bits, unless the AI tool is one your organisation has approved for confidential documents.

Below are the IT details a business we're acquiring has sent us, with
names removed. Compare them against this checklist:
- domain registrar and owner, DNS host
- Microsoft 365 admins, each named and current
- who pays for each subscription
- licences: assigned, unused, renewal dates
- contracts with change-of-control or auto-renewal terms
- every place personal data is stored
- MFA coverage, last tested backup restore, unmanaged devices
- data protection or DSPT status
For each item say: ANSWERED (quote where), PARTLY (what's missing) or
NOT ANSWERED. Don't assume anything that isn't stated.

[PASTE SELLER'S RESPONSES]

The output is a list of questions to send back, not a conclusion.

Day one

The aim on day one is control and continuity. Nobody should notice anything except new people being able to help them.

• Take control of admin access. Your own named admin accounts in their tenant, the seller's old admin accounts disabled or handed over, break-glass credentials changed and stored somewhere only named people can reach.
• Turn on MFA everywhere it's missing, warning staff first so it isn't a surprise on their phones.
• Change ownership of the domain and billing to accounts you control.
• Signatures and branding. Staff email is often the first place the new ownership shows. If it's being rebranded, give people a new template to fill in rather than asking them to copy someone else's. (That's the job my own Signature Tool, in beta, does: staff pick a template and add their details.)

Week one

• A site register. Each location, its devices, network, contracts and suppliers, in one place. I'm building Estate (in beta) for exactly this: it follows each site from acquisition to closure, with its contracts, assets, documents and compliance records attached.
• Meet the people who know how things work. The receptionist who knows which PC runs the card machine is worth more than any document.
• Fix anything you found that's dangerous now: former staff with access, shared admin logins, missing backups.

The first 90 days

Plan the integration as a project with owners and dates. A shared plan where tasks move on without someone chasing them is half the job. Any task tool with notifications works; Planner, in beta, is my own.

The big decision is whether the business joins your Microsoft 365 tenant or stays separate for now.

• Joining your tenant means moving mailboxes and OneDrive across. Microsoft's own cross-tenant mailbox migration does this, and needs a Cross Tenant User Data Migration licence for each person moved; the same licence covers cross-tenant OneDrive migration.
• Mail cutover is the moment people notice. Lower DNS time-to-live values a few days before, move the domain at a quiet time, and test sending and receiving from outside before telling anyone it's done.
• Identity. Decide which tenant each person signs in to, and when. Changing someone's sign-in twice in a quarter is how you lose their goodwill.
• Switch things off last. Keep the old tenant and subscriptions until you've confirmed nothing still depends on them, then cancel in an order that doesn't leave data stranded.