Switching IT Providers: What Actually Changes
Most organisations considering a change still rate their current provider as competent. That is not a contradiction — it is the most common version of this decision. A provider that was the right choice at one size and shape of business is not automatically the right choice at the next one.
This page sets out what genuinely changes, what does not, the sequence that keeps a transition from going wrong — and the cases where switching will not fix the problem you actually have.
First, The Honest Version
Most of this is not a performance problem
A two-person provider cannot staff continuous coverage. A provider priced for break-fix cannot fund proactive operations. A generalist cannot hold deep Microsoft 365, network and compliance capability simultaneously. None of those are failings — they are the arithmetic of how that business is built, and no amount of escalation changes arithmetic.
Which leads to the distinction worth making before anything else: a fixable gap and a structural mismatch look identical from the inside. A fixable gap responds to a direct conversation about scope and expectations. A structural mismatch does not respond to conversation at all, because the thing you need is not the thing the provider is built to deliver.
Working out which one you have is worth doing before changing anything — and it is the reason the section near the bottom of this page argues against switching in several specific cases.
The Triggers
Eight reasons organisations change provider — and what each one usually means
The left column is what gets said out loud. The right column is the underlying condition, which determines whether a change will actually help.
Response has slowed, and the same issues keep returning
Recurrence is the signal, not slowness. A provider closing tickets without recording a contributing cause will keep closing the same ticket. That is a method problem, and method problems do not resolve under escalation.
Support is reactive — nobody tells you anything until something breaks
Proactive operations are a cost structure, not an attitude. A provider priced for break-fix cannot absorb continuous patch, monitoring and review work without changing what it sells.
The business grew, and the provider did not grow with it
A provider that fitted at fifteen users may be genuinely unsuited at eighty — more sites, more compliance exposure, more systems that cannot be down. Nothing went wrong; the requirement moved.
Nobody can produce documentation when it is asked for
This is the one that usually surfaces at the worst moment — an audit, an insurance renewal, a customer security review. And the real question is rarely whether the provider will hand documentation over. It is whether it was ever produced.
A customer, insurer or auditor asked for evidence you cannot produce
Evidence is a by-product of how an environment is operated. A provider that does not record access reviews, change history and recovery tests as it works cannot reconstruct them later on request.
Infrastructure is aging and there is no plan
Lifecycle planning requires someone accountable for a multi-year view. Where no one owns it, equipment is replaced when it fails rather than before it does.
Billing is unpredictable, or nobody can say what is included
Ambiguous scope is usually a contracting failure rather than a billing one, and it tends to persist because neither party wants to reopen it.
The relationship depends entirely on one person at the provider
When one engineer holds the knowledge, their departure is your operational event. That is a documentation and process gap wearing a relationship problem as a disguise.
What Actually Moves
Change of management, not migration
The single most useful distinction in this subject. Most provider changes are a change of who administers an environment. Most buyer anxiety is calibrated to a full migration, which is a different and much riskier project.
Who administers your environment
changes
Administrative access, monitoring agents, patch tooling and the escalation path move. This is the substance of most provider transitions, and it is reversible and low-risk when sequenced properly.
Your Microsoft 365 tenant, identities and data
does not change
The tenant belongs to your organisation. Changing provider does not move it, rebuild it, or require users to be recreated. Delegated administrative access is revocable by you, is time-bounded by Microsoft’s own design, and is not ownership.
Who holds the Microsoft licensing relationship
changes — separately
Administrative access and the billing relationship are two independent things, and they are frequently conflated. A competent transition handles them in a deliberate order rather than simultaneously.
Your users’ day-to-day experience
largely does not change
Mailboxes, files, applications and sign-in generally continue as they are. Most provider changes are a change of management, not a migration — and most buyer anxiety is calibrated to a migration.
Security tooling licensed through the provider
usually changes
Where EDR, email security or documentation platforms are licensed to the provider rather than to you, they are often not portable. This is a legitimate, unavoidable cost of switching that an honest provider quantifies up front rather than minimising.
Historical backup retention
may not transfer
Backup history is frequently non-portable. The failure is silent: you regain administrative access and only discover months later that the recovery history did not come with it. Resolve this before access is removed, not after.
Sequence
Transitions fail on order of operations, not on technology
Every step below is ordinary. Performing them in the wrong order is what turns a routine change into an incident.
Before notice is given
The phase with the most leverage and the least attention. Check the domain registrant; establish your own Global Administrator and break-glass accounts; find the contract notice window and diarise it; determine whether transition-assistance language exists at all; inventory what the incumbent controls — licensing, backup platform, security tooling, documentation, DNS.
Independent discovery
The incoming provider documents the environment without depending on the incumbent’s cooperation. Anything that only exists in the outgoing provider’s head or platform is identified here, while there is still time to do something about it.
Parallel running
Both providers hold access briefly. The incoming provider’s access is established before the outgoing provider’s is removed — this is what eliminates the gap-in-coverage fear. It is also the highest-privilege window of the whole relationship and should be deliberately time-boxed rather than left open.
Cutover, in order
Licensing stabilised, then monitoring and endpoint tooling, then backup verified with a dated test restore, then documentation handover confirmed — and only then is the incumbent’s access revoked. Reversing any two of these is how transitions go wrong.
When Not To Switch
Three cases where changing provider will not fix the problem
The scope was never actually agreed
If nobody can point to what the provider is responsible for, the next provider inherits the same ambiguity. Fix the scope first — with the incumbent if they are willing. If that conversation is impossible, that is itself the finding.
The real constraint is internal
Where decisions stall internally, budget is unavailable, or no one internally owns technology, a new provider arrives into the same conditions and produces the same outcome. The provider was not the bottleneck.
The expectation was never reasonable
Enterprise response expectations at small-business pricing do not resolve by changing supplier. A provider promising otherwise is making a claim worth examining carefully before signing.
IT KORR would rather say this plainly than win an engagement that was never going to work. A transition undertaken for the wrong reason produces a dissatisfied client a year later, and the reason is usually visible at the start.
FAQ
Common Questions
How difficult is it to change IT providers?
Less difficult than most buyers expect, and difficult in a different place than they expect. The technical change is usually modest — administrative access, monitoring agents and tooling move, while the systems themselves stay put. The hard part is almost always what the incumbent holds that nobody inventoried: licensing ownership, backup history, documentation, and domain control. Transitions that go badly are nearly always sequencing failures rather than technical ones.
Can our current provider stop us from leaving?
Not from leaving, and not from your own tenant — that belongs to your organisation, and delegated administrative access is revocable by you. But there is one real friction point worth knowing: where Microsoft licensing is held through a provider, the transfer of that billing relationship requires the outgoing partner to approve it. Microsoft does not mediate that, and an unanswered request simply expires. It is workable either way — if a transfer is refused, the practical fallback is to let the term run and have the incoming provider purchase fresh subscriptions in the same tenant. Nothing moves; it is a billing event rather than a migration.
Will we have downtime?
A change of management should not cause downtime, because nothing is being migrated — the same servers, mailboxes and applications continue running while responsibility for them changes. Downtime risk appears when a provider change is bundled with actual migration work. If both are happening, separate them in time rather than treating them as one project.
What does our outgoing provider owe us?
Whatever the contract says, and frequently that is nothing. Absent an explicit transition-assistance clause, a departing customer is generally not owed assistance, and a provider may be entitled to delete customer data after a retention window. This is the most under-communicated fact in the subject, and it has a practical consequence: the decisive moment is the contract you sign with the incoming provider, not the argument you have with the outgoing one.
How long does a transition take?
It depends on what documentation already exists, which is why no honest provider should quote a single number before looking. A well-documented environment can transition quickly; one where nothing was ever written down takes materially longer because the incoming provider is discovering the environment rather than inheriting a description of it. Published industry timelines vary so widely that they are not useful as a planning input.
What should we ask a prospective provider before signing?
Ask what documentation you will receive and in what format; who holds the Global Administrator accounts; what happens to your records if the relationship ends; and whether transition-assistance rights are written into the agreement in your favour. A provider that answers these concretely is describing an operation. One that answers in principle is describing an intention.
Is it worth switching if our provider is mostly fine?
Often not — and that is a legitimate answer. If the gap is fixable through a direct conversation about scope, cadence or expectations, switching imports transition risk to solve something a meeting could resolve. Switching is justified when the mismatch is structural: when what you now need is not what the provider is built to deliver.
Related
The documentation you should expect from any provider — and the questions to ask about it.
The operating model on the other side of a transition.
If the gap is capacity rather than capability, a full provider change may not be the answer.
What IT KORR does, where it operates, and what is included.
Which model fits, before deciding whether to change provider at all.
Rebuilding the record set when a transition reveals it was never produced.
Before You Decide
Work out whether the gap is fixable or structural
Bring the specifics — what is recurring, what cannot be produced on request, what the contract actually says. If the honest answer is that your current provider can resolve it, we will tell you that.
We respond within one business day.