Before switching IT providers, write down the decision you need to make: can the current arrangement meet the business's needs, or do you need a different one? A proposal from another provider can help explain an alternative. It does not, by itself, establish what went wrong with the current service.
What would justify changing your IT provider?
Consider replacement when you have documented failures against agreed commitments, an unresolved capability gap, or business needs the provider cannot meet. A correction with the current provider may be suitable when the problem is understood and there is a credible, testable plan to resolve it. You do not have to assume either outcome before examining the evidence.
| Your concern | Evidence to compare | What remains to establish |
|---|---|---|
| Slow responses | Ticket timestamps, priority definitions and agreed service hours | Were response commitments missed, or do the commitments no longer meet your needs? |
| The same fault returns | Incident records, proposed corrective work and approval history | Did agreed work fail, was it not completed, or was a proposed change declined? |
| Reports do not answer your questions | Reporting commitments and the reports supplied | Is promised evidence missing, or does the reporting scope need to change? |
| Costs are hard to explain | Invoices, contracted scope, quantities and approved changes | Are charges unsupported, quantities wrong, or different services being compared? |
Start with evaluating the provider you already have if you need help framing the delivery question. For a renewal decision, also check what to review before renewing your MSP contract. Work outside the contract can still be important to the business; identifying an exclusion does not make that need disappear.
When the same IT problem keeps returning
Choose the issue and period you want to examine. Record the dates, affected work and related ticket references. Ask the provider to explain what each closure status meant and what, if anything, was checked after the action. A status label alone does not establish that the underlying cause was identified or corrected.
A recurring-problem request you can adapt
Compare the reply with the service schedule, approval records and what your team observed. Keep a proposed fix, an approved action and a verified result as separate entries. Similar symptoms on different dates do not, by themselves, establish a shared cause.
| What the reply says | What to check next |
|---|---|
| Corrective work was proposed but not approved | Check what was proposed, who could approve it and whether it addressed the issue. Do not assume this explains every recurrence |
| The work is outside the agreement | Check the scope wording and clarify how the business need should be met |
| Agreed corrective work was completed | Ask for the action record and the check performed afterwards, including unresolved findings |
| The cause or next action remains unclear | Record the unanswered question, investigation owner and a suitable follow-up date |
If an action also appears in the monthly service report, compare its status with the ticket and approval records. Use the combined findings in the correction or replacement discussion below. Do not let a closed ticket or an unanswered question decide the whole case on its own.
Build a record you can use in the discussion
For each concern, record the business impact, the relevant commitment, the document requested, its date, what you checked and the next action. Keep a person and a follow-up date against unresolved items. This is a discussion record, not a numerical grade for your provider.
- Verified from evidence: record the specific observation and its limits. One ticket or test is not proof of all future performance.
- Reported but unverified: record what you have been told and what would substantiate it.
- Evidence not provided: identify what is missing and who can clarify it. Absence of a document alone does not prove a service failed.
- Outside agreed scope: record the exclusion and decide how the business need will be met.
Download the provider decision worksheet, a CSV file you can open in a spreadsheet. It includes an illustrative example and blank rows. Keep account credentials and sensitive client records out of the discussion summary. The useful output is a set of supported findings and open questions that the people responsible can act on.
Decide whether a correction is credible
Where a correction is appropriate, ask the provider to explain the issue, name the action owner and agree how completion will be demonstrated. Check whether the proposed work addresses the cause of the concern and whether it is within the agreed service or separately chargeable.
Repeated missed commitments, contradictory explanations or an inability to deliver a required service can support a decision to change. You do not need to offer an unlimited sequence of chances. An active security incident or service outage also needs an immediate operational response; do not defer that response to a renewal discussion.
Check these six handover requirements
If you are considering a move, ask both parties to identify the dependencies before agreeing dates. The Canadian Centre for Cyber Security's managed-services guidance covers access control, recovery and exit arrangements. Use those topics to frame questions that reflect your systems and contract.
- Ownership and control. Identify who holds the tenant, domain and supplier accounts, and how your organisation can retain access.
- Administrative access. Agree which authorised people need access during and after handover, how it will be transferred securely and when outgoing access will be removed.
- Documentation. List the inventories, configurations, system dependencies and vendor contacts needed by the incoming team, including anything still missing.
- Subscriptions. Check renewal commitments, transfer options and any services tied to the outgoing provider's agreement.
- Recovery. Establish access to backup data, usable export formats, retention arrangements and how restoration will be checked through the transition.
- Exit responsibilities. Review notice requirements, handover assistance, data return or deletion, charges and responsibility for each task. Resolve unclear terms before relying on them.
Write down the handover facts you cannot yet answer
Before giving notice, separate handover facts you can evidence today from those you only believe to be true. For each item in the list above, write the answer you would give a new provider, then name the document that supports it: an account inventory, a registrar record, an invoice, a contract clause or a written confirmation from the outgoing provider. Items with no supporting document are the gaps to close while the incumbent is still engaged.
One point is easy to leave unanswered: what happens to data the outgoing provider holds after the service ends. The Office of the Privacy Commissioner of Canada's guidance on assessing third-party service providers recommends confirming what happens to personal information held by a provider or its subcontractors once services are terminated, including how it is transferred back, the deletion methods used for anything remaining, and how it is disposed of. That guidance is addressed to organisations subject to PIPEDA and describes recommended practice, not a handover schedule for your contract.
Treat the reply as a statement of the provider's understanding, not as verified fact or as an expansion of your contract. Where the reply differs from the signed agreement, record both and decide which needs correcting before notice periods start. The OPC's accountability bulletin notes that an organisation is responsible for personal information in its possession or custody, including information transferred to a third party for processing, and that the bulletin offers guidance rather than binding legal interpretation.
If a question stays unanswered after a written request, that on its own does not establish that the record is missing or that the provider is at fault; a delayed or partial reply is consistent with several ordinary explanations, including workload, an unclear request or the answer sitting with a supplier. Record it as an open question with an owner and a date, and ask specifically who would hold the answer.
Compare the replacement against the problem
Take the same evidence record into the next proposal discussion. Use compare scope before price to distinguish included services, exclusions and assumptions. Ask how the proposed arrangement would address each unresolved need.
Agree the transition sequence, accountable people, continuity arrangements, costs and acceptance checks with the parties doing the work. Check these against your existing notice deadline. A period of overlap may help, but its duration and cost depend on the plan; it does not guarantee a successful handover.
When an independent review can help
A provider's assessment can be useful. Ask what evidence supports its findings and what services it is proposing to sell. Apply the same questions to an independent adviser: independence should be explained through commercial relationships and a clear scope, not assumed from a label.
actually. offers an independent review of evidence about your existing IT provider.
The review is a paid service.
Discuss the question and scope of the actually. review before deciding whether it fits the work you need.
