What switching IT providers involves, and how to keep the disruption small.

1. How to tell if it is time to switch

Most businesses do not switch IT providers because of a single bad day. They switch because a pattern has built up over months, and the gap between what they need and what they are getting has grown too wide to ignore. Recognising the pattern is the hard part. Problems that become normal stop feeling like problems.

Here are the signs worth paying attention to:

• Tickets that stay open for days with no update. A healthy ticketing process tells you what is happening, even when the answer is "still investigating".
• You only hear from your provider when something breaks. There are no reviews and no roadmap, and nobody suggests improvements. The relationship is purely reactive.
• Your IT environment has not changed in years. Same servers, same configurations, same workflows. Old technology costs more to support and is harder to secure.
• You or your team have started routing around IT. Personal Dropbox instead of SharePoint. A private list of passwords because the helpdesk is too slow. Shadow IT is usually a symptom of a service that is not meeting needs.
• Security is a mystery. You do not know if MFA is enabled everywhere, if you could restore from your backups, or what your risk looks like. Nobody has ever shown you.
• You pay invoices without understanding what you are getting. Line items are vague, and the link between cost and outcome is unclear.
• Your provider does not know your business. They know your network, perhaps, but not what your team does, which systems matter, or where growth is heading.

A slow ticket or a frustrating week is not, by itself, a reason to switch. Every provider has bad weeks. A persistent pattern across months, particularly around communication, visibility and proactive work, usually is.

Sometimes the issue is fit. A provider built for large enterprises may not suit a smaller business, and the reverse is also true. A helpdesk tuned for corporate clients can be too slow, too formal or too expensive for a small business, even when the engineers are competent.

Knowing whether you have a fit problem or a quality problem changes the conversation you have with your current provider, and what you look for in the next one.

2. What to look for in a new provider

Once you start looking, the market can feel noisy. Most providers describe themselves the same way. Cut through by asking for specifics: how is the service structured, and what do they do day to day?

Key things to compare across providers:

• Service model clarity. Do they charge per seat, per device or per hour? Is the support included, or is it metered by the hour? Ask for a list of what is in scope and what is not. A vague answer here usually means vague service later.
• Proactive work. A good managed service is monitoring, patching and improving in the background, between calls. Ask what they do in a typical week when nothing is on fire.
• Communication standards. What are the response targets for each priority level? How often do you meet to review the service, and what reporting do you get between reviews? Ask to see a sample report.
• Cybersecurity posture. Is a security baseline standard or an add-on, and what does it include? MFA, endpoint protection, patching and backups you can restore from should come as standard, never as optional extras.
• Fit. Do they work with businesses of your size and complexity? Ask them to describe a typical customer. If that customer is much larger or much smaller than you, that tells you something.
• Transition capability. Have they moved customers from other providers before? Ask them to walk you through their last transition and what they did in the first 30 days.
• References or proof. Testimonials, case examples, or the willingness to let you speak with an existing customer. A provider confident in its service will not shy away from this.

One common mistake is choosing on price alone. The cheapest provider is rarely the one that documents your environment thoroughly, keeps backups you can restore from and gives you a named contact who picks up the phone. The hidden cost is technical debt and the time your staff spend working around poor IT. Price matters. It should not be the deciding factor.

3. How the transition process works

A transition is a structured project. It is not a single weekend cutover, and it is not months of disruption. Done well, your staff should barely notice beyond a new helpdesk contact.

A typical transition moves through these phases:

1. 1Discovery. The incoming provider assesses the current environment: devices, accounts, software, Microsoft 365 tenant, network, licences, vendors, security controls and backups. Expect questionnaires, scanning tools and conversations.
2. 2Documentation. The current state gets documented, often for the first time. Asset registers, access matrices, software inventories and configuration notes.
3. 3Transition plan. Scope, timeline, and what happens to existing vendor relationships and contracts. Who is doing what, when, and how progress is measured.
4. 4Parallel period. The new and old provider may overlap briefly, or there may be a clean handover date. Either can work. The right choice depends on the complexity of the environment and the relationship with the incumbent.
5. 5Go-live. The new provider takes over the helpdesk and monitoring. Staff are introduced to the new support channel.
6. 6First 90 days. Stabilisation, fixing known issues, and setting the regular rhythm: reporting, business reviews and any agreed roadmap items.

Every transition turns up things the old provider let drift: undocumented systems, licences for people who left two years ago, weak passwords nobody reset, a backup job failing silently for months, settings applied by someone who is no longer at either company. This is normal, and it is one of the main reasons switching is valuable. You start again from a documented, known state.

Ask any provider you are evaluating: does your onboarding follow a documented process? Will we have a single point of contact through the transition? What happens if we need the outgoing provider during the handover? Vague answers are a warning sign. Specific answers, with examples, are reassuring.

4. What to prepare before you move

You do not need a complete asset register before you start talking to providers. A capable incoming provider will do the discovery work. The more you can gather in advance, though, the smoother the early stages will be.

• Gather what you can. The contract with your current provider, recent invoices, a list of software licences and subscriptions, and an informal list of systems and who has access. Partial information still helps.
• Check your notice period. Most managed service contracts have notice periods of 30 to 90 days, and some auto-renew. Review the terms before you commit to a transition timeline, so the dates line up.
• Identify your key systems. Email, your CRM, accounting software, industry-specific applications: anything that cannot be down. Listing these helps the incoming provider plan the riskier moments around them.
• Talk to your team. Staff need to know a change is coming, particularly a new support number, a new ticket system, and possibly a new person at the door. A short note in advance prevents confusion on day one.
• Accept that you may not have everything. A good incoming provider will not expect a tidy handover pack. Anything you can provide is a bonus.
• Domain and DNS access. This is often the single biggest blocker. If your current provider holds your domain registrar login or controls your DNS, make sure you can regain access. Your domain is your business's property.

A note on data ownership, because it comes up often. Your data belongs to your business: email, files, documentation, configurations, asset registers and historical tickets. A reputable outgoing provider will make the exit clean and cooperative.

Confirm the exit obligations in writing before the transition begins. If you meet resistance or evasive answers later, you have something to point to.

5. Common concerns about switching

These are the questions that come up most often when owners and operations managers start thinking seriously about switching.

Will there be downtime?

Possibly a little, and a well-run transition keeps it small. The highest-risk moments are an email cutover, if you are also changing mail platforms, and the monitoring handover, where alerts move from the old tools to the new. Both are planned for quiet windows and tested first. Where the platform stays the same, as with most of Microsoft 365, the network and file storage, staff usually do not notice.

What if our current provider is uncooperative?

It happens, and an experienced incoming provider has handled it before. The usual friction points are withheld documentation, domain or DNS access, and slow tickets during the notice period. Have your contract reviewed early, know the notice and handover obligations, and put your expectations in writing. Then lean on the incoming provider, who will know which calls to make and which records to request formally.

We have a long-standing relationship with our current provider.

A long relationship, particularly with a person you trust, has real value. It is still worth separating the relationship from the service. The business has grown, the risks have changed, and staff expect more. If you value the relationship, have an honest conversation with them about what is not working. Sometimes that prompts a real improvement. Sometimes it confirms that the gap is too wide to close.

How long will we be disrupted?

Staff mostly notice a new support number and ticket system. The leadership team feels it more, because discovery sessions and decisions sit with them. Plan for that time: a few hours a week through discovery and the transition plan, then the regular review rhythm once the switch is done.

Is this the right time?

There is no perfect time. There will always be a project, a busy period, or a quiet window that seems like it should come first. A poor-performing provider is a compounding cost: slow tickets, thin documentation and security drift all accumulate. At some point the disruption of switching becomes smaller than the cost of staying. The sections above are meant to make that judgement easier.