Switching IT providers is the riskiest month in the relationship — not because the technology is hard, but because two organisations briefly share responsibility for one environment and neither fully owns it. This is the sequence we run to keep that month boring, written out in full so you can hold us to it. It also works as a checklist for judging anyone else. The plan this describes is managed IT; the security baseline inside it is the six-layer stack.
01 — Why handovers fail
Almost every bad handover we have inherited failed the same way: the new provider started changing things before they finished learning things. A migration on day three, a new firewall on day five — and when something broke, nobody could say whether it was the change or the environment, because the environment was never documented in the first place.
The fix is a rule, not a tool.
Nothing is changed in week one. That rule has survived every temptation to break it, and it is the single best predictor of a quiet month.
02 — Days 1–5 · Document
The first week is pure inventory. Every device, account, licence, backup job, vendor contract and — most importantly — every known pain point, written down before anything is touched. If your current provider holds the keys, we run this alongside them; the overlap is normal, and we handle the awkward conversation if there is one.
The output is the seven-artefact documentation set that stays current for the life of the engagement: asset register, network diagram, credential vault you hold keys to, licence inventory with renewal dates, vendor list, runbooks, and the written restore procedure.
- Whatever credentials you hold directly — domain registrar, Microsoft 365 admin, ISP account.
- The last invoice from every IT-adjacent vendor. It is the fastest map of what you actually run.
- Your list of “things that have always been broken.” Week one is when they finally get written down.
03 — Days 6–12 · Deploy
Monitoring and patching agents go out to every endpoint and server — tuned to what the documentation found, not to a template. A dental clinic gets maintenance windows that never touch patient hours; a retailer gets them overnight. This is also when the first honest picture of patch debt appears, and it is usually worse than anyone guessed. That is normal.
04 — Days 13–21 · Harden
With visibility in place, the security baseline goes on: MFA everywhere, conditional access, mail filtering, DNS filtering, and admin rights reduced to named, time-bound accounts. Each change is small, reversible and announced — hardening is a sequence of dull steps, not an event.
The week ends with the step most providers skip: a restore test. Not a green tick in a dashboard — an actual file, an actual mailbox, an actual system brought back from backup, timed and documented. If the backups you inherited are broken, this is the week that proves it, while there is still time to fix them calmly.
05 — Day 22 → · Quiet
Steady state. The environment is documented, watched, patched and recoverable — and the cadence takes over: nightly job checks, weekly patch review, monthly security exceptions, quarterly restore test and a written review in plain English. From here, the measure of the engagement is how rarely you think about it.
06 — What to demand from any provider
Ours or anyone else's, the same four questions separate a real onboarding from a sales promise:
- What changes in week one? The right answer is nothing.
- What documentation do I get, and do I keep it if I leave? Anything less than “all of it” is hostage-taking with a friendly face.
- When is the first restore test, and do I see the evidence? A date and a document, or it does not exist.
- What does day 31 look like? If the answer is vague, the onboarding was the product and the service is an afterthought.
The full scope, response targets and pricing approach for the engagement this describes are on the Managed IT page — and the backup discipline it hands over to is on Backup & Disaster Recovery.