Switching IT providers doesn't have to mean downtime or chaos. Here's what actually happens across a properly run 90-day onboarding — from discovery through the first business review — and how to tell if the plan you've been handed is real.
Almost every business that’s shopped for a new managed IT provider has had the same thought at some point: this sounds good, but what actually happens in the weeks after we sign? That question matters more than most of the sales conversation, because a good provider and a bad onboarding process can produce the same outcome — a business that’s worse off for having switched.
Managed IT onboarding is the structured process of transitioning a business’s IT environment to a new provider — documenting what exists, migrating and securing systems in a defined sequence, and validating that everything works — typically completed over 60 to 90 days while live support continues in parallel.
“I’d rather we catch this now, in a review, than have it show up as an incident in six months.”
— Jeffrey Bowles, Partner & Director of IT Services, ACT360
This article walks through what should actually happen in each phase, where onboarding tends to go wrong, and how to tell whether the plan you’ve been handed is a real transition roadmap or just a sales deck with dates on it.
Why Onboarding Is Where Switching Fear Actually Comes From
Businesses stay with underperforming IT providers longer than almost any other vendor relationship, and the reason is rarely satisfaction. It’s fear of the transition itself. One Ontario manufacturing CEO stayed with a provider he knew wasn’t performing for three extra years, specifically because he was afraid of what would break if he switched. Nobody wants to be the business that switched providers and then spent two weeks fighting broken email or a server that wouldn’t come back up.
That fear isn’t irrational — it’s a reasonable response to how badly onboarding gets handled industry-wide. A provider who treats onboarding as an afterthought — a quick network scan and a login handoff — is setting up exactly the kind of disruption businesses are afraid of. A provider who treats it as a defined, sequenced project is doing the opposite: reducing risk instead of creating it.
The Canadian Centre for Cyber Security’s baseline guidance for small and medium organizations opens with the same starting point every serious onboarding process should: you can’t secure or manage what you haven’t documented. Asset inventory — a complete list of hardware, software, and cloud services in use — is listed first among its recommended controls, precisely because everything else depends on it.
Days 1-30: Assess & Comprehend
The first 30 days shouldn’t involve moving anything. This is the discovery phase, and rushing it is the single most common cause of onboarding problems that surface months later.
A real assessment covers the technical inventory — every server, workstation, network device, application, and cloud service in use — plus the parts that don’t show up on a network scan: how staff actually use their systems, which workarounds have become “normal,” what decisions led to the current setup, and where the business is headed over the next two to three years.
This is also when documentation gaps get exposed. It’s common for a business to discover that nobody has a current password for a piece of network equipment, or that a “temporary” workaround from three years ago is now load-bearing for an entire department. Finding that in week two is a minor inconvenience. Finding it during a live migration is an outage.
By the end of this phase, a business should have a written picture of its environment — not just a device count, but a document explaining what’s running, why, and what depends on what.
Days 31-60: Tailor & Implement
This is where the actual transition happens, and the operating principle should be phased, not big-bang. Critical systems move first, get validated, and only then does the next system move. Nothing flips all at once.
A typical sequence looks like this:
| Timeframe | What Happens | What This Prevents |
|---|---|---|
| Week 5 | Security baseline deployed: endpoint protection, MFA, patch management schedule set | A gap where the old provider’s tools are gone but the new ones aren’t active yet |
| Week 6-7 | Backup and disaster recovery systems migrated and tested | Discovering a backup doesn’t work during an actual emergency instead of during a test |
| Week 7-8 | Core business systems migrated (email, file access, line-of-business applications) in priority order | An all-at-once cutover where five things break simultaneously and nobody can tell which failure caused which |
| Week 8-9 | Monitoring and helpdesk tools fully active; old provider’s access formally revoked | A security gap where two providers technically have access, or neither clearly owns a ticket |
Live support runs throughout this entire window. A properly run onboarding doesn’t create a support gap while the technical work happens — staff can still call in for help on day 35 exactly as they could on day 5.
Days 61-90: Validate & Optimize
The final phase is where a lot of providers stop paying attention, and it’s exactly the wrong place to do that. Migrating a system isn’t the same as confirming it works under real conditions.
This phase should include actually testing backups by restoring something, not just confirming a backup job ran. It should include walking the team through any new tools or processes, since a perfectly migrated system that nobody knows how to use isn’t actually done. And it should end with the first real business review — not a check-in call, but a structured look at what was found during onboarding, what’s already been fixed, and what’s next.
That first review is the handoff point between onboarding and the ongoing relationship. It’s also the moment a business finds out whether “we’ll do quarterly reviews” was a real commitment or a line in a sales deck.
What Can Go Wrong (and How Good Onboarding Prevents It)
Onboarding does occasionally cause real disruption, and pretending otherwise doesn’t help anyone evaluate a provider honestly. The difference between a bad experience and a non-event usually comes down to a few specific failure points:
Skipping documentation to move faster. A provider under pressure to show quick progress sometimes starts migrating before finishing discovery. This is how “temporary” workarounds turn into mid-migration surprises.
Migrating everything at once. A single cutover weekend feels efficient on a project plan and creates the highest-risk scenario in practice — if something breaks, there are five possible causes to untangle instead of one.
No overlap in provider access. Revoking the old provider’s access before the new one has fully validated everything removes a safety net at exactly the moment it might be needed.
Treating training as optional. A system that works perfectly but that nobody was shown how to use generates support tickets that look like technical failures but are actually a missed step in onboarding.
None of these are inevitable. They’re what a defined, phased plan with named milestones is specifically built to prevent.
How to Tell If Your Onboarding Plan Is Actually Solid
Before signing, it’s reasonable to ask a prospective provider to walk through their actual onboarding plan rather than accept “smooth transition” as an answer. A few signs the plan is real:
- It has specific phases with target dates, not just a general timeline
- It includes a documentation/discovery period before anything gets migrated
- It names which systems move first and why
- It includes a plan for testing backups, not just migrating them
- It specifies when the old provider’s access gets revoked, and confirms there’s overlap rather than a gap
- It ends with a defined first business review, not just “ongoing support”
If a provider can’t answer these specifically, that’s worth noticing before day one, not during week six.
What This Looks Like at ACT360
Onboarding is the “Implement” step in ACTION, but it only works because it comes after Assess and Comprehend, not instead of them. We don’t quote a transition plan from a headcount and a device list — the same team that does the discovery is the team that runs the migration, which means nothing gets handed off to people who weren’t in the room for the assessment.
Every ACT360 managed IT engagement includes a 90-day exit clause, and onboarding is exactly why that number was chosen. As my co-founder Adam puts it: “If this isn’t working in 90 days, you’re not stuck with us. That’s the point of the exit clause.” Ninety days is roughly the length of a properly run onboarding — long enough to judge whether a partnership is actually working, not just whether the sales pitch matched reality.
The first vCIO-led business review happens at the end of onboarding, not months later. For more on what that role actually covers day to day, see our breakdown of what a vCIO does. And if you’re not yet sure what should be included in the agreement you’re transitioning into, our plain-English guide to what managed IT actually includes covers that groundwork.
Final Thought
The businesses that end up frustrated with a provider switch usually aren’t frustrated with the new provider’s capability — they’re frustrated with a transition that felt chaotic, unexplained, or rushed. That’s almost always a planning failure, not a technology failure. A provider that can walk you through exactly what happens in week one, week five, and week nine isn’t showing off. They’re showing you they’ve done this enough times to know it has to be planned that specifically.
If you’re evaluating a switch and want a clearer picture of what a real transition would look like for your business, that’s exactly what an IT Readiness Assessment covers before anything is signed.
T: 705-739-2281 E: [email protected]
