Taking on someone else's IT estate is the riskiest moment in the relationship. This is the sequence we follow so that nothing important is discovered during an emergency.
A provider cannot manage what it cannot see, support what it cannot access, or be accountable for systems nobody documented. So the first month is spent understanding your environment rather than changing it. The second turns those findings into fixes, in an order your business can absorb. The third proves the arrangement works and sets the rhythm for everything after.
The output is a written picture of what you actually run, and a ranked list of what we inherited.
A structured start with named people on both sides, so nobody is wondering who to call. Escalation paths and support expectations are agreed in writing before anything else happens.
Hardware, software, licences, user accounts and network topology, catalogued properly. Automated discovery does the collecting; an engineer validates it rather than trusting the tool.
Who can reach what, which admin accounts exist, whether shared logins are in use, and whether your leaver process actually removes access. Inherited credential gaps are the most common serious finding.
We test a restore rather than checking that a job reports success. A backup nobody has restored from is an assumption, not a safeguard.
Monitoring is deployed early so we are seeing real behaviour before we start changing things — and so the baseline is genuine rather than measured after our own work.
Changes are sequenced so your business can absorb them, rather than compressed into one disruptive month.
The findings from discovery worked through in order of risk and effort, not in the order they were noticed. You approve the sequence.
Patch levels brought current, endpoint protection standardised, multi-factor authentication applied where it is missing. Unpatched systems and compromised credentials are the two most common ways in.
Machines and services brought onto consistent builds, so support is faster and behaviour is predictable across the estate.
The environment recorded in a form another engineer could pick up cold. This is yours, and you keep it whether or not you stay with us.
Staff shown how to raise a ticket and what to expect back. A support process nobody knows how to use does not get used.
By the end of the first quarter, IT management should feel planned rather than reactive.
Anything parked during phase two is finished or explicitly carried forward with a date, not quietly dropped.
Ticket volumes, response times, uptime and open risks recorded, so future reviews compare against something real.
A session with whoever owns the budget: what we found, what we fixed, what it cost, and what we recommend next. Written up, not just discussed.
A prioritised plan for the following quarters, with indicative costs, so IT spend stops being a series of surprises.
Steady state means monitoring and patching running continuously, your team raising tickets through one route, and a business review each quarter covering what happened, what it cost, and what is coming. The roadmap is revisited at each review rather than written once and forgotten.
Tickets are ranked by business impact, not by when they arrived. Anything stopping people working outranks anything inconvenient, and a single user unable to work outranks a cosmetic fault affecting everyone. Specific response targets are written into your agreement rather than published here, because a realistic commitment depends on the size of your estate and the cover you have chosen — and we would rather agree something we can meet than advertise something we cannot.
If you are considering moving provider, the discovery phase alone is usually worth having — even if you decide to stay where you are.
Book a Call