How to Audit Your Current MSP: A 10-Point Renewal Checklist

To audit your MSP before renewal, pull twelve months of ticket data, your asset register, every invoice, and your security baseline. Then test the provider against ten measurable points: SLA compliance, resolution times, security posture, licence usage, documentation, after-hours performance, strategic input, escalation, project scope, and communication quality. The gaps tell you whether to re-sign.

Most Melbourne SMEs renew their managed IT contract on autopilot. The invoice arrives, someone signs it, and another three years tick over. That’s how businesses end up paying for fifty Microsoft 365 licences when they have thirty-eight staff, or discover their “24/7 support” means a voicemail box until 8am.

This is a checklist you can run yourself before you put pen to paper on a renewal — or before you go to market. It applies to any provider, including us. If your current MSP can’t survive this audit, the renewal conversation should be a difficult one.

Why a pre-renewal audit matters

MSP contracts in Australia typically run two to three years. Over that time, staff numbers shift, software stacks change, security expectations rise, and the original scope drifts. The provider you signed with in 2023 isn’t necessarily the same operation in 2026 — engineers leave, tooling changes, and the founder who sold you the contract may not even be answering tickets anymore.

An audit gives you leverage. If you walk into renewal negotiations with twelve months of ticket data, a count of unused licences, and a list of unmet SLAs, you’re not arguing on vibes. You’re arguing on numbers. That changes the price, the scope, and often the provider.

We’ve done second-opinion audits for businesses in Hawthorn, Box Hill, and Dandenong South where the existing MSP had been billing for services they weren’t delivering for years. Nobody was being malicious — it’s just that nobody had checked.

Before you start: what to gather

You’ll need:

• The last 12 months of ticket exports (CSV from the MSP’s PSA — ConnectWise, Autotask, HaloPSA, Halo, whatever they run)
• Every invoice for the past 12 months, including any project or out-of-scope work
• The current Master Services Agreement and any Statements of Work
• The agreed SLA document
• Your current asset register (from the MSP)
• Your Microsoft 365 / Google Workspace admin centre access
• Any documentation the MSP has provided (network diagrams, runbooks, password vault structure)

If your MSP refuses to hand over ticket data or the asset register, that’s the first red flag — and probably the only audit point you need. The data is yours. They’re contracted to maintain it on your behalf.

The 10-point audit checklist

1. Pull real ticket data and check the numbers

What to pull: A CSV export of every ticket logged in the last 12 months, with fields for date opened, date closed, priority, category, time-to-first-response, time-to-resolution, and engineer assigned.

What to look for: Total ticket volume per user per month (a healthy environment runs 0.5 to 1.5 tickets per user per month — anything higher suggests unresolved root causes), category distribution (if 40% of tickets are password resets, you’ve got a self-service problem), and engineer concentration (are 80% of your tickets handled by one person who could leave tomorrow?).

Red flags: Ticket volume trending up over the year, repeat tickets on the same machine or user, tickets closed without resolution notes, or a single engineer carrying the entire account. Also watch for tickets being closed and immediately reopened — that’s a metrics game, not a fix.

2. Test SLA compliance against the contract

What to pull: Your signed SLA and the same 12 months of ticket data, filtered by priority.

What to look for: Calculate the percentage of P1, P2, P3 and P4 tickets that met the contracted response and resolution targets. If your contract says “P1 response within 15 minutes” and 30% of P1s took an hour, you have a breach pattern, not an exception.

Red flags: SLA compliance below 95% on any tier. Vague SLA definitions like “best efforts” or “as soon as practical” — those aren’t SLAs, they’re hedges. For reference, our standard P1 response sits under 15 minutes from our 24/7 NOC in Tecoma, with the SLA structure and credit terms documented on our pricing page. If your provider can’t show you a written SLA with credits attached, that’s a deeper problem.

3. Audit the asset register against your invoices

What to pull: The MSP’s asset register (every endpoint, server, switch, firewall, and licensed user) and your monthly invoices.

What to look for: Reconcile the number of billed devices and users against what’s actually deployed. If you’re paying per-device or per-user, you should be able to name every line item. We’ve seen Melbourne businesses paying for laptops that left with employees in 2022.

Red flags: Billed count exceeds physical count. Devices on the register that haven’t reported in for 90+ days (either decommissioned or unmanaged — both are problems). No documented onboarding/offboarding process for assets. Read our breakdown of how Australian MSPs structure billing for the trade-offs between per-user and per-device models.

4. Check security posture against current standards

What to pull: The Essential Eight maturity assessment (if your MSP has done one), your last vulnerability scan, MFA coverage report from Microsoft 365 or Google Workspace, endpoint detection coverage report, and patching compliance numbers.

What to look for: MFA on 100% of accounts (not 95% — the unprotected accounts are where attackers go). Endpoint protection deployed on every device including BYOD where applicable. Patching cycles documented with compliance rates above 95% for critical patches within 14 days. Privileged access reviewed quarterly.

Red flags: No documented Essential Eight position. No regular vulnerability scanning. Legacy protocols still enabled (SMBv1, basic auth on Exchange Online, NTLMv1). Local admin rights handed out to end users. An MSP that can’t tell you the security posture of your environment in concrete terms isn’t doing the work.

5. Audit licence usage versus licence cost

What to pull: Microsoft 365 admin centre user list (or Google Workspace equivalent), every other software subscription on the invoice (security tooling, backup, RMM), and a current staff list from HR.

What to look for: Unassigned licences, licences assigned to former staff, users on Business Premium who only need Business Standard, users on E3 who’d be fine on Business Premium. Backup licences for machines that no longer exist. We routinely find 10–20% of licence spend is dead weight.

Red flags: The MSP can’t produce a clean licence-to-user map. They’re billing you for licences they’re buying through their own CSP at a markup you can’t see. They’ve never proactively suggested a downgrade — only upgrades. This is one of the areas covered in detail in our piece on hidden costs Melbourne MSPs don’t disclose.

6. Review documentation completeness

What to pull: Every document the MSP holds about your environment — network diagrams, server inventory, application list, vendor contacts, line-of-business app runbooks, disaster recovery plan, password vault structure, and the offboarding playbook.

What to look for: A non-engineer should be able to follow the network diagram. The DR plan should specify RPO, RTO, and the exact steps to recover. Application runbooks should cover the quirks — the printer driver that needs a specific install order, the legacy app that breaks on Windows 11 24H2.

Red flags: Documentation last updated more than six months ago. Critical knowledge held in one engineer’s head. No documented DR plan or a plan that’s never been tested. If your MSP can’t hand you a portable, useful documentation pack, you don’t own your environment — they do. That’s a problem when you switch.

7. Check after-hours response performance

What to pull: Ticket data filtered for tickets logged outside 8am–6pm Monday to Friday, plus any after-hours phone records.

What to look for: Average response time for P1s logged at 2am. Whether a real engineer picked up or whether tickets sat until the next business day. Whether your contract specifies 24/7 coverage or only business hours.

Red flags: “24/7 support” that’s actually a triage line forwarded to an offshore call centre with no escalation authority. Long after-hours response times for outages that hit your operations. Our NOC runs 24/7 from Tecoma with the same 13 Australian engineers who handle daytime work — the model isn’t universal, so check what you’re actually getting.

8. Evaluate strategic input (the vCIO function)

What to pull: Meeting minutes or technical business reviews (TBRs) from the past 12 months, the current 3-year IT roadmap, and the budget forecast document.

What to look for: Quarterly business reviews with documented outcomes. A roadmap that ties IT to business goals (expansion, new sites, compliance requirements). Budget forecasts with capex and opex split out. Evidence the MSP is thinking about your business, not just closing tickets.

Red flags: No TBRs in the past year. No roadmap. The only strategic input is “you should buy more of what we sell.” If you’re paying a managed services fee and you’ve never had a strategy conversation, you’re paying for a help desk dressed up as a partnership.

9. Review project work scope creep

What to pull: Every Statement of Work or project quote from the past 24 months alongside the original signed scope.

What to look for: Projects that ballooned past the original quote. Recurring “small projects” that should have been included in the managed service fee (firewall firmware updates, mailbox migrations within the existing tenant, basic group policy changes). Whether the MSP is upselling projects to compensate for thin managed services margins.

Red flags: The total cost of “projects” exceeds 30% of the annual managed services spend. The same project type recurs (Microsoft 365 “optimisation” every six months — that should be ongoing, not a project). Hourly rates on projects that weren’t disclosed at contract signing. Compare your structure against the co-managed, fully managed, and internal IT models to see whether you’re paying twice for the same coverage.

10. Evaluate cultural fit and communication quality

What to pull: Sit down with three people in your business — someone in finance, someone in operations, and your most-frustrated end user.

What to look for: Do they know who to call? Do they get a human, or a ticket form? Do engineers turn up on site when needed, or is everything remote? Do you trust the team? Have engineers stayed across multiple years, or is there churn?

Red flags: Different engineer every ticket, no continuity. Account manager you’ve never met. Communication that comes across as scripted or defensive when issues are raised. An MSP that won’t show you their engineer retention numbers.

A concrete example: how this plays out

A 42-staff professional services firm in Camberwell ran this audit before their renewal last year. Their MSP had been quoting a 6% price increase. Here’s what the audit found:

They didn’t switch immediately — they put the findings to their MSP and renegotiated. Final outcome: 18% reduction in monthly fee, project work re-scoped into the managed contract, and quarterly TBRs reinstated. The audit took about two days of internal effort. The savings were $40K+ in year one.

Not every audit ends with a renegotiation. Sometimes the data is clean and the provider’s doing a good job. That’s a useful result too — you re-sign with confidence rather than out of inertia.

What to do with the findings

If the audit is clean: re-sign, but lock in the SLA credits and TBR cadence in writing. Don’t accept verbal promises.

If the audit shows fixable issues: book a meeting with the MSP, walk through the findings, and ask for a remediation plan with deadlines. Good providers will own the gaps and propose fixes. The reaction tells you whether the relationship is worth continuing.

If the audit shows systemic issues — missing documentation, security gaps, SLA breaches across the board — go to market. Issue an RFP to two or three providers and let the incumbent compete. Our team handles transitions like this regularly; the process is laid out in our managed IT services overview.

How TechAssist would look under this audit

We wrote this checklist knowing it’d be applied to us as well. For the record: we operate from Tecoma with a 24/7 NOC, 13 Australian engineers on staff, sub-15-minute P1 response as standard, per-user fixed monthly fee with no surprise project margins on in-scope work, quarterly TBRs built into every managed contract, and full documentation handover at any point on request. We’ve been doing this since 2014.

None of that means we’re the right fit for every Melbourne SME — we’re not. But the audit is the right way to figure out whether any MSP, us included, is doing what you’re paying them for.

If you want a second-opinion audit run by an MSP that isn’t your current one, give us a call on 1300 028 324 or drop us a line through the contact page. We’ll walk through the ten points with you, no charge for the initial conversation. If the result is that your current provider passes — great, re-sign and get on with running your business.

Frequently asked questions

How long does an MSP audit take?

Two to five working days of internal effort depending on the size of the environment. The data-gathering phase is the slow part — once you have the ticket exports, licence reports, and asset register, the analysis is a day or two for a 30–80 staff business.

Should I tell my current MSP I’m auditing them?

Yes. Frame it as renewal due diligence — most providers do this as standard for their own clients and will cooperate. If they push back on handing over ticket data, asset registers, or documentation, that itself is a finding. The data belongs to you under any reasonable contract.

What if I don’t have the technical skills to interpret the data?

Bring in a third party — either a tech-literate board member, an internal IT lead at another business you trust, or a competing MSP offering a second-opinion audit. Most reputable Melbourne MSPs will do an initial review at no charge as part of a sales conversation. Just be aware they have a commercial interest in the result.

How often should I audit my MSP?

A full audit at every renewal (every two to three years). A lightweight check — licence reconciliation, SLA compliance, ticket volume trends — every six months. If your business goes through significant change (acquisition, new site, headcount jump), audit at that point too.

What’s the difference between an audit and a vCIO review?

A vCIO review is forward-looking — it’s about strategy, roadmap, and budget. An audit is backward-looking — it’s about whether the past 12 months of service matched the contract. You need both, and they shouldn’t be done by the same provider if you want them to be honest.

Switching MSPs is a documentation problem dressed up as a technical one. Get the paperwork right in the first three weeks and the cutover is uneventful. Get it wrong and you’ll spend month two chasing passwords. This is the 90-day playbook we use when onboarding Melbourne SMEs leaving another provider.

The post assumes you’ve already made the call. You’re not weighing up how to choose an MSP in Melbourne — you’ve chosen. What you need now is execution: a sequence of decisions and handover tasks that gets you out of the old contract cleanly and into the new one with your data, your tenant control and your sanity intact.

The three decisions you settle before day zero

Most failed MSP migrations fail before they start, because the incoming provider was handed a vague brief and the outgoing one was given a vague deadline. Settle these three things in writing before the 90-day clock begins.

1. What’s in scope and what isn’t

Re-scope from scratch. Don’t inherit your old MSP’s scope document — it was almost certainly written to suit their staffing, not your needs. Walk through every endpoint, every server, every SaaS tenant, every printer, every meeting room, every shadow-IT app the finance team has been quietly paying for, and decide: managed, co-managed, or out-of-scope.

The honest answer for most Melbourne SMEs sits somewhere between fully managed and co-managed IT support, where the internal champion keeps the institutional knowledge and the MSP handles the heavy lifting. Decide which model you want before you sign, because it changes the SLA, the pricing and the documentation burden on day one.

2. The transition window

Pick the date the outgoing MSP’s responsibility ends, and pick it carefully. Don’t end it on a Friday. Don’t end it the day before a board meeting, end-of-month payroll, or a public holiday long weekend. We strongly prefer mid-week, mid-month cutovers — usually a Wednesday — so there’s time on either side to fix anything weird without burning a weekend.

Build a 30-day parallel-running window into the contract if you can. Some outgoing MSPs will fight this; their commercial incentive is to be gone the moment the notice period ends. Push back. A parallel period — where they still answer P1 tickets while the new provider takes over documentation and tooling — is the single biggest predictor of a clean switch.

3. Who owns the data, the tenant, and the licences

This is the conversation that exposes the bad MSPs. If your current provider’s name is on your Microsoft 365 tenant as the global admin owner, on your domain registrar account, on your backup vendor’s portal, or on your CSP partner record — you have a problem, and you need to fix it before you give notice. Not after.

Your business should own:

• The Microsoft 365 tenant, with at least two break-glass global admin accounts that belong to your staff, not the MSP
• The domain registrar account (and DNS, if it’s separate)
• Any CSP relationship and the licences attached to it — these can be transferred between partners but only if the outgoing one cooperates
• Your backup data and the keys/credentials to access it directly
• Firewall and switch admin accounts, with documented passwords held by you

If you can’t tick all of those today, the first month of your 90-day plan is going to be about clawing them back. That’s normal. It just needs to be planned for.

Days 0-30: onboarding, documentation, and the quiet panic

The first month is unglamorous. It’s spreadsheets, screenshots, audit logs and asset lists. Resist the temptation to start changing things — the new MSP’s job in month one is to learn your environment, not improve it.

What to demand from the outgoing MSP

Send this list in writing on day one. Give them fourteen days. Escalate to their account manager on day fifteen.

If the outgoing MSP refuses any of the above, you have a documentation problem and possibly a contract problem. Read your exit clause carefully — most decent MSP agreements include a transition cooperation obligation, even if it’s buried. If yours doesn’t, that’s a lesson for the new contract.

Vendor relationship transfers

Microsoft is the big one. If your licences sit under the outgoing MSP’s CSP tenant, you have three options: transfer the CSP relationship to your new MSP (cleanest, but needs both providers to cooperate), move to direct billing with Microsoft (clean break, but you lose any CSP discount and pick up admin overhead), or run a fresh CSP relationship in parallel and migrate users across. Most of our incoming clients choose option one. It takes about ten business days when both sides play ball, and four weeks of pain when they don’t.

Cisco Meraki, Datto, Veeam, NinjaOne, Ahsay, SentinelOne, Huntress — anything with a partner portal — works the same way. Each vendor has its own re-assignment process, each takes a different amount of time, and each one needs the outgoing partner’s sign-off. Map every vendor relationship in week one. Start the transfer requests in week two. By week four, most should be done.

The “who do I call now?” comms plan

Your staff don’t care about your CSP transfer. They care about who picks up the phone when Outlook stops working. Two communications go out in the first week of the new MSP relationship:

Internal staff comms — short, plain, on a single page. New helpdesk email, new phone number, what counts as a P1 (and what to do about it after hours), and a one-line reassurance that nothing else is changing yet. Keep it under 200 words. Pin it in Teams. Print it for the front desk.

Vendor and partner comms — a separate note to your accountant, your auditor, your software vendors and your ISP, telling them who the new IT provider is and giving them updated contact details. Five emails, fifteen minutes, saves a week of confused calls in month two.

At TechAssist, this is the part we drive hardest in week one. Our managed IT services onboarding kicks off with a comms pack the client can send out the same afternoon they sign — because the technical handover takes weeks, but the staff experience changes the moment someone needs help.

Days 31-60: cutover, validation, and finding the lies

Month two is where the previous MSP’s documentation gets tested against reality. It’s also where you migrate the systems they were responsible for — backups, monitoring, ticketing, security tooling — and where things go wrong if anyone rushed month one.

Backup and DR migration

Don’t decommission the old backup until the new one has completed a full successful cycle and a test restore. That sounds obvious. It is regularly ignored.

The order we use:

1. New backup platform deployed and configured in parallel — Veeam, Datto, Ahsay, whatever the new MSP standardises on. Old backups continue running untouched.
2. First full backup completes successfully on the new platform. Verify the job logs, not just the dashboard summary.
3. Test restore performed — not a “we restored a file” test, an actual rebuild of a representative VM or mailbox to an isolated environment, with the client present.
4. Second successful cycle.
5. Old backup retention frozen (don’t delete — freeze) for a minimum of 90 days after cutover. This is your safety net if a corruption is discovered later.
6. Old backup agents removed from production endpoints.

Do not skip the test restore step. We have seen handovers where the outgoing MSP’s backup dashboard was green every day for two years and nothing was actually being captured beyond the C: drive. The only way to find that out is to try to restore something that matters.

Monitoring and ticketing platform switch

The new RMM agent goes on every endpoint in month two. So does the new ticketing system’s email connector. The old RMM and ticketing email stay live in parallel until day 60, then come down.

Two specific gotchas. First, antivirus and EDR conflicts — running SentinelOne alongside Defender for Business alongside the outgoing MSP’s Webroot deployment will cause genuine performance issues and false positives. Plan the security tool swap as a single coordinated change, not a gradual rollout. Second, RMM agent collisions on shared resources, especially scheduled tasks and Windows Update behaviour. Audit scheduled tasks after the new agent is in place; you’ll usually find three or four orphaned jobs from the previous provider that nobody removed.

Security baseline reassessment

Month two is the right time to ask “is the security posture we inherited actually any good?” — and to answer it honestly. Run a fresh baseline: MFA coverage across all accounts (not just users — service accounts, break-glass, admin), conditional access policies, Defender for Office 365 settings, Entra ID logs, privileged role assignments, and external sharing settings on SharePoint and OneDrive.

It is not unusual to find that the outgoing MSP had MFA enforced for staff but not for the three service accounts that authenticate to line-of-business apps. It’s almost universal to find at least one privileged role assignment that should have been removed when someone left the business two years ago. Fix these before they bite you.

A concrete example

A South Yarra logistics firm — around 45 staff, two warehouses, a fleet of about thirty vehicles — switched to us in Q3 2025 after their previous MSP missed two P1 outages in a single quarter. The pre-switch audit found that the firm’s Microsoft 365 tenant had the outgoing MSP listed as the primary CSP partner with sole global admin rights, no break-glass accounts owned by the client, and the domain registrar account was registered to a personal Gmail address belonging to the outgoing MSP’s former tech lead, who had left that business eighteen months earlier.

Reclaiming the tenant took twelve business days and a Microsoft support case. Reclaiming the domain took a further three weeks and required a notarised letter of authority. None of this was technically complex. All of it was the documentation problem this post keeps banging on about. By day 60 the firm was fully migrated, with a backup regime that actually included their warehouse management database (the previous one did not), and a per-user fixed monthly fee they could budget against. The first three months of tickets came in under our standard sub-15-minute P1 response, and the on-site work — including a Wi-Fi controller swap at the Port Melbourne warehouse — was handled same-business-day from our Tecoma NOC.

Days 61-90: stabilise, verify, and close the door

The final month is about proving the new arrangement works and shutting down the old one for good.

SLA verification with real tickets

By day 60 you should have enough ticket history with the new MSP to verify what they promised against what they’re actually delivering. Run a report. Not the MSP’s report — your own pivot of the ticket data, exported. Look at:

• P1 response time, mean and 95th percentile (not just the average — averages hide the bad ones)
• P2 and P3 resolution time against SLA
• Tickets reopened within seven days (a proxy for “fixed it properly the first time”)
• After-hours ticket coverage, if you pay for it
• On-site response time for the tickets that needed it

If something’s off, raise it at the day-90 review, in writing, with the numbers. A good MSP will look at the same data and either explain it or fix it. A bad one will tell you the dashboard says everything’s fine.

Final removal of outgoing MSP access

Day 75 is the audit. Every system, every portal, every shared mailbox, every Teams channel, every PSA integration — does the outgoing MSP still have a way in? They almost always do. The common ones we find at this stage:

• An old Entra ID guest account still active
• A service principal or app registration created during their tenure with broad Graph permissions
• A VPN account that wasn’t disabled
• A shared admin email forwarder that still copies to their helpdesk
• RMM agent remnants on one or two endpoints that were offline during the rollout
• Their public IP still in your firewall allowlist for “remote support”

Close them all. Document who closed each one and when. This isn’t paranoia — it’s basic hygiene and it’s increasingly a requirement of cyber insurance renewals.

The post-mortem with the new MSP

Day 90 isn’t a celebration, it’s a review meeting. The honest version of this conversation includes “what wasn’t documented that we wish had been,” “what surprised us in the environment,” and “what we’d do differently if we did this again.” If your new MSP can’t have that conversation, they’re not the right MSP. If you don’t have it, you’ll repeat the same mistakes in three years when you switch again.

Red flags from outgoing MSPs

Some MSP handovers go badly because the outgoing provider is genuinely overstretched. Some go badly because they’re being hostile. It helps to know which one you’re dealing with.

The single best defence against a hostile handover is having owned your own tenant from day one. If you’ve already given notice and you don’t own it, the first phone call is to Microsoft (or the relevant vendor) to start the partner-of-record change, not to the outgoing MSP.

What a good incoming MSP actually does in the first 90 days

To set expectations on the other side of the table — here’s what we do when a Melbourne SME signs with us. We’ve been doing this since 2014 and we’ve refined the playbook through several dozen migrations across industries from logistics to professional services to manufacturing.

Week one is documentation and access. Our onboarding engineer (not a salesperson) sits with the client’s internal champion, sometimes at our Tecoma office, sometimes at our 575 Bourke Street CBD office, sometimes on-site at the client. We work through the artefact checklist above and we don’t leave the room until either we have the documents or we have a written commitment from the outgoing MSP on when we’ll have them.

Week two and three is monitoring and tooling deployment in parallel — we don’t switch off anything the outgoing MSP is doing yet. Our NOC at Tecoma picks up alerting; the outgoing MSP’s RMM keeps running until day 30.

Week four is the comms switch. The client’s staff get the new helpdesk details. Our sub-15-minute P1 response and same-business-day on-site for Melbourne metro becomes the standard. Per-user fixed monthly pricing kicks in — no hourly billing for anything that was in the agreed scope, which removes the awkward “should I log this ticket?” decision for the client’s staff.

Weeks five through eight are the technical migrations — backups, security tooling, the harder vendor transfers. Weeks nine through twelve are stabilisation and the day-90 review.

That’s it. It’s not glamorous. It works because the order is right and because the people doing it have done it before. Our thirteen engineers are all Australian-employed and most of them have been with us long enough to have run this playbook a dozen times. If you’re comparing providers and want a longer reference list, our writeup on the top managed service providers in Melbourne covers what to look for in this stage of the conversation.

FAQ

How long does switching MSPs actually take?

From signed contract to fully decommissioned previous provider, plan for 90 days. The technical work is usually done in 45-60 days; the remaining time is SLA verification, security baseline review, and the final access cleanup. Smaller environments (under 25 staff, no on-premises servers, clean Microsoft 365 tenant) can be done in 45 days. Larger or more complex environments, or anywhere with a hostile outgoing provider, can stretch to 120 days.

Will my staff be without IT support during the switch?

No — not if it’s run properly. The whole point of the parallel-running window in the first 30 days is that the outgoing MSP keeps handling P1 tickets while the incoming MSP takes over documentation and tooling. By day 30 the new provider is taking everything. There should be no period where nobody is on the hook.

What happens if the outgoing MSP won’t hand over passwords or admin access?

Read your contract first — most MSP agreements include a transition cooperation clause, and a written reminder of it usually unlocks the handover within a week. If that doesn’t work, the vendors themselves (Microsoft, your domain registrar, your backup vendor) have partner-of-record change processes that don’t require the outgoing MSP’s consent, though they take longer. As a last resort, a letter from your solicitor referencing the contract terms is usually sufficient. We’ve never had to go further than that.

Do I have to migrate to my new MSP’s preferred tools?

Mostly, yes — and that’s usually fine. MSPs deliver SLAs through standardised tooling; if every client runs different backup, monitoring and security stacks, the response times suffer and the cost goes up. The exception is line-of-business software, which obviously stays where it is. If your new MSP insists on swapping out a working line-of-business system as part of onboarding, push back hard — that’s a separate project.

Can I keep some IT in-house and outsource the rest?

Yes, and for a lot of Melbourne SMEs this is the right model. Co-managed arrangements where an internal IT person or small team handles day-to-day requests and strategic projects, and the MSP handles the NOC, helpdesk overflow, after-hours and specialist work, tend to give the best outcome per dollar spent. The 90-day playbook above works the same way; the scope conversation in the pre-switch phase is just more detailed.

What’s a reasonable price to pay during the transition?

You’ll likely pay both MSPs for the first 30-45 days — the old one on the existing contract, the new one on a reduced onboarding fee or a ramped-up monthly. Budget for it. Trying to avoid the overlap by ending the old contract early is where most failed migrations start. The overlap cost is small compared to the cost of a botched cutover.

How do I know if the new MSP is actually any better?

Real ticket data at day 90. Not testimonials, not the sales pitch, not the dashboard the MSP shows you — your own export of the ticket history, with response and resolution times against the SLA you signed. If the numbers are good, you’re in the right place. If they’re not, you have the conversation early, when it’s still fixable.

If you’re partway through this decision and want a second opinion on the pre-switch audit — particularly the tenant ownership and vendor relationship pieces, which are where the worst surprises live — get in touch. An hour on the phone before you give notice saves a fortnight in month two.