Changing IT providers? Start with the problem you need solved.

Choosing an IT provider is easier when you can explain what needs to be different after the change. Perhaps staff spend too much time chasing an unresolved issue. Perhaps the business is growing and a project has outgrown the capacity available to it. Or perhaps the service you bought no longer matches the way you work.

Before requesting proposals, write down three things: the problem, its effect on the business, and the result you would accept as a resolution. That short exercise gives prospective providers something concrete to respond to—and helps you avoid buying a different version of the same frustration.

Consider three possible decisions

Improve the existing arrangement. A concern may come from unclear priorities, an excluded service or expectations that were never agreed. Ask the current provider what a realistic resolution would involve. Their explanation can help you decide whether the relationship can still work.

Add specialist help for a project. You may be satisfied with everyday support but need extra capacity for a migration, network redesign or Microsoft configuration project. In that situation, a specialist can work alongside the existing team, provided responsibilities and access are agreed.

Choose a replacement. If the required service and the provider's capabilities or working arrangement no longer align, a replacement may be appropriate. Compare the new proposal against the outcome you need, not simply against the old monthly fee.

Give every bidder the same brief

Imagine a company whose remote staff regularly lose access to a business application. This is an illustrative example, not a customer case study. One proposal might offer more support hours. Another might propose investigating the application and network dependencies before recommending changes. Those proposals address different needs and should not be compared on price alone.

A short brief can make the distinction clear:

• Business impact: what work is delayed, and who is affected?
• Desired result: what should staff be able to do reliably?
• Scope: investigation, implementation, ongoing support—or some combination?
• Constraints: when can work take place, and who approves changes?
• Acceptance: how will you and the provider decide the work is complete?

Ask each provider to separate what is included, what depends on discovery, and what would require a further agreement. If you need daytime response or after-hours coverage, make that a direct question rather than an assumption.

Treat access and purchasing as separate questions

Someone being able to administer a service does not tell you who pays for it or which commercial relationships remain in place. For Microsoft 365, Microsoft explicitly distinguishes removing a partner's administrative roles from removing the partner relationship. A support change therefore needs a separate review of administrative permissions and subscription arrangements. Microsoft guidance on partner relationships.

Ask the authorized people responsible for each service to confirm its account owner, billing contact and access arrangements. Transfer sensitive information through an agreed secure method. Make access changes through a reviewed plan, with business authorization and working recovery options; do not treat a change of supplier as a reason to disable accounts indiscriminately.

Make the handover measurable

Agree who can authorize work during the transition, who receives user requests and who decides whether a change should proceed. Staff should know where to ask for help while the responsibilities move.

Choose acceptance checks that reflect the business: a user can sign in, an agreed application works, an expected message arrives, or a recovery test succeeds. Record what was tested, the result and any outstanding issue. A successful sample check supports a specific conclusion; it does not prove that every system will work under every condition.

Recovery deserves its own discussion. The Canadian Cyber Centre recommends backups of essential systems and recovery mechanisms that can restore them effectively. Ask what a proposed restore test will cover and who will act if it fails. Canadian Cyber Centre baseline controls.

The schedule should follow the work that is actually needed. A change of support contact and a migration of an application are different projects. Ask which activities could interrupt service, what alternatives exist and when a decision to stop or recover would be made.

Start with a conversation about the work

Vitosha Technologies can help define a technical review, implementation or transition project in French or English. That may involve Microsoft services, infrastructure, networking, migrations or recovery planning, with deliverables and availability agreed before work begins.

If you are considering a change, tell us what you want to improve, your timeframe and the team or provider already involved. We can discuss whether a focused project or a broader transition plan would be a useful next step.