The first ninety days of an outsource
Handing your IT to someone else is mostly a documentation exercise, and the quality of the first three months decides what the next three years feel like.
Changing providers is a decision people put off, usually because the last transition was painful and nobody wants to repeat it. That reluctance is reasonable, and it is worth being specific about what a transition actually involves, because most of the pain is avoidable and comes from the same few places.
What the first weeks are really for
Not fixing things. Finding out what there is.
Every environment holds decisions nobody wrote down: why that server is still on, which of the two backup jobs is the real one, what the accounts system depends on that nobody has touched since the person who built it left. A transition that starts by changing things breaks something load-bearing in week two.
So the early work is discovery, and the deliverable is documentation that did not exist before: the asset register, the network as it actually is, identity and licensing, the dependency map, the list of third parties who have access, and the list of things that are quietly wrong.
That last list is the one clients find most useful, and it is also where the awkwardness lives, because it is implicitly a report card on the previous arrangement. We try to write it as a state of affairs rather than a verdict. Sometimes the previous provider was asked to do less than the client believed, and that shows up here.
The handover from the incumbent
This is the part to plan hardest, because you have the least control over it.
Get the notice period, the offboarding obligations and the documentation rights out of the existing contract before anything else. Then be concrete about what is being handed over: administrative credentials, domain registrar access, tenancy ownership, licence agreements, certificate and DNS control, documentation, and open tickets.
Tenancy ownership is the item that most often turns a transition into a project. If your Microsoft tenancy sits under the provider’s agreement rather than your own, the change is a migration rather than a transfer, and it should be scoped as one rather than discovered mid-way.
Most outgoing providers are professional about this. Some are not, and the honest answer is that friction is usually commercial rather than technical. Assume goodwill, plan for the alternative, and do not schedule the cutover for the week of a season peak.
What we do in that window
Roughly in this order, though it overlaps.
Weeks one to three: discovery, access, and monitoring in place, so that we can see the environment before we touch it. Nothing changes except visibility.
Weeks three to six: stabilise the things that are actively risky. Usually that is identity, backups and anything internet-facing with no support behind it. This is also when the honest list of findings gets written up.
Weeks six to twelve: the boring foundations. Patching cadence, device baselines, documentation, and a roadmap with the remaining findings sequenced and costed, so the client can decide what happens in what order rather than being presented with a bill.
Support runs throughout, obviously. The point of the sequence is that we do not start improving until we can see, and we do not start rebuilding until it is stable.
What a client should expect to feel
Weeks one and two: mildly frustrating, because a lot of questions get asked and nothing visible improves.
Week six: the pace picks up and the reasoning behind decisions starts to be explained rather than asserted.
Month three: a roadmap, an environment that is documented, and a clear answer to what it will cost to fix the things that are still wrong.
If at ninety days there is no documentation and no prioritised list of findings, the transition has not happened yet, whoever is doing it. That is a fair question to ask of any provider, including us.