IT Integration After an Acquisition: What to Do in the First Ninety Days

The deal closes and IT is handed a new organisation to absorb. The instinct is to start with the visible things — one email domain, one directory, one set of tools — because those are what people ask about.

That order is wrong. On day one you have acquired an environment you do not understand, with administrative access held by people whose status may have changed, and connectivity requirements nobody has documented. Security exposure comes first, discovery second, and identity when you understand both.

Days 1–7: contain the exposure

Inventory privileged access immediately. Who holds administrator rights in the acquired environment, including former staff, the outgoing IT provider, and the previous owner. Change what needs changing, and document who legitimately retains access during transition.

Confirm who holds the keys to the externals. Domain registrar, DNS, certificate authority, the cloud tenant, the backup platform. Transferring domain control is routinely forgotten until a certificate expires and nobody can renew it.

Verify backups exist and restore. You have assumed responsibility for data you have never protected. Confirm it is being backed up and that a restore actually works — before you change anything.

Establish incident contacts on both sides. If something happens in week two, people need to know who to call.

Check for known-bad obvious things. Internet-facing RDP, unsupported operating systems, expired endpoint protection, shared administrator passwords. These are common in smaller acquired businesses and each is urgent.

Days 7–30: understand what you bought

Resist integrating until you have the picture.

• Applications, and which are business-critical. Interview the people who use them rather than reading an asset list
• Contracts and renewal dates. Telecoms, software, support, leases. A renewal that auto-renews during integration can lock you into something you were about to replace
• Data: where it is, what it is, and what obligations attach. Customer data, employee data, anything regulated
• The integrations. What talks to what. This is where unplanned breakage comes from
• The people. Who kept it running, and are they staying? The acquired organisation's informal knowledge is usually concentrated in one or two people, and they are also the most likely to leave

Write down what you must not break. Every business has a handful of processes that have to keep working through any change — invoicing, dispatch, clinical systems, payroll. Name them explicitly, and make them constraints on the plan rather than things you discover.

Days 30–90: integrate in the right order

Identity first, but carefully

Identity is the foundation for everything else, which is why it goes early — but it is also the most disruptive thing to get wrong.

Common approaches: migrate the acquired organisation into the acquirer's tenant; establish trust between the two and migrate gradually; or leave them separate and federate. The right answer depends on size, timeline and whether the acquired business will retain its brand.

Gradual is usually right for anything but the smallest acquisition. A big-bang identity migration concentrates all the risk on one weekend.

Email, after identity

Email migration is visible, emotive and well-trodden. The specifics that matter:

• Decide the domain strategy early — keep both, or retire one. Retiring a domain affects customer communications far beyond email
• Keep the old domain receiving mail indefinitely. Customers use addresses from years ago
• Shared mailboxes, distribution lists and the aliases nobody documented are where migrations fail
• Signatures, disclaimers and mail flow rules need recreating deliberately

Networking, when there is a reason

Connect sites only when something requires it. A connection between two previously separate networks also connects two previously separate security postures — and you have likely just inherited the weaker one.

Segment the acquired network until you have brought it to your standard.

Endpoints and tooling, steadily

Bring devices under management, deploy your endpoint protection, standardise the build at natural refresh points. There is rarely a reason to replace working hardware on day thirty.

The decisions that are worth making explicitly

Whose standard wins? Often the acquirer's, but not always — sometimes the acquired business does something better. Decide deliberately and say why, because the acquired team will read an automatic default as a judgement about them.

What stays separate, permanently? Not everything should merge. A business with different regulatory obligations, a different customer base or a distinct brand may legitimately keep separate systems.

What is the end state, and when? Integration without a defined end drifts for years, running two of everything at double the cost.

The part that is not technical

The acquired organisation's IT staff are integrating themselves and their work simultaneously, under uncertainty about whether they still have jobs. They also hold all the knowledge you need.

Tell them where they stand as early as you honestly can. The practical consequence of leaving it ambiguous is that the person who understands the warehouse system leaves in month two, and you find out what they knew by discovering what breaks.

The failure mode to avoid

The pattern that causes the most damage is integrating the visible things quickly — email, branding, the intranet — while the unglamorous work goes undone. Six months in, the directories are merged and the logos are updated, and nobody has checked whether the acquired company's backups work, who still has administrative access, or what the server in the back office actually does.

Exposure first. Discovery second. Integration third. The order is not negotiable, even though the pressure always runs the other way.