Changing IT provider sounds disruptive, and it is when it is improvised. Run properly it is a sequenced project with a defined end state, and most of your team notices very little of it.
This page sets out how a transition should be run, what the incoming provider needs from you, how the handover from an outgoing one actually works, and what should be true on the day onboarding is declared finished. It applies to any organization in any sector, whether or not the provider is us.
Onboarding is not a settling-in period. Each phase has an output, and that output is what lets the next phase begin. A provider who cannot say what ends phase one is describing a transition with no end date.
Nothing is changed before it is understood. The incoming provider documents what exists: servers, network hardware, firewalls, the productivity tenancy, line-of-business applications, licence positions and every administrative credential in use. Ownership of the tenancy and the domain registration is verified and, where it sits with somebody else, corrected so that it sits with you. Management and security agents go on, backups are inventoried, and a restore is performed rather than assumed. Staff get the support number in the first week, so help exists from day one.
Discovery always produces a findings list, and it is always longer than anyone expected. Unpatched systems. Accounts still enabled months after the person left. Multi-factor authentication missing on the accounts that most need it. Backups covering less than everybody believed. Findings are ranked by risk and worked through with you, highest first, with the reasoning explained rather than asserted. Standard device builds and a joiner-and-leaver process go in here, so departing staff lose access the same day they leave.
By now the ticket history shows where the recurring pain actually is, which is rarely where anyone predicted. Those fixes move upstream, out of the help desk and into configuration, so the same issue stops being raised. Documentation is completed and handed over, so the knowledge lives in a system rather than one person's head. The service then settles into its rhythm: day-to-day support, monitoring and patching, and a scheduled review covering security posture, hardware lifecycle and a budgeted roadmap.
Onboarding stalls for administrative reasons far more often than technical ones. Almost every delay traces back to an approval nobody was able to give, or an account whose owner nobody could identify. The work below is small, but it has to come from your side.
None of this has to be perfect before starting. It has to be findable. Where a record does not exist, say so rather than sending a guess: a confidently wrong inventory costs more than a missing one.
The common case is not poor documentation. It is none at all. The environment was built over years by several people, some of whom have left, and what survives sits in an email thread or somebody's memory. That is normal and recoverable, and it has to be treated as work rather than wished away.
Discovery is then done by observation rather than by reading. Monitoring agents enumerate the devices actually on the network, which is almost never the list you were handed. Authentication records reveal the systems genuinely in use, including those a department bought without telling anyone, and licence records rarely survive contact with either. Firewall and switch configurations are read and redrawn as a diagram.
Rebuilding a record from nothing lengthens the first phase. It does not change the sequence, and the output is identical: an inventory, a network diagram and a credential record you own and could hand to somebody else.
Handovers range from genuinely cooperative to entirely silent, and you cannot tell which one you have until notice has been served. Design the transition to work in the silent case, because then the cooperative case is simply faster.
Read the termination clause of your existing agreement first: the notice period, what the outgoing provider must hand over, whether any of that is billable, and what happens to tooling licences bought in their name. This sets the calendar, and it is the item most often discovered too late.
Where the outgoing provider is uncooperative, every line above is still achievable. Ownership of a domain or a tenancy can be recovered through the registrar and the platform by the account's legal owner, which is your organization rather than your supplier. It takes longer, which is why notice periods matter.
Insist on one thing either way: a named person on the incoming side owns the transition and reports progress against the plan, so onboarding does not quietly become a permanent state with no completion date. The questions worth putting to a provider before you sign are in our guide to choosing an IT provider.
Fully covered is worth pinning down, because it is easy to say and harder to demonstrate. At the end of a transition it should mean something specific: every device and user is known and managed, the agreed services apply to all of them, and nothing depends on somebody who happens to remember how it works.
Day 90 should end with a document and a conversation rather than silence: what is in place, what remains open, what closing it would cost, and what the coming year holds. If the question underneath yours is how the monthly figure is built up, that is covered in what managed IT costs.
Our own commitments apply from the first week of a transition rather than at the end of it: a 15-minute response target on critical issues, a helpdesk and Security Operations Centre staffed 24/7, and 95% of tickets resolved the same day. Our controls are independently examined under a SOC 2 Type 2 attestation, which matters most to clients who are themselves audited. For local coverage and on-site work, see IT support in Toronto.
On the day the agreement is signed and access is granted, not on the day your previous agreement ends. The two usually overlap, and that overlap is useful: discovery can run while the outgoing provider is still in place.
They should not. Changes that affect everybody, such as password policy, multi-factor enrolment and device management, are scheduled, announced and staged rather than applied at once. For most people the visible parts are an enrolment step and a new number to call.
It slows the work but does not stop it. Domain and tenancy ownership can be recovered by the account's legal owner, which is your organization, and the rest can be documented by observation. Serve notice with enough runway, and read the termination clause first.
Not as a condition of being supported. Findings come with the risk and the cost attached, and you decide. Anything genuinely unsupportable is flagged plainly, but working equipment is not replaced to suit a provider.
The service becomes routine: day-to-day support, monitoring and patching, and a scheduled review covering security posture, hardware lifecycle and next year's budget. Anything deferred stays on the list.
If you want to see the transition plan for your own environment before committing to anything, we will walk through it with you. Our head office is at 141 Main Street N, Markham ON L3P 1Y2, and the number is 647-476-5259.
%20(1).avif){kind=logo}
%201.avif)
