Some IT relationships fade rather than fail. Tickets still close. Invoices still arrive. Meanwhile the same problems return, nobody owns the awkward supplier conversations, and the business has grown around a setup that was never really designed.
Changing provider is not a personality decision. It is a project. It needs a clear reason, a picture of what good looks like, and enough documentation that you are not buying a mystery. This is not an argument for switching. It is a way to decide without being bounced into it.
Signs the current arrangement may no longer fit
One sign is not a case for divorce. A pattern is. Look for several of these, sustained, after you have said they matter:
- The same incidents return and are never treated as a design problem.
- Ownership is unclear: you are the person who has to chase Microsoft, the ISP, the landlord and the “IT company”.
- Communication is slow, defensive, or only happens when you chase.
- Documentation is thin, outdated, or exists only in one engineer’s head.
- Devices are replaced when they die, with no view of age, warranty or risk.
- Nobody can explain backup scope, monitoring, or when recovery was last tested.
- Security controls are assumed (“we have MFA”) but not evidenced.
- There is no technology planning — only the last emergency and the next invoice.
- The relationship still looks like break-fix while the business now depends on Microsoft 365, hybrid working and a handful of critical cloud systems.
Reasons not to switch on impulse
Frustration is information. It is not a migration plan. Changing provider while you are angry about a single incident often recreates the same mess with new logos.
There is real cost: notice periods, overlapping fees, time from your own staff, residual access that did not get removed, and a window where two parties each think the other is watching the backups.
Sometimes the current provider is a reasonable fit and the environment is the problem — ageing kit, an undocumented line-of-business system, or a Microsoft 365 tenant that was never administered. Those things follow you. Planning what’s next is often the better first move: name the issues, then decide whether the partner can meet them.
“If you cannot describe what is wrong in a page of plain English, you are not ready to brief a replacement. You are shopping for a mood.”
What you should understand before you move
Write down the current risks, not only the annoyances. What would hurt this month if it failed?
Establish what access and documentation exist: admin accounts, DNS, backup consoles, device management, warranty portals, registrar logins. If those live in a personal mailbox, that is part of the problem and part of the project.
Read the contract. Notice, scope, what happens to data, and whether “unlimited support” excluded the work you actually need.
Decide what good looks like. How we work is Radius’s version of that story: understand, baseline, then operate. You do not have to choose Radius to use that shape. You do have to choose some shape, or the next provider will only be a new queue.
The Radius Standard is a useful checklist of areas — identity, devices, Microsoft 365, security, backup, networks, operations, improvement — even if you never become a customer. If a prospective provider cannot talk to those areas in ordinary language, they are selling tickets.
Questions to ask a prospective IT provider
Ask for answers you could show a colleague. Vague confidence is easy. Specific operating habits are harder.
- Who owns an issue when another supplier is involved?
- How do you manage onboarding and offboarding, including access as well as devices?
- How do you know devices are patched — and what do you do when they are not?
- How are backups monitored, and when was recovery last checked?
- How is the environment documented, and who can use that documentation?
- How do you identify recurring problems instead of closing them as new tickets?
- How do you help plan future technology, rather than only responding?
- How do you approach security as ongoing operations, not a one-off product?
- How do you approach AI and automation — including when you would advise against it?
- What is outside scope, in writing?
A change done properly is quieter than a pitch
A competent transition looks like inventories, dual-running where needed, named administrators, backup jobs that still exist on Monday, and staff who know where to ask for help. It does not look like a weekend cutover announced on a Friday.
Managed IT is the operating relationship you are buying. If the sales conversation cannot describe the first ninety days without slogans, believe that.
If you want a structured view of the current environment before you decide anything — stay, fix, or leave — a Technology Review is built for that. It is a discovery exercise, not a trap and not a score.