Taking over someone else’s IT estate

Taking on support for an existing estate means becoming accountable for systems you have not seen, built by people you cannot ask, documented in a way that is at best partial. The first thirty days decide whether that becomes a working relationship or a sequence of surprises.

Week one: find out what exists

Before anything else, an inventory — from discovery rather than from the handover document, because the handover document describes what someone believed in the year it was written.

• Scan the networks and compare against what you were given.
• Enumerate the cloud accounts and subscriptions, including any a department pays for separately.
• List the domains, certificates and their expiry dates. An expiring certificate nobody owns is the classic first-month incident.
• List the internet-facing services, from the outside in.
• Identify the backup systems, and what they actually cover.

The gap between the document and the discovery is the most informative thing you will produce all month. Record it and show it to the customer — it sets a shared, factual starting point rather than an inherited assumption.

Week one, in parallel: secure the keys

A transition is the moment when access is at its least controlled. Outgoing staff or providers retain credentials, shared passwords are widely known, and nobody has an inventory of who holds what.

• Change administrative credentials on everything you are taking over, in a planned sequence.
• Enumerate who currently has privileged access and remove what is no longer appropriate.
• Take ownership of the registrar, DNS, certificate and cloud root accounts. These are the ones with no technical workaround if they are lost, and they are frequently held personally by someone who has left.
• Establish break-glass access and store it properly.

Week two: find out what matters

An inventory without criticality is a list. Sit down with the business and establish which systems, if they stopped, would stop work — in their terms, not in system names.

Expect this to contradict the technical assumption. The system with the most monitoring is often not the one whose failure hurts most, because monitoring accretes around what has broken before rather than around what matters.

Alongside it, two questions that shorten the next six months considerably: what breaks regularly, and what is everyone afraid to touch? The answers name the real risks faster than any assessment.

Week two to three: check the things that are usually wrong

A short list, in priority order, because these are the findings that recur across almost every transition:

1. Restore a backup. Not the report — an actual restore. It is the single most valuable thing done in the first month.
2. Check what is out of support — operating systems, databases, appliances, firmware.
3. Check what is exposed from the internet, and whether it should be.
4. Check certificate and domain expiries for the next twelve months.
5. Check the monitoring covers the critical systems established in week two, and that its alerts reach someone who now exists.

Week three to four: establish how work will flow

The operational relationship needs settling while nothing is on fire: how requests are raised, who is authorized to approve what, how an incident is escalated and to whom, what the reporting cadence is, and what the change process is for the estate.

Agreeing the escalation path during the first real incident is how transitions go wrong publicly.

Then report honestly

At thirty days, a written position: what was found, what differs from the handover, what the immediate risks are, what has already been fixed, and what needs a decision or a budget.

There is a temptation to soften this, either to avoid criticizing the predecessor or to avoid alarming the customer. It is the wrong call. Findings raised in month one are inherited problems; the same findings raised in month eight are yours.

What good looks like at ninety days

An inventory that matches reality, credentials under control, a tested restore, monitoring aligned to what the business actually depends on, a documented escalation path, and a risk list with owners and dates. None of it is glamorous, and all of it is what makes the following year quiet.

Our infrastructure managed services begin with exactly this sequence — discovery before assumption, a restore test before a service report, and a written thirty-day position. If you are changing provider, the handover pack is worth comparing against what a discovery would find.