Switching MSPs: The 90-Day Migration Playbook for Melbourne SMEs

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.

An AI acceptable use policy tells your staff which AI tools they can use, what they can paste in, and what happens when somebody pastes the wrong thing. For a Melbourne SME it is now a baseline governance document, sitting next to your password policy and breach response plan. Write it before something goes wrong.

We have spent the last eighteen months helping clients across construction, accounting, law, and healthcare write and roll these out. The pattern is consistent: people are already using ChatGPT and Copilot on company data, leadership has no visibility, and nobody can articulate the rules because there are no rules. This post is the practical guide to fixing that.

Why every Melbourne SME needs an AI acceptable use policy by 2026

The regulatory ground has shifted under Australian businesses in the last twelve months. The Privacy and Other Legislation Amendment Act 2024 introduced a statutory tort for serious invasions of privacy, expanded the Australian Information Commissioner’s enforcement powers, and brought in tiered civil penalties. The reforms are being rolled out in tranches through 2025 and 2026, and the OAIC has explicitly signalled AI-related privacy practices as a focus area.

The OAIC’s guidance on generative AI, published in October 2024, is unambiguous on three points. Personal information entered as a prompt triggers Australian Privacy Principle obligations. Organisations should not enter personal or sensitive information into publicly available generative AI tools by default. Organisations need policies and staff training, not just technical controls. If your business hits the $3 million annual turnover threshold and you do not have a documented position on AI tool usage, you are exposed.

Then there is the insurance side, which is the conversation that usually focuses minds. Most professional indemnity and cyber insurers renewing policies in 2025 and 2026 are asking specific questions about AI usage and whether the insured has an acceptable use policy in place. Answering “no” is not yet a coverage exclusion, but it is increasingly a premium loading factor and, in the event of a claim involving AI-assisted error, a question your broker would rather not have to answer for you.

A Hawthorn accounting firm we onboarded earlier this year discovered, during the initial security review, that two of their senior accountants had been pasting client trial balances into ChatGPT to draft management reports. The data was technically anonymised, but client revenue figures, GST positions, and director loan accounts were sitting in OpenAI’s training-eligible consumer tier. There was no malice and no policy. The partners had not realised what their staff were doing because nobody had told the staff what they could or could not do. The remediation took a fortnight. The conversation with their PI insurer took considerably longer.

What an AI acceptable use policy should actually contain

A workable AI AUP for a Melbourne SME runs to about eight to twelve pages. Anything shorter is a marketing document; anything longer will not be read. We structure ours around nine sections, and the framing matters — the document should read as a set of practical rules with reasons attached, not as a legal artefact that requires a lawyer to interpret.

Sample wording: Acceptable uses

This is the section that tells staff what AI is for. Get this right and the rest of the policy reads as enabling rather than restrictive. Sample wording:

Staff are encouraged to use approved AI tools to: draft and refine internal communications; summarise long documents that the staff member has the right to access; generate first-draft code, scripts, and spreadsheet formulas; brainstorm options and structure arguments; translate text where no client-confidential content is involved; transcribe and summarise meetings where all participants have consented and the meeting platform’s AI features have been approved. The expectation is that AI accelerates work; the staff member remains accountable for the output.

Sample wording: Prohibited inputs

This is the section that does the heaviest lifting. Be specific. Vague prohibitions (“do not enter sensitive data”) are unenforceable because nobody agrees on what sensitive means. Sample wording:

The following must never be entered into any AI tool, regardless of tier, unless the tool is explicitly listed as approved for that data type in the tools register: full names combined with any other identifier of clients, patients, students, or staff; financial account numbers, credit card numbers, or tax file numbers; health information of any kind; legal advice received from the firm’s solicitors; commercially sensitive information about live tenders, M&A activity, or unannounced pricing changes; passwords, API keys, certificates, or any other authentication material; source code that the company does not own or that is covered by a non-disclosure agreement; CCTV footage, voice recordings, or biometric data.

Sample wording: Data handling for client information

This is where most policies fall over because the authors try to write a single rule that covers all client data. It does not work. The cleaner approach is to define tiers and map tools to tiers. Sample wording:

Client information is classified into three tiers. Tier 1 is publicly available information about the client (their published address, their listed directors, their ABN); this may be used with any approved AI tool. Tier 2 is non-public but non-sensitive client information (meeting notes, project plans, draft scopes of work); this may only be used with AI tools running in the company’s Microsoft 365 tenancy or other approved enterprise tenancies, and only where the client engagement letter does not prohibit it. Tier 3 is confidential or regulated client information (financial records, legal matters, health records, personally identifying details of the client’s customers or staff); this must not be entered into any AI tool without written authorisation from the engagement partner and, where required, the client.

Tool-by-tool guidance: where the data actually goes

The single most useful section of an AI AUP, in our experience, is the per-tool guidance. Staff do not care about abstractions; they care about whether they can use the specific tool that is open on their screen. The honest answer for each major tool depends on which tier you are on, and most staff have no idea what tier their employer is paying for.

ChatGPT

The free and ChatGPT Plus consumer tiers train on user inputs by default unless the user opts out, and they sit outside any contractual arrangement your business has with OpenAI. These tiers should be in the prohibited column for anything beyond Tier 1 client information. ChatGPT Team and ChatGPT Enterprise do not train on business data and offer SAML SSO, audit logs, and data residency commitments. If your business has a Team or Enterprise subscription, ChatGPT can be used for Tier 1 and Tier 2 client data. The policy should state which tier the business holds and forbid use of personal ChatGPT accounts for work purposes.

Microsoft Copilot

This is where most policies get muddled because Microsoft uses the word “Copilot” for at least four different products. Microsoft 365 Copilot, included as a per-user licence on top of a Business Standard or Premium subscription, runs against your Microsoft 365 tenancy, respects your existing SharePoint and OneDrive permissions, and does not train on your data. It is generally safe for Tier 1 and Tier 2 data, with the important caveat that Copilot will surface anything a user has permission to access — so an oversharing problem in SharePoint becomes a Copilot problem the day you turn it on. Copilot Chat (the free tier formerly known as Bing Chat Enterprise) offers commercial data protection but does not access tenancy data. GitHub Copilot is a separate product with its own data handling. Copilot in Windows is a Bing-backed consumer experience and should be treated like consumer ChatGPT.

Claude

Anthropic’s consumer Claude.ai free and Pro tiers do not train on user conversations by default, which puts Claude in a better starting position than consumer ChatGPT, but the consumer terms still apply and the data sits outside any business agreement. Claude for Work (Team and Enterprise) provides the contractual framework, SSO, and admin controls that make it viable for Tier 2 client data. Claude is also available via Amazon Bedrock and Google Cloud, which is the route most regulated Australian businesses take because it keeps data within a known cloud tenancy.

Gemini

Gemini in a personal Google account trains on user data and should be treated as prohibited for anything beyond Tier 1. Gemini for Google Workspace, included with Business and Enterprise Workspace plans, does not train on customer data and respects Workspace permissions in the same way Microsoft 365 Copilot respects SharePoint permissions. Gemini in Google AI Studio with a paid API key has its own data handling terms that need to be read separately. The policy should be explicit that the consumer Gemini at gemini.google.com is a different product from Gemini inside Gmail and Docs at a business domain.

Industry-specific clauses you will need

The base policy works for most professional services businesses. Specific industries need extra clauses, and we add these as numbered addenda rather than rewriting the body of the policy.

Law firms

Solicitors have legal professional privilege obligations that are not negotiable. The addendum should prohibit entering any communication with a client, any document prepared in contemplation of litigation, and any matter file content into any AI tool that is not covered by an enterprise agreement with explicit confidentiality provisions. It should require that any AI-assisted drafting is reviewed by the responsible practitioner before it leaves the firm, and that any use of AI in advice given to the client is disclosed in accordance with the firm’s cost agreement. The Victorian Legal Services Board has not yet mandated AI disclosure, but it has signalled that practitioners remain wholly responsible for AI-assisted work, and firms should not wait for prescriptive guidance before tightening their own rules.

Accountants and bookkeepers

The APES 110 Code of Ethics covers confidentiality of client information without any AI-specific carve-out, which means client financial data going into a consumer AI tool is a Code breach regardless of intent. The addendum should prohibit entering client financial records, BAS data, payroll data, or trust account information into any tool not in the approved enterprise tier. It should also address the AI-generated advice question directly: AI output that materially informs advice given to a client must be reviewed and signed off by a qualified accountant, and the firm’s engagement letters should be updated to disclose the use of AI tools in the engagement.

Healthcare providers

Health information is sensitive information under the Privacy Act and attracts stricter handling. The addendum should prohibit entering any patient-identifying information, clinical notes, imaging, pathology, or Medicare numbers into any AI tool that is not specifically approved for health data — which, in practice, means almost none of the consumer or general-business AI tools qualify. Practices using AI scribing tools (Heidi, Lyrebird, and similar) need to verify the vendor’s data residency, ensure the tool has been assessed against the practice’s privacy obligations, and obtain patient consent in line with RACGP guidance.

How to roll it out without it becoming shelfware

Writing the policy is the easy part. The hard part is getting it adopted, and the failure mode we see most often is a policy that gets emailed to all staff once, signed in a hurry, and never referenced again. The rollout that actually works follows a sequence.

Stakeholder sign-off comes first, and it should involve more people than you think. The owner or managing director signs as the policy sponsor. The person responsible for IT — whether that is an internal IT manager or your managed service provider — signs as the technical owner. Heads of regulated practice areas sign because they will be enforcing the industry addenda. HR signs because policy breaches feed into the disciplinary process. Send a copy to your external auditor or PI broker before publication, because their later approval is much easier than their retrospective objection.

The training session is non-negotiable. A thirty-minute, in-person or video, all-staff session works better than any e-learning module. The session should cover the three or four scenarios staff will actually encounter — drafting an email, summarising a meeting, writing a report — and walk through what is and is not allowed in each. The session should be recorded for new starters and run again, in a different month, for staff who missed it. Sign-on after the training, not before.

Monitoring is where most SMEs hand-wave, and it is also where insurers are increasingly looking. Microsoft 365 and Google Workspace both expose audit logs that show Copilot and Gemini usage, and Defender for Cloud Apps (or its equivalent) can detect personal AI tool usage on managed devices. Endpoint DLP can flag attempts to paste large blocks of text into browser tabs. None of these are perfect; all of them are better than nothing. A quarterly review of the approved tools register, with input from team leaders on what their staff are actually using, catches the drift that always happens between policy and practice.

Breach consequences should be proportionate and documented. We recommend a three-tier framing: a first-time minor breach (using a non-approved tool for low-sensitivity work) results in a refresher conversation and a documented note. A repeat or moderate breach (entering Tier 2 data into a consumer tool, or ignoring the approved tools register after training) results in a formal warning and remedial training. A serious breach (entering Tier 3 data, or any breach involving client personal information) triggers the data breach response process, an incident review, and the disciplinary procedures set out in the staff handbook. The point of writing this down is so the response to a breach is predictable rather than political.

Aligning the policy with broader security frameworks is the step most SMEs skip and most insurers are starting to ask about. Our policies are Essential Eight aligned because that is the baseline the Australian Cyber Security Centre expects of Australian SMEs, and because the application control and user application hardening strategies map directly to the question of which AI tools staff can run. For clients pursuing ISO 27001 certification, the AI AUP slots into the Annex A control set under information security policies and acceptable use. For clients moving toward zero trust, the per-tool tenancy rules in the AI AUP are an expression of the same conditional access principle.

A worked example: rolling out the policy at a Box Hill professional services firm

A forty-seat professional services firm in Box Hill — a mix of consulting and accounting work — engaged us last spring to write and roll out their AI AUP. The starting position was familiar: the principals knew staff were using ChatGPT, had no idea what data was going into it, and had just received a renewal questionnaire from their PI insurer with an AI governance section.

Week one was discovery. We ran a short survey, anonymous, asking staff which AI tools they used at work and for what tasks. Eighty per cent of staff used ChatGPT; about half used the personal Plus tier; one team had standardised on Claude. Nobody used Copilot, despite the firm holding Microsoft 365 Business Premium licences that included Copilot Chat. The discovery surfaced two specific risks: confidential client correspondence being summarised in consumer ChatGPT, and the firm’s internal financial reports being pasted into Claude for variance commentary.

Week two was the policy draft. We started from our template, customised the tools register for the firm’s environment (Microsoft 365, Xero, a practice management system), and added the accounting industry addendum. A working session with the principals and practice manager surfaced three changes: a carve-out for AI use in business development, a stricter rule on AI-generated client deliverables, and a thirty-day transition clause to move off personal AI accounts.

Week three was the rollout. A forty-five minute all-staff session walked through the policy with three worked scenarios. Microsoft 365 Copilot was enabled for a pilot group, and the firm subscribed to ChatGPT Team for the consultants who needed it. Signed acknowledgements were collected through the firm’s HR system.

The first quarterly review, ninety days in, found that two staff had requested additional tools (one approved, one not), one minor breach had occurred and been handled through a refresher conversation, and Copilot adoption had reached seventy per cent of licensed users. The renewal questionnaire was answered honestly, and the broker confirmed the policy met the insurer’s expectations. The principals would tell you the value was less in the document itself and more in the conversation the rollout forced — shadow IT became part of the supported environment, and they got visibility into how the firm was actually working.

What to do this week if you do not have a policy yet

If your business is in the Melbourne CBD, Camberwell, Dandenong, Richmond, or anywhere else in greater Melbourne, and you do not have an AI acceptable use policy, the practical next steps are straightforward. Run an anonymous staff survey to find out what AI tools are actually being used. Audit your existing Microsoft 365 or Google Workspace licences to find out what AI features you are already paying for. Identify the three to five regulated obligations specific to your industry (privacy, professional standards, sector-specific rules) that the policy needs to address. Draft the policy or have it drafted, run a training session, and put a quarterly review in your calendar.

TechAssist has been doing this work for Melbourne SMEs since we started the firm in 2014. We run a thirteen-engineer team out of our offices in Tecoma and the Melbourne CBD at 575 Bourke Street, with our 24/7 network operations centre in Tecoma. Our cybersecurity services include AI governance work as a defined engagement, and our broader managed IT services sit underneath it for clients who want the policy enforcement to be technically backed by their managed environment. We work with construction firms, law practices, accounting partnerships, healthcare clinics, schools, manufacturers, and logistics businesses across Melbourne, and the AI AUP looks different in each of those industries — which is part of the work.

If you want a starting point, the Privacy Act guidance for Australian SMBs is a useful companion read because the AI AUP sits on top of the Privacy Act compliance posture. If you have an internal IT lead and want help on the governance side without handing over the day-to-day, our co-managed IT support arrangement is the right shape. If you want a conversation about where to start, get in touch and we will book a thirty-minute call with one of our senior engineers.

Frequently Asked Questions

Is an AI acceptable use policy legally required in Australia?

There is no specific Australian law that mandates an AI AUP by name. However, the Privacy Act, the OAIC’s generative AI guidance, professional standards in regulated industries (legal, accounting, medical), and increasingly the terms of professional indemnity and cyber insurance policies all create a practical requirement. If you handle personal information and you do not have a documented position on AI tool usage, you are exposed under the existing legal framework.

How long should an AI acceptable use policy be?

Eight to twelve pages is the sweet spot for an SME. Shorter than that and you cannot cover the per-tool guidance and industry addenda that make the policy useful. Longer than that and staff stop reading. The approved tools register and industry addenda are the sections that should grow over time; the body of the policy should stay stable.

Can we just use a generic AI AUP template from the internet?

You can start with one, but you will need to do real customisation work. Generic templates do not know which AI licences you actually hold, which industry you are in, what your data classification scheme looks like, or how your disciplinary process works. The cost of poor customisation is a policy that does not match your environment, which makes enforcement impossible and gives staff a reason to ignore it.

How often should the policy be reviewed?

The body of the policy should be reviewed annually. The approved tools register should be reviewed quarterly, because the AI tool landscape moves fast enough that a six-month-old tools register is already out of date. We bake the quarterly review into our managed services engagements so it does not get forgotten.

What if a staff member breaches the policy?

The policy itself should set out a tiered response: a documented conversation and refresher training for a first-time minor breach, a formal warning for a repeat or moderate breach, and the data breach response process plus disciplinary procedures for a serious breach involving client or personal information. The point is to make the response predictable and proportionate, so that the first breach does not become a political event.

Does the policy cover AI features built into tools we already use?

It should. AI features built into Microsoft 365, Google Workspace, Adobe products, Zoom, Teams, Atlassian tools, and any other SaaS your business uses are all in scope. The approved tools register should list them explicitly, including which features are enabled and which are turned off at the tenancy level. The default position should be that an AI feature is prohibited until it has been assessed and added to the register.

Should we tell our clients we use AI in our work?

For most professional services engagements, yes. The cleanest approach is to update your engagement letters with a short clause disclosing that the firm uses approved AI tools to assist with work, that human review remains with the qualified practitioner, and that no client confidential information is entered into any AI tool that does not meet the firm’s data handling standards. Several professional standards bodies are moving toward this disclosure as an expectation, and it is easier to lead than to be caught out.

Before 30 June 2026, Melbourne SMEs should verify backups, reconcile the IT asset register with finance, audit software licences, decide on any pre-EOFY hardware purchases with your accountant, and decommission anything you’re paying for but not using. The rest is detail.

EOFY isn’t just a tax event. For most Melbourne businesses we look after, it’s the one time of year where finance and IT actually sit down together and tally up what’s been bought, what’s been retired, what’s still being paid for, and what needs replacing. If you skip that conversation, you end up paying for ghost subscriptions in July, missing depreciation entries in August, and scrambling to buy laptops in September when supply tightens.

This EOFY IT checklist is the same one our engineers run with clients across Hawthorn, Box Hill, Dandenong and the CBD every June. It mixes operational housekeeping with the finance-side items your bookkeeper or CFO will thank you for. Nothing fancy. Just the stuff that actually moves the needle before the books close.

Why EOFY matters for IT, not just finance

Two reasons. First, your tech estate drifts over a year. People leave, projects start and stall, trials become forgotten subscriptions, and hardware quietly ages past its useful life. EOFY is a natural forcing function to clean that up. Second, if you’re planning capital spend on technology, the timing of the purchase, the install, and the in-service date can matter for how your accountant treats it. We don’t give tax advice, but we do give you a clean asset list and accurate purchase dates so your accountant can do their job properly.

A Hawthorn accounting firm we work with had 47 active Microsoft 365 licences on the books in May last year. After we ran their EOFY audit, the real headcount needing licences was 38. Nine licences at $30+/month each had been quietly billing since two staff turnovers and a contractor project that wrapped in October. That’s around $3,200 a year in pure waste, caught in a 90-minute review.

The EOFY IT checklist: 10 items to work through before 30 June 2026

Work through these in order. Most can be done in a single afternoon with your IT provider; a few need finance involvement. If you’re a TechAssist managed client, your account engineer will already have most of this scheduled into your June service calendar.

1. Verify your backups actually restore

Having backups isn’t the same as having recoverable data. Before 30 June, pick at least one critical system (your file server, your accounting database, your shared mailbox) and do a test restore to an isolated location. Time how long it takes. Compare that to your recovery time objective. If you don’t have an RTO documented, this is the moment to write one down.

We see at least two or three clients a year discover their “working” backups had been silently failing for weeks because nobody read the alert emails. A test restore is the only proof that matters. More on our approach at data backup and recovery.

2. Reconcile the IT asset register with finance

Your finance team has a fixed asset register. Your IT provider has an inventory list. These almost never match. EOFY is when you sit them next to each other and resolve every discrepancy: laptop serial numbers, monitor counts, server hardware, network gear, even the licences attached to specific people.

The output is a single reconciled asset list with purchase dates, supplier invoices, current location, and assigned user. Your accountant uses this for depreciation. Your IT provider uses it for warranty and refresh planning. Both of you stop chasing ghosts.

3. Audit every software subscription and licence

Pull a report of every SaaS subscription you pay for. Microsoft 365, Adobe, Xero, Dropbox, ChatGPT Team, Canva, Zoom, the random Trello upgrade somebody bought in 2023. For each one, answer three questions: who uses it, do they still need it, and is the licence tier right?

Common findings: Microsoft 365 E3 seats assigned to people who only need Business Premium; per-user tools paid for ex-staff; duplicate tools (two project management apps, two e-signature platforms). Cancelling or right-sizing before 30 June means the saving starts in FY27 rather than mid-year.

4. Decommission unused services and shadow IT

This is the cousin of item 3. Subscription audits catch the things on your credit card. Decommissioning catches the things that aren’t, like that VPS somebody spun up four years ago, the test SharePoint site nobody touches, the legacy line-of-business app running on a Windows Server 2012 box in the corner. Each one is an attack surface, a compliance headache, and in some cases a recurring cost.

Make a list. Tag each item: keep, migrate, decommission. Set a date for each decommission. Get sign-off from a business owner so nothing critical disappears by surprise.

5. Plan your hardware refresh cycle

Walk your asset list and identify everything that’s three or more years old. Laptops on their fourth Windows feature update, servers past warranty, switches that haven’t had a firmware update since the Coalition was in power. These don’t all need replacing in June, but you need a plan with dates and budgets.

If you do intend to purchase hardware before 30 June 2026 for tax-timing reasons, talk to your accountant about the current instant asset write-off threshold and whether the asset must be installed and ready for use by 30 June to qualify. The rules change year to year and we won’t pretend to know yours. See the ATO website for current figures.

6. Review your IT spend: capex vs opex

Sit with finance and categorise your IT spend from the past 12 months. How much was capital (hardware purchases, major project work, software licences treated as assets)? How much was operating expense (managed services, subscriptions, cloud)? Most Melbourne SMEs we work with are gradually shifting from capex-heavy to opex-heavy as cloud and managed services replace owned infrastructure.

Whether that shift is right for your business is a tax and cashflow conversation with your accountant. Our job is to give them clean numbers. A per-user fixed monthly model like ours makes the opex side predictable, which is what finance teams want when they’re forecasting FY27.

7. Confirm depreciation schedule with your accountant

Your IT assets depreciate. Laptops, servers, network equipment, sometimes software. The schedule depends on the asset class, the effective life the ATO publishes, and any small business concessions your accountant elects to use. You don’t need to understand the maths. You do need to give your accountant the reconciled asset list from item 2 with accurate purchase dates and disposal dates.

If you disposed of equipment during the year (e-waste, sold a server, scrapped old phones), document it. Disposals affect the depreciation schedule and the asset register both. Photos of the e-waste pickup or the disposal certificate are good evidence to keep.

8. Check renewal dates for the next 12 months

Pull every renewal date that hits between July 2026 and June 2027. Microsoft 365 anniversaries, antivirus, firewall licences, domain renewals, SSL certificates, broadband contracts, your MSP agreement. Put them in a single spreadsheet sorted by month.

This gives finance a cashflow forecast and gives IT a heads-up for negotiation windows. Multi-year deals often have better pricing if you can commit, but only commit on tools you’ve confirmed you still need (item 3).

9. Review cyber security posture and insurance

Cyber insurance renewals usually ask the same questions: MFA on everything, EDR on every endpoint, backup tested in the last 90 days, patching cadence, admin account separation. If you haven’t been measuring yourself against a framework, EOFY is a sensible time to start. The Essential Eight from the ACSC is the practical baseline for Australian SMEs.

Even if you’re not pursuing formal compliance, the Essential Eight maturity levels give you and your insurer a common language. Most cyber policies now ask explicitly about MFA coverage and backup testing. Having documented answers makes renewal cheaper and faster.

10. Set the FY27 IT budget and roadmap

You can’t do this properly without items 1-9. Once you have the asset list, the subscription audit, the renewal calendar, and the refresh plan, the budget almost writes itself. Three buckets: recurring (subscriptions, managed services), planned capex (hardware refreshes, projects), and contingency (10-15 percent for the things you can’t predict).

For most SMEs we work with, IT spend lands between 3 and 6 percent of revenue depending on industry. Professional services and finance firms run higher because of compliance and software costs. Trades and retail tend to run lower. There’s no universal right answer, only what’s right for your business and what’s enabled the year ahead. We help clients build this through IT strategic planning sessions, usually run in late June or early July.

A quick reference table

How TechAssist runs EOFY for our managed clients

We’ve been doing this since 2014. The standard EOFY cycle for our managed IT services in Melbourne clients runs across May and June. Your account engineer schedules the backup test, pulls the licence and subscription report from our PSA, generates the reconciled asset list, and books a 60-minute review with you and your finance lead. We hand the asset register and the FY26 IT spend summary directly to your accountant if you want us to.

For context: TechAssist has 13 engineers, all employed in Australia (no offshoring), and our 24/7 Network Operations Centre runs from Tecoma in the Dandenong Ranges. Our P1 response target is under 15 minutes and we publish it openly in our pricing and SLA. The model is per-user, fixed monthly — which makes the EOFY conversation about value delivered, not surprise invoices.

If you’re not on a managed agreement and you’d like to run a one-off EOFY IT review before 30 June 2026, we offer that too. It’s a fixed-scope engagement that gives you the reconciled asset list, the subscription audit, the backup verification, and a written summary your accountant can use. Call 1300 028 324 or use the form at contact.

Common mistakes we see at EOFY

A few patterns repeat every year. Worth flagging so you can avoid them.

• Buying hardware on 28 June without checking install-by dates. If the asset has to be installed and ready for use by 30 June for a particular tax treatment, a laptop sitting in a delivery van doesn’t qualify. Order earlier.
• Cancelling subscriptions on the last day of the month. Most SaaS billing runs monthly anniversaries, not calendar months. You’ll often still be billed for July. Cancel mid-month with explicit confirmation of when access ends.
• Treating the asset register as IT’s problem. If finance doesn’t have an accurate fixed asset register, your accountant is guessing. This is a joint exercise, not a handoff.
• Skipping the backup test because backups “looked green”. A green dashboard isn’t a restore. Test the restore.
• Promising a major rollout starts 1 July. Nothing major should start on day one of the financial year. Your team is exhausted, suppliers are slow, and finance is busy. Start mid-July at the earliest.

What good looks like on 1 July

If you’ve done the work, here’s what your first week of July 2026 looks like. Backups tested and documented. Asset register matches finance’s books. Every active subscription is justified and right-sized. Decommissioned services no longer billing. Renewal calendar visible 12 months out. Cyber posture documented against the Essential Eight. FY27 budget signed off with three buckets and a contingency. Your accountant has clean numbers. Your team isn’t scrambling.

That’s the standard. It’s not glamorous and it doesn’t make headlines. It does mean July starts calm instead of chaotic, and that’s worth a fortnight of June effort.

Frequently asked questions

What’s the instant asset write-off threshold for FY26?

The instant asset write-off rules change regularly. As of mid-2026 the threshold has been adjusted several times in recent years by federal budget announcements. Rather than quote a figure that may be out of date by the time you read this, check the current threshold on the ATO website or ask your accountant. The principle stays the same: assets under a certain dollar value, installed and ready for use by 30 June, may be eligible for immediate deduction rather than depreciation over multiple years. Your accountant will tell you whether it applies to your situation.

How does depreciation work for IT assets like laptops and servers?

The ATO publishes effective life schedules for different asset classes. Laptops and desktops typically have an effective life around three to four years; servers and network equipment longer. Your accountant chooses between prime cost (straight-line) and diminishing value methods, and may apply small business depreciation concessions if you qualify. Your job is to give them an accurate asset list with purchase dates, prices, and disposal dates. The maths is their job.

When’s the best time to budget IT spend for the new financial year?

May and June, before 30 June. You want the FY27 budget signed off before the new financial year starts so July doesn’t begin with uncertainty. The inputs are the items in this checklist: reconciled asset list, subscription audit, renewal calendar, refresh plan, cyber posture review. With those in hand, a half-day workshop with your business owner and IT lead is usually enough to land a defensible FY27 number.

Should I buy laptops before 30 June 2026 for tax reasons?

Talk to your accountant. If the asset is genuinely needed and you’re going to buy it anyway, timing the purchase before 30 June may have tax benefits depending on the current rules and your business structure. If you’re buying purely to chase a deduction, that’s a worse decision than it sounds, because you’ve spent real cash to save a fraction of it in tax. We can help you decide whether the hardware is genuinely needed; your accountant decides whether the timing helps your tax position.

How long does an EOFY IT review take?

For a typical 20-50 user Melbourne SME, the review itself is half a day of work from your IT provider plus a 60-90 minute joint session with finance. Remediation (cancelling subscriptions, scheduling decommissions, organising hardware orders) is usually another half day across the month. Start in mid-May and you’ve got comfortable runway. Start on 25 June and you’ll be cutting corners.

Closing thought

EOFY IT prep is one of those tasks where the value isn’t in any single item, it’s in doing all of them properly. A clean asset register makes depreciation accurate. An honest subscription audit makes the FY27 budget defensible. A tested backup means the next ransomware incident is a Tuesday inconvenience instead of a business-ending event. None of it is exciting. All of it compounds.

If you’d like a hand running through this before 30 June 2026, get in touch via our contact page or call 1300 028 324. We’ll tell you straight whether you need our help or whether you’ve already got it sorted.

Week 1 of a co-managed IT engagement is mostly listening, counting and writing things down. We audit the environment, capture credentials, transfer documentation from your internal IT person, and get a RACI matrix signed. No big changes, no tool rollouts. The goal is a true picture of what you actually have, not what the last vendor said you had.

That paragraph is the short answer. The rest of this piece is the long one — a week-by-week playbook of what the first 30 days of co-managed IT onboarding should look like for a Melbourne SME, what goes wrong, and how to tell whether your new partner is doing it properly or just collecting a monthly fee.

We’ve run this onboarding sequence dozens of times at TechAssist since 2014, mostly for businesses between 30 and 200 staff across Melbourne. The pattern below is what we’ve settled on after enough painful lessons to know which corners can’t be cut. If your engagement is starting next month, print this out and use it as a checklist against whatever your MSP proposes.

What co-managed IT onboarding actually is (and isn’t)

Quick definition so we’re aligned. Co-managed IT means your internal IT person or small team keeps running day-to-day, and an external MSP plugs in to handle specific gaps — usually 24/7 monitoring, after-hours support, escalations, project capacity, and the unsexy compliance and documentation work. It’s not full outsourcing. It’s not staff augmentation. If you’re not sure which model suits you, our co-managed vs managed vs internal IT comparison breaks down the differences in plain terms.

Onboarding is the bridge between signing the contract and the partnership actually working. Done well, it takes four weeks and ends with both teams operating as one. Done badly, it stretches to six months and never really finishes — the MSP is firefighting tickets they don’t understand because nobody documented anything, and your internal lead is quietly furious because they’ve been answering the same questions for ninety days.

The thirty-day target isn’t arbitrary. After 30 days you should be at steady-state: tickets flowing, monitoring green, runbooks written, the first quarterly business review (QBR) scheduled. If you’re not there by day 30, something has gone wrong upstream — usually in week 1.

The 30-day playbook at a glance

That’s the skeleton. Now the meat.

Week 1: Discovery and scoping

The opening week is unglamorous and easy to skip. Don’t skip it. Everything that follows depends on what you find in the first five working days.

The environment audit

On day one we walk the environment with your internal IT lead. Not remotely. In person where possible, even if it’s a half-day in a Hawthorn office. We want to see the comms cabinet, count the switches, photograph the UPS labels, find the cabling that runs through the ceiling void that nobody documented. Remote-only audits miss the patch panel that’s held together with cable ties and hope.

The deliverable from the audit is a written inventory covering:

• Every server (physical and virtual), with OS, role, owner and last-patched date
• Every endpoint count by device class, broken down by warranty status
• Network gear — firewalls, switches, APs — with firmware versions and support contract end dates
• SaaS tenants — Microsoft 365, Google Workspace, line-of-business apps — with licence counts and admin accounts
• Backup targets, retention policies, last verified restore date
• Internet links, static IPs, DNS hosting and where the domain registrar sits

If your MSP doesn’t ask for the last verified restore date, that’s a red flag. Backups that haven’t been tested aren’t backups. They’re hope.

Credentials capture

This is where most onboardings stall. Your internal IT person — let’s call him Dave — has accumulated passwords over four years. Some are in a KeePass vault, some are in his head, some are on a Post-it under his keyboard, and a few belong to a previous employee whose Microsoft 365 account technically still has Global Admin.

The MSP needs everything moved into a shared, audited password vault before week 2. Not Dave’s personal KeePass. A vault both teams can access with role-based permissions and full audit logging. We use a hosted IT documentation platform with credential management built in; your MSP will have their own. The point is shared, audited, encrypted.

Here’s what often goes wrong: Dave doesn’t want to share the passwords. Sometimes it’s protective — he’s worried about his job. Sometimes it’s just years of muscle memory around being the sole custodian. Either way, it has to be addressed by the business owner directly. The MSP can’t force it. We’ve had week 1 stretch to three weeks because a single internal lead wouldn’t hand over the firewall admin password, and the whole project sat there idling.

The fix is a frank conversation, framed around resilience. If Dave gets hit by a tram on the Lygon Street tracks tomorrow, the business needs to keep running. Co-managed IT is the insurance policy, not the replacement.

Documentation transfer

Whatever Dave has — Visio diagrams, OneNote pages, a folder of Word docs called “IT Stuff” — it all gets transferred and reviewed. Most of it will be out of date. That’s fine. We’re not auditing Dave’s documentation hygiene; we’re capturing institutional knowledge before it walks out the door.

Things we look for that are nearly always missing:

• Network diagram showing actual VLAN topology, not the one from 2019
• List of which line-of-business app talks to which database, on which server, on which port
• Vendor contacts with account numbers — internet provider, hardware supplier, line-of-business software vendors
• Recurring scheduled tasks (the script that runs every Sunday night that nobody understands)
• The actual office Wi-Fi password

RACI matrix sign-off

The most important week 1 deliverable, and the one businesses skip most often. A RACI matrix lists every category of work — patching, user onboarding, after-hours P1 response, M365 licence changes, backup verification, project work, vendor liaison — and for each one assigns Responsible, Accountable, Consulted and Informed roles between you and the MSP.

Without it, scope creep starts on day 8. We had a Box Hill manufacturing client where week 2 turned into a “could you just have a look at this” parade because nobody had written down who owned what. Their internal IT lead burned out within six months and we had to renegotiate the agreement. A signed RACI in week 1 would have prevented all of it.

A good RACI is boring. Three pages of “MSP responsible, internal IT consulted” rows. If it’s exciting, something’s wrong.

Week 2: Tooling rollout

With the audit complete and the RACI signed, week 2 is when the MSP’s tooling goes in. This is the visible part of onboarding and the part most clients judge us on. It’s important, but it’s only the middle act.

RMM deployment

Remote Monitoring and Management agents go on every server and endpoint. The deployment itself is straightforward — a GPO push or Intune deployment, depending on your environment. The harder part is the post-deployment tuning. Out of the box, every RMM screams about everything. By end of week 2 it should be tuned to your environment: warnings on the things that actually matter, silence on the things that don’t.

Ask your MSP what their first-week alert volume looks like. If they tell you “five hundred alerts a day, we’ll tune it later” — that’s a tooling team that doesn’t tune. If they tell you “we expect noise for 48 hours then it should drop below 30 actionable alerts a day” — that’s a team that knows what they’re doing.

EDR rollout

Endpoint Detection and Response goes on the same agents. We typically run in monitoring-only mode for the first week, then flip to blocking once we’ve baselined what’s normal in your environment. The Camberwell legal firm we onboarded last spring had a custom internal app that EDR initially flagged as malware. Two days of monitoring told us it was legitimate, we wrote an exclusion, and we never heard from it again. Had we gone straight to blocking on day one, their fee earners would have been locked out of their case management system.

EDR also needs to be connected to a 24/7 monitoring centre. Detection without response is just a noisier RMM. Our NOC at Tecoma watches EDR alerts for every client around the clock, with a sub-15-minute target response on P1 incidents. If your MSP doesn’t operate (or contract to) a true 24/7 NOC, you don’t have 24/7 cover regardless of what the SLA document says.

Backup monitoring

Your existing backup solution — whatever it is — gets connected to monitoring. We don’t usually rip and replace backup tooling in week 2; that’s a project for month two or three. Week 2 is about visibility. Are jobs running? Are they completing? When was the last successful restore test?

One of our Ringwood clients arrived with backups that had been “running fine” for two years according to their previous vendor. First week of monitoring revealed three of seven jobs had been silently failing since the previous Christmas. The vendor had been ignoring the alert emails. This is exactly the kind of thing co-managed IT catches in week 2.

NOC enrolment

By Friday of week 2, your environment is enrolled in the MSP’s NOC. That means 24/7 eyes on monitoring, with documented escalation paths back into business hours support. Test it. Genuinely. Pick a Saturday morning, simulate a server going offline, see what happens. If you don’t get a phone call within fifteen minutes, you’ve learned something important before it matters.

Week 3: Runbook writing

Week 3 is where co-managed IT separates from break-fix outsourcing. A break-fix vendor stops here — tools are in, tickets are flowing, what more do you want? A co-managed partner spends week 3 writing down how your specific environment is meant to operate.

BAU runbooks

Business as usual procedures get documented. The deliverables are short, practical documents — usually one page each — covering things like:

• New starter provisioning end-to-end (M365 licence, group memberships, line-of-business app accounts, hardware allocation, induction checklist)
• Leaver offboarding (account disable timing, mailbox conversion to shared, OneDrive handover, MFA token revocation, asset return)
• Password reset for the CEO’s PA (specific authentication checks because executives get targeted)
• VPN access request and approval workflow
• Standard hardware build and imaging procedure

These runbooks live in shared documentation. Both teams update them. They’re owned by the MSP’s service delivery manager but the internal IT lead has edit rights. If your MSP keeps runbooks in a vault you can’t access, you’ve recreated the original lock-in problem you were trying to solve.

After-hours playbooks

The after-hours playbook is what the NOC reads at 2am when something breaks. It needs to be opinionated. “If the primary firewall is unreachable, do X, then Y, then call Z.” Not “investigate and escalate appropriately.” The whole point of co-managed IT is that the NOC engineer at 2am — who has never met your team — can act decisively because the playbook tells them exactly what your business considers acceptable risk.

Three things the after-hours playbook must include:

1. Reboot authority — what services can the NOC restart without calling anyone, and which ones need human approval no matter what time it is?
2. Escalation contacts in priority order, with both mobile and alternate numbers
3. Communication rules — when does the business want a phone call versus a text message versus an email-tomorrow?

We’re firm with clients on this: if you don’t give the NOC reboot authority for non-critical services, you’re paying for 24/7 cover and getting a 24/7 paging service. Different things.

Escalation tree

Published, visible, dated. Both teams should know that P1 incidents go to the internal IT lead first, then to the operations manager, then to the business owner. P2 follows a different path. P3 doesn’t wake anyone up. The escalation tree gets reviewed and re-signed at every QBR.

Week 4: Shakedown and the first QBR

The final week of onboarding is about live testing and setting up the steady-state cadence.

Live ticket testing

By week 4, real tickets are flowing. We deliberately introduce a few synthetic ones to test the full pipeline — a fake password reset, a simulated phishing report, a planned “service down” drill. The goal is to find the gaps in the workflows we built in weeks 2 and 3 before a real incident finds them for us.

Failover drill

If your environment includes any kind of failover — secondary internet link, virtualised server cluster, cloud-hosted backup of an on-prem database — we test it during week 4. Pull the cable. See what happens. The Footscray distribution client we onboarded last year discovered during their week 4 drill that their secondary internet link had been incorrectly configured for eighteen months. The failover had never worked. They’d have found out the hard way during the next storm.

QBR preparation

The first Quarterly Business Review happens 90 days after go-live, but the pack starts coming together in week 4. The QBR pack should cover:

• Tickets raised, resolved, escalated — broken down by category
• SLA performance against contract
• Open security or compliance findings from the week 1 audit, with remediation status
• Recommended projects for the next quarter, ranked by business value
• Budget tracking against your IT operating budget

A useful QBR is opinionated. The MSP should have a view on what you should do next, with reasoning. If your QBR is a slide deck of green ticks and nothing else, you’re getting account management, not strategic advice.

The 90-day plan

Week 4 closes with a signed 90-day plan listing the projects the MSP and internal IT will tackle together. Usually 3-6 items. Things like “migrate file server to SharePoint,” “replace ageing firewall,” “implement conditional access policies in M365.” Each one has a budget, an owner and a target completion date.

A real example: a 90-staff engineering consultancy in Cremorne

We onboarded a structural engineering consultancy in Cremorne last quarter — 90 staff, two offices, one internal IT manager who’d been there nine years and was three weeks from going on long service leave. The brief was specific: get fully operational before he walked out the door.

Week 1 went mostly to plan. The audit surfaced two unsupported Server 2012 R2 boxes still running production workloads, a Hyper-V cluster with a failed disk that nobody had been alerted to, and an Active Directory with 47 stale user accounts including three former IT contractors with Domain Admin.

Week 2 was where it got interesting. The internal IT manager — entirely reasonably — wanted to be the one to flip every switch. We worked around him, scheduled deployments during his preferred hours, and accepted the slower pace because the alternative was a worse handover. Don’t underestimate this. Co-managed IT is a relationship, and the internal lead’s psychological investment matters.

Week 3 we hit a scope creep moment. The CFO asked whether we could “just have a quick look” at why the M365 e-discovery search wasn’t returning results, which turned out to be a configuration project worth about two weeks of engineering effort. We declined to absorb it into onboarding, scoped it as a separate project, and got it approved as the first item on the 90-day plan. That’s what the RACI is for.

Week 4 the failover drill found that their secondary internet link’s BGP advertisement had a typo in the AS path, so failover would have black-holed traffic. Fixed inside the drill window. The internal IT manager went on long service leave on day 31. Steady-state for the past four months has been clean.

What good MSPs do differently in onboarding

If you’re comparing MSPs and trying to read between the lines of their onboarding pitches, here’s what to listen for.

They want to talk to your existing IT person before signing

A serious MSP wants a 30-minute call with your internal IT lead during the sales process, not after. They’re trying to understand whether the handover will be co-operative. If your prospective MSP shows no interest in your incumbent until the contract’s signed, expect a difficult onboarding.

They have a written onboarding methodology

Ask to see it. If they email you a Visio diagram and a six-page document, good sign. If they wing it from a sales deck, less good. Our methodology lives in the same documentation system clients use post-onboarding — they can see exactly what we’re going to do because we’re going to ask them to use the same system afterwards.

They quote a per-user fixed price for steady-state

Onboarding work is project-priced. Steady-state should be per-user per-month with a clear inclusions list. If your MSP quotes hourly for everything post-onboarding, your costs will balloon unpredictably the moment you actually need them. Our co-managed IT pricing breakdown walks through how this should be structured for Australian SMEs.

Their engineers answer the phone

Not a call centre, not a triage queue with three levels before you reach someone who can help. TechAssist runs 13 engineers, all Australian-employed, and the person who picks up your P1 call at 11pm can usually fix the problem themselves. That model has limits at scale, but at SME scale it’s the right one. Our managed IT services page lays out the staffing model in more detail.

The most common onboarding failures (and how to avoid them)

After eleven years of doing this, the failure modes are pretty consistent.

The incumbent won’t share credentials. Addressed above. Requires executive sponsorship and a frank conversation about resilience.

The RACI doesn’t get signed. Everyone agrees in principle, nobody puts ink on paper, and by week 3 the scope is whatever the loudest person says it is. Insist on signature before week 2 starts.

The MSP deploys tooling without tuning it. Visible in week 2 alert volumes. If your inbox is on fire by Friday of week 2, the MSP isn’t doing the configuration work.

Runbooks get skipped to “save time.” Week 3 is the easiest week to compress because it’s all writing. It’s also the week that pays the biggest dividends in months two through twelve. Don’t let it get squeezed.

The first QBR doesn’t happen. If 90 days come and go and nobody’s booked the QBR, the engagement has already drifted into break-fix territory. Push for the date in week 4.

Scope creep on day 8. The “could you just have a look at” parade. Every co-managed engagement faces this. The answer is “yes, and here’s the scoped quote” — never “yes, we’ll absorb it.”

What this should cost

Onboarding for a 50-150 staff Melbourne business typically lands between $8,000 and $22,000 as a one-off project, depending on environment complexity. Steady-state per-user pricing then sits in the range we’ve documented in our pricing guide. You can also see our standard SLA terms on the pricing and SLA page.

What you should not see is a low onboarding fee paired with hourly steady-state rates. That’s the model where MSPs make their money on the surprise invoice in month three. Per-user fixed monthly with a clear inclusions list is the only model that aligns incentives properly.

Where to from here

If you’ve just signed a co-managed IT agreement, share this article with your new MSP and ask them to walk you through their version of each week. If their methodology looks materially different, get them to explain why. Different isn’t wrong — but it should be defensible.

If you’re still evaluating, our overview of co-managed IT support covers the broader engagement model, and the co-managed IT for Melbourne SMEs piece goes deeper on why the internal-plus-external structure works for businesses in our market.

If you want to talk through your specific environment, the team at TechAssist is on 1300 028 324, or use the form on our contact page. We’re based in Melbourne, our NOC runs out of Tecoma in the Dandenong Ranges, and we’ve been doing co-managed IT for Australian SMEs since 2014. No call centres. No overseas escalation. Just engineers who answer the phone.

FAQs

How long should co-managed IT onboarding actually take?

Four weeks for a typical 30-200 staff Melbourne business. Longer if your environment is unusually complex (multiple sites, heavy compliance requirements, line-of-business applications with no current documentation) or if there’s friction with the incumbent IT staff. If your MSP is quoting more than six weeks for a standard SME environment, ask what’s driving the extra time — it’s usually a sign their process isn’t tight.

Do we need to replace our existing tools during onboarding?

No. Week 2 is about getting visibility, not ripping and replacing. If your existing backup, EDR or RMM is genuinely fit for purpose, a good co-managed partner will connect it to their monitoring and leave it in place. Tool replacements get scoped as separate projects in the 90-day plan, with proper cost-benefit analysis. Anyone who tries to replace everything in week 2 is selling licences, not service.

What if our internal IT person resists the engagement?

Common, and usually fixable. Most resistance comes from job insecurity rather than genuine disagreement. A clear RACI matrix that shows the internal lead remaining responsible for strategic and relationship work — while the MSP absorbs the monitoring, after-hours and overflow — almost always wins them over within the first month. If resistance persists past week 2, that’s an executive conversation, not an IT one.

Will we get the same engineer every time?

For day-to-day work, you’ll get a small team of two to four engineers who know your environment, not a random round-robin from a queue. After-hours and P1 incidents go to whoever’s on the NOC roster, which is why the runbooks matter — they make sure any of our 13 engineers can act decisively on your environment even if they’ve never been on-site. Sub-15-minute P1 response is the standard we hold ourselves to.

What happens if onboarding falls behind schedule?

It happens. About one in five engagements slip by a week, usually because of credential or documentation friction in week 1. A serious MSP will flag the slip immediately, explain the cause, and adjust the plan rather than pretending everything’s on track. The worst outcome is silent slippage — week 4 arrives and nobody’s done the runbooks, but the invoicing has switched to steady-state. Insist on weekly status updates during onboarding and don’t let week 4 close without the deliverables checklist signed off.

Under 15 staff with no IT person — fully managed IT usually fits. 30 to 150 staff with one or two internal techs drowning in tickets — co-managed vs managed IT tilts toward co-managed. 200+ with complex apps and strict compliance — a proper internal team, often backed by a partner, is the right call.

That’s the short answer. The rest of this post is the working — what each model actually means once the sales deck closes, what it costs in real AUD, where each one falls over, and a decision matrix you can take into your next board meeting.

We’ve helped Melbourne SMEs across Cremorne agencies, Dandenong manufacturers, and Box Hill medical practices move between all three models. None of them are inherently better. They suit different shaped businesses, and the wrong fit is expensive in ways that don’t show up on the invoice.

What each model actually means in practice

The three terms get used loosely, and MSPs are guilty of muddying the water. Here’s what’s really on offer when you strip out the marketing.

Internal IT

You employ your own IT staff. Could be one person doing everything from password resets to Azure tenant design, or a structured team with a help desk, sysadmins, and an IT manager reporting to the CFO or COO.

The pitch is control and institutional knowledge. Your IT person knows where the bodies are buried, sits in the lunchroom, and can be tapped on the shoulder. They learn your line-of-business apps deeply because they live with them every day.

The reality is that one person can’t cover everything. A solo internal hire is on-call 24/7 by default, can’t take a fortnight off without something burning, and is unlikely to be equally strong at Microsoft 365 hardening, network design, backup verification, server patching, and end-user support. You’re paying senior money for someone who’ll spend two thirds of their day on tickets a Level 1 should handle.

Fully managed IT

You outsource the lot to an MSP. They run your help desk, manage your devices, patch your servers, monitor your network, handle your backups, and own the relationship with Microsoft, your ISP, and your line-of-business vendors. You get a single number to call.

The pitch is predictable cost, broad skill coverage, and after-hours support without paying overtime.

The reality, when it’s done properly, matches the pitch. The reality when it’s done badly is ticket queues, junior engineers cycling through your account, and a feeling that nobody actually knows your business. The difference comes down to engineer-to-client ratios, whether the MSP is Australian-employed or offshored, and whether there’s a named technical lead on your account.

At TechAssist we run with 13 engineers, all Australian-employed, and clients get a named lead engineer who knows the environment. We charge per user, fixed, with no surprise hourly billing. The model only works if the MSP is genuinely incentivised to fix root causes rather than churn tickets.

Co-managed IT

You keep your internal IT person or team, and an MSP plugs in alongside them. Roles get carved up explicitly. The internal team usually owns user-facing work, line-of-business app knowledge, and project liaison. The MSP owns the heavy lifting — 24/7 monitoring, after-hours coverage, backup verification, security operations, escalations, and the deep technical work the internal person doesn’t have time for.

The pitch is “your internal IT, supercharged.” It’s accurate when the boundaries are clear and the MSP doesn’t try to land-grab. It falls over when nobody documents who owns what, and tickets fall between the cracks.

Co-managed is the fastest-growing of the three models in the Melbourne SME market, and it’s where we’re seeing the most thoughtful conversations. We’ve written a longer piece on how it works specifically for Melbourne SMEs that runs alongside this one — see co-managed IT for Melbourne SMEs: internal plus external for the operational detail.

Who each model actually suits

Forget headcount-only rules of thumb. The right model depends on a handful of factors that interact.

Fully managed: the sweet spot

Best fit: 5 to 50 staff, no internal IT, standard tech stack (Microsoft 365, some line-of-business SaaS, maybe a file server or two), and a leadership team that wants IT to “just work” without thinking about it.

Concrete example: a 22-person accounting firm in Camberwell running Xero Practice Manager, FYI Docs, and Microsoft 365. They don’t need a full-time IT person — that’d be 60% idle. They need someone to onboard new staff in a day, keep the laptops patched, run the backups, respond when someone can’t print, and lift their security posture so the cyber insurance renewal doesn’t bite. Fully managed is the obvious call. See our managed IT services for what’s included.

Also a strong fit: professional services firms, allied health practices, smaller manufacturers, and not-for-profits where IT isn’t a competitive differentiator and reliability matters more than bespoke control.

Co-managed: the sweet spot

Best fit: 30 to 150 staff, one to three internal IT people, and either a growth trajectory that’s outpacing the team or a skills gap (usually security, cloud architecture, or after-hours).

Concrete example: a 75-person engineering consultancy in Richmond with a solo IT manager. He’s good — knows the CAD pipeline, knows the Revit licensing, knows which director hates Teams. But he’s the only one. He can’t take leave, his security knowledge is patchy, and the directors won’t sign off on hiring a second IT person at $110k when they’re not sure it’s justified.

Co-managed lets him keep owning the user-facing work and the CAD environment, while an MSP runs 24/7 monitoring, handles after-hours incidents, owns backup verification, and gives him senior engineers to escalate to when something’s beyond his depth. He stops being a single point of failure, and the directors get sub-15-minute response times around the clock without hiring a second body. Our co-managed IT support page covers how the role split works in practice.

Also a strong fit: mid-sized law firms, multi-site retail, manufacturers with shift work needing after-hours coverage, and any business where the internal IT person is the bottleneck on growth.

Internal IT (sometimes plus a partner): the sweet spot

Best fit: 200+ staff, complex environment (multiple line-of-business apps, integrations, dev teams, regulated industry), and IT genuinely is a strategic function rather than a cost centre.

Concrete example: a 350-person specialist healthcare provider with multiple clinics across Victoria, a custom patient management platform, HL7 integrations with pathology and imaging providers, and ADHA compliance requirements. They need an IT manager, a help desk, sysadmins, and probably a developer or two. An MSP can’t run this — too much institutional knowledge required, too much custom work, decisions that need to be made in real time with clinical context.

What they often do have is a partner for specific functions: a security-focused MSSP for SOC services, a cloud partner for Azure architecture reviews, or an MSP backstop for after-hours help desk overflow. Pure internal is rare at this size; pure outsourced is dangerous.

Also a strong fit: financial services with regulatory complexity, large healthcare networks, businesses with significant in-house software development, and any organisation where the IT function is genuinely a strategic asset.

What each model costs (real AUD ranges)

Prices below are Melbourne market ranges as of mid-2026, for a representative SME profile. Your numbers will vary with complexity, but these are the right order of magnitude.

Internal IT cost

A solo internal IT generalist in Melbourne: $85k to $120k base salary, plus super, leave, training, and tools. All-in cost to the business is roughly $115k to $160k per year. Add the cost of the gear they need (admin licences, monitoring tools, backup software if you go DIY) and you’re closer to $130k to $180k.

For a 30-person business, that’s $360 to $500 per user per month, just for one person. And you’ve still got a single point of failure, no after-hours coverage, and skill gaps.

A structured internal team (IT manager + two help desk + one sysadmin) for a 200-person business: $450k to $650k all-in, or roughly $190 to $270 per user per month before tools and gear.

Fully managed IT cost

Quality Melbourne MSPs charge between $120 and $220 per user per month for fully managed, depending on scope, security inclusions, and whether 24/7 is bundled in. The cheap end ($60 to $100) usually means offshore help desk, shared engineer pools, and project work billed separately on top. The expensive end usually includes a vCIO function, security operations, and bundled project hours.

TechAssist sits in the middle — fixed per-user pricing, no hourly billing for in-scope work, 24/7 NOC included, and named engineers per client. Full breakdown on our pricing and SLA page.

For a 30-person business: roughly $3,600 to $6,600 per month, or $43k to $80k per year all-in. Less than half the cost of a solo internal hire, with broader coverage and no leave gaps.

Co-managed IT cost

Co-managed pricing varies more because the scope varies. Typical Melbourne ranges are $50 to $130 per user per month for the MSP portion, on top of your existing internal IT salary cost.

For the 75-person engineering consultancy above: $110k for the internal IT manager, plus roughly $4,500 to $9,000 per month for co-managed coverage. All-in cost in the $165k to $220k range, versus $220k+ for hiring a second internal person to fill the gaps.

The maths usually works out in favour of co-managed at this size, and you get 24/7 coverage, deep specialist skills on tap, and resilience the second hire wouldn’t have provided.

The comparison matrix

This is the table to take to your next leadership meeting. One row per decision factor, one column per model.

What breaks under stress in each model

Every model has a failure mode. Knowing them up-front saves grief.

Internal IT failure modes

The single-point-of-failure problem is the big one. When your solo IT person resigns, takes long-service leave, or gets hit by a bus, the institutional knowledge walks out the door. We’ve been called into Melbourne businesses where the internal IT manager left with three weeks’ notice and nobody else knew the admin passwords, the backup configuration, or which Azure tenant did what. Recovery takes months.

The other failure mode is skills atrophy. A solo IT person can’t be expert at everything. Their security knowledge gets stale, their cloud architecture is whatever they learned five years ago, and their backup verification is “I assume it’s working.” This bites hardest during incidents.

Fully managed IT failure modes

The classic failure is the help desk ticket queue. You log a ticket, it sits with a Level 1 engineer who doesn’t know your environment, it gets escalated, then re-escalated, and four days later somebody actually fixes it. This happens when the MSP’s engineer-to-client ratio is too high, or when accounts get bounced between engineers with no continuity.

The other failure is scope arguments. “That’s not in your agreement, that’ll be billable” gets old fast. The fix is choosing an MSP with broad fixed-scope inclusions and not the cheap-and-cheerful end of the market.

The third failure, less talked about, is loss of internal capability. After three years of full outsourcing, your team has forgotten how anything works. Switching providers or bringing it back in-house becomes a major project.

Co-managed IT failure modes

The biggest one is unclear boundaries. If the RACI matrix isn’t documented and reviewed quarterly, tickets fall between the cracks. The internal person thinks the MSP owns it, the MSP thinks internal owns it, the user waits two days, and trust erodes.

The second failure is ego. Some internal IT people see the MSP as a threat to their job. Some MSPs treat the internal person as a junior to be worked around. Either kills the model. It needs to be a partnership, with the internal IT person treated as the senior on-site contact and the MSP as the deep-bench backstop.

A worked example: which model would a Cremorne creative agency choose?

Imagine a 45-person creative agency in Cremorne. Adobe Creative Cloud across the studio, big shared storage for video projects, Microsoft 365 for everything else, hybrid working, and one part-time IT contractor who comes in two days a week.

The contractor handles user issues and the studio storage. He’s competent but works in a silo. The directors are nervous about security after a competitor got hit with a ransomware incident last year. They’ve never tested a backup restore. After-hours support is whatever the contractor picks up on his mobile.

Three honest options:

• Hire a full-time IT manager. $115k all-in. Still a single point of failure. Still no genuine after-hours. Probably overkill for the day-to-day load.
• Move to fully managed. Replace the contractor entirely. Roughly $6,500 a month all-in for a quality MSP. Lose the contractor’s accumulated knowledge of the studio storage and Adobe setup.
• Move to co-managed. Keep the contractor (maybe bump him to three days a week) and bring in an MSP for monitoring, after-hours, security operations, backup verification, and escalation. Roughly $4,500 to $5,500 a month for the MSP portion, on top of the contractor.

For this business, co-managed is usually the right answer. The contractor’s studio knowledge is valuable. The MSP fills the security, after-hours, and resilience gaps. The total cost is lower than hiring a full-time IT manager, and the risk profile is much better than the status quo.

For a different business — say, a 12-person Hawthorn architecture practice with no internal IT at all — fully managed would be the obvious answer, not co-managed.

How to actually decide

If you’re staring at the matrix and still not sure, work through these questions honestly.

Do you have someone internal already?

If yes, and they’re competent, the conversation should start with co-managed. Replacing a good internal IT person with an MSP almost always costs you institutional knowledge that’s hard to rebuild. Co-managed lets you keep what works and patch what doesn’t.

If no, fully managed is the default unless you’re large enough (200+) to justify building an internal team from scratch.

What’s your growth trajectory?

If you’re growing fast — say, doubling staff in 18 months — fully managed scales the easiest. You add users to the agreement. Internal hiring lags growth by months, which means IT becomes the bottleneck.

If you’re stable, the question is more about fit and cost.

How much does after-hours matter?

If you’re shift-based, multi-state, or your business loses meaningful revenue during downtime, after-hours coverage is non-negotiable. Internal-only struggles here. Both managed and co-managed models include 24/7 monitoring and response from a proper NOC.

What’s the compliance picture?

If you’re in healthcare, financial services, government-adjacent, or you handle sensitive client data with regulatory implications, get specific about what controls you need. Essential Eight maturity, ISO 27001, ADHA, APRA — these change the conversation. A good MSP will speak this language. An MSP that doesn’t is a red flag regardless of which model you choose.

FAQ

Can I switch from managed to co-managed later if I hire an internal IT person?

Yes, and a decent MSP will welcome it. The scope shifts — your internal person takes on the user-facing work, and we re-carve the responsibilities. Pricing usually drops because we’re doing less of the day-to-day, though not as much as you might expect, because the high-value work (monitoring, security operations, after-hours) stays with us. Get the boundary changes documented before the new hire starts.

What’s the minimum business size where fully managed makes sense?

Around 5 staff. Below that, the per-user pricing model can feel steep relative to the actual support load, and ad-hoc engagements often suit better. From 5 staff upward, the maths starts working — you’re getting a help desk, monitoring, patching, backups, security, and after-hours for less than you’d pay a junior IT person.

Does co-managed mean my internal IT person gets demoted or sidelined?

If it’s set up properly, no — the opposite. The internal person typically becomes the technical owner of the relationship, the person who decides priorities, and the senior point of contact. The MSP works to their direction on most things. Where it goes wrong is when the MSP tries to take over, or when leadership treats the internal person as redundant. Set the framing early and revisit it quarterly.

How do I tell if an MSP is good before signing?

Ask for the engineer-to-client ratio, where the engineers are employed (Australia or offshore), whether you’ll get a named technical lead, what’s actually in scope versus billable, and what their average response time is for high-priority tickets. Ask for two reference clients of similar size and industry. If they hedge on any of these, walk. At TechAssist we publish our response targets (sub-15-minute on high-priority), our team size (13 Australian-employed engineers), and our pricing structure publicly because we’d rather have those conversations up-front.

Can I run fully managed for the main business and internal IT for a specific division?

Yes, and it’s more common than people realise. A manufacturing business might run fully managed across head office and the warehouse, but keep an internal IT person dedicated to the production floor systems. A medical group might outsource the corporate office but keep clinical IT internal. The key is clean boundaries and a single point of accountability for cross-domain issues.

The honest answer

There’s no universally right model. There’s a right model for your business at its current size, with its current internal capability, in its current growth phase, with its current compliance burden. Two years from now the answer might be different.

The wrong model is usually expensive in ways that don’t show up immediately. A solo internal IT hire in a 25-person business looks like control — until they resign. A bargain-basement MSP in a 60-person business looks like savings — until the third major incident in a quarter. Hiring an internal team in a 40-person business looks like maturity — until you realise you’re paying $400k for capabilities a $90k-a-year MSP would have covered better.

If you want a second opinion that doesn’t end with us trying to sell you something you don’t need, give us a call on 1300 028 324 or get in touch via our contact page. We’ll tell you honestly which of the three models fits, even if it’s not us. If you’re specifically weighing up MSP options in Melbourne, our Melbourne managed IT services page lays out exactly what we cover, what we charge, and what the SLAs look like.

An internal IT team overwhelmed by demand looks like this: a growing ticket backlog, the same problem fixed for the third time this month, projects perpetually “next quarter”, and a senior tech who hasn’t taken a proper holiday since 2023. Work gets done — barely — but nothing improves.

If that sounds familiar, you’re not alone. We see it constantly across Melbourne — particularly in firms that grew from 30 staff to 120 over a few years without rebuilding the IT function to match. This article is for business owners, GMs and CFOs who already have an internal IT team of one to three people and are starting to notice the cracks. It’s a different problem from businesses with no formal IT support at all — those firms need a starting point. You need to fix something that’s already there.

Why this matters now

An overwhelmed internal IT team is one of the most expensive problems in a mid-sized business, and it’s almost always hidden. The salaries are already paid. The tickets are eventually closed. From the outside, IT looks “fine.” But underneath, three things are happening: security work is being skipped, your best technical person is quietly burning out, and the business is paying senior-engineer wages for help-desk work.

None of that shows up on a P&L line until something breaks. Then it shows up as a ransomware incident, a key resignation, or a $90,000 project that overruns by six months.

What “overwhelmed” actually looks like

Forget the abstract definitions. Here are the observable signs we walk into when a Melbourne business calls us about co-managing their IT.

1. The ticket backlog never shrinks

Healthy internal IT teams clear what comes in each week, with a slow-burn project queue running underneath. Overwhelmed teams have a backlog that grows steadily — 40 open tickets becomes 80, then 150. The team isn’t lazy. They’re triaging the loudest problem, fixing it, then moving to the next loudest. Nothing strategic gets touched.

A useful test: ask your IT manager how many tickets are older than 30 days. If they don’t know, or the number is above 10% of monthly volume, you have a capacity problem.

2. Projects have been “next quarter” for a year

Server replacement. Entra ID tenant cleanup. Backup verification. Migrating off that one legacy app nobody wants to touch. These projects sit on the roadmap because everyone agrees they’re important, but the team is too busy fixing today’s problems to start them. This is the clearest sign that the day-to-day load has consumed the team’s strategic capacity.

3. Security work is the first thing to get skipped

Patching schedules slip. MFA rollouts stall at 70%. Conditional access policies never get tightened past the defaults. The internal team knows it matters — they’re not negligent — but security work is usually invisible until it isn’t, so it loses every battle for time against a user who can’t print.

4. Everything breaks when Mark goes on holidays

Key person dependency is the dead giveaway. If your senior tech takes two weeks off and the team can’t function — passwords can’t be reset for certain systems, the firewall config is a mystery, nobody else knows how the backup actually works — you don’t have an IT team. You have one person and some helpers. This is fragile and it gets worse over time, because Mark stops documenting things he doesn’t have time to document.

5. Documentation is non-existent or three years stale

Ask to see the network diagram. Ask where the admin credentials are stored. Ask for the runbook on restoring email if the tenant goes down. If the answer is “it’s in Mark’s head” or “we had one but it’s old,” your team is past capacity. Documentation is the first thing that goes when people are flat out, and the absence of it makes everything slower.

6. After-hours work has become routine

Patching on Saturday nights. Answering Teams messages at 9pm. The senior engineer logging in from home on Sunday to fix the accounting export before Monday morning. Occasional after-hours work is part of the job. Routine after-hours work means the team is doing two jobs in one week and one of them is being done on personal time. It ends in resignation, usually with three weeks’ notice.

7. Your IT manager is doing tier-1 tickets

If the person you hired to run IT strategy is resetting passwords and unjamming printers, you’re paying $140k for $60k work, and the strategy isn’t happening. This usually means the team is short one or two technicians and the manager has been absorbing the gap.

8. Vendors are managing the team instead of the other way around

The internet provider, the phone system vendor, the line-of-business app support team — they’re all calling the shots about when things happen, because the internal team doesn’t have time to push back or coordinate. You start finding out about changes after they happen.

A concrete example

A professional services firm in South Yarra came to us last year. About 85 staff, two internal IT people — a manager and a junior. On paper, that’s a reasonable ratio. In practice, the manager was working until 7pm most nights, taking calls on weekends, and hadn’t started the Microsoft 365 security baseline project that had been approved 14 months earlier.

The junior was good but couldn’t operate without supervision on anything past tier-1. When the manager took annual leave over Christmas, the firm had three outages in two weeks because nobody else knew the environment.

The owner’s first instinct was to hire a third person. That would have helped, eventually — but the recruitment timeline alone was three to four months, and onboarding another six weeks before they were useful. Meanwhile the manager was 90 days from resigning. We don’t say that hypothetically; he told us so on the second meeting.

We ended up co-managing with them. Our team took over the after-hours load and the tier-1 ticket queue. Their manager kept ownership of strategy and the relationship with the business. Within six weeks the backlog was down 70%, the security project was running, and the manager was taking weekends off again. He’s still there.

Your three real options

When an internal IT team is overwhelmed, there are realistically three responses. The honest answer is that the right one depends on your situation — there’s no universal best.

When hiring is the right call

If your business is genuinely growing — adding 20+ staff per year, opening new sites, expanding the application stack — and you’ve got the management bandwidth to onboard and supervise, hiring is often correct. A third internal tech who knows the business deeply is worth a lot. Just be honest about the timeline. You’re not going to feel relief for six months.

When promoting works

Sometimes the team is fine but the structure is wrong. The senior tech is doing manager work informally, the junior is ready for more, and a quick reshuffle plus clearer responsibilities solves 60% of the problem. This works best in smaller teams where the issue is role ambiguity rather than headcount.

When co-managed makes sense

If your internal team is solid but drowning, co-managed IT is usually the fastest way to relief. The MSP takes over the predictable, repeatable work — tier-1 tickets, after-hours coverage, patching, monitoring — and your internal team gets back to the strategic work they were hired for. Done well, your manager keeps their job satisfaction and your business keeps the institutional knowledge.

This isn’t the same as fully outsourced managed IT, which replaces the internal team. Co-managed augments them. The distinction matters when you’re talking to staff about what’s changing.

What to look for in an MSP if you go co-managed

If you do head down the co-managed path, the wrong MSP will make your problem worse. They’ll squabble with your internal team over territory, fail to document what they do, and slowly position themselves to replace your internal staff. The right MSP behaves like a senior colleague to your IT manager, not a competitor.

• Australian-based engineers. Co-managed only works with tight collaboration, and that’s harder across time zones. TechAssist runs with 13 engineers, all Australian-employed.
• Real after-hours coverage. Not a voicemail and a callback. Our 24/7 Network Operations Centre at Tecoma in the Dandenongs handles overnight monitoring and incident response, which is exactly the load that’s killing your internal team.
• Fast response on critical issues. We target sub-15-minute response on critical tickets. If your internal team knows that backup is there, they sleep better.
• Clear scope. You should be able to draw a line between what the internal team owns and what the MSP owns, and update it as things evolve.
• Documentation discipline. The MSP should be feeding documentation back to your team, not hoarding it as job security.

If you’d rather discuss your specific situation, our team in Melbourne is happy to have a no-pressure conversation. Call 1300 028 324 or use the contact page. We’ve been doing this since 2014 and we’ll tell you honestly if co-managed isn’t the right fit.

What not to do

A few patterns we see that don’t end well:

• Hiring a junior to “help” a drowning senior. The senior now has less time, because they’re supervising the junior, and the junior can’t take work off their plate for six months.
• Buying tools instead of capacity. A new RMM platform or ticketing system doesn’t fix the problem. It just gives you better visibility into the backlog.
• Asking the team to “be more efficient.” They’re already running flat out. Telling overwhelmed people to work smarter is how you get a resignation.
• Ignoring the documentation gap. If you don’t fix it, the day Mark resigns is the day you discover what you don’t know.

How to decide

Pick a quiet week and do three things. First, sit with your IT manager for an hour and ask them honestly what they’d change if they could. Second, look at the ticket data — volume, age, recurrence. Third, look at the project roadmap and ask which things have been on it for more than six months and why.

If the answers point to “we need a person who can take ownership of this whole function long-term,” hire. If they point to “we need predictable capacity now, especially after hours,” look at co-managed. If they point to “the whole IT function is broken and we don’t have anyone capable of running it,” that’s a conversation about fully outsourced IT support.

FAQ

How do I know if my internal IT person is overwhelmed or just bad at their job?

Look at trajectory. A good person who is overwhelmed will be doing things in the right order — critical first, easy wins next — and will be honest about what’s not getting done. A bad hire will be busy on the wrong things, defensive about backlog, and surprised by problems they should have seen coming. If you’re not sure, get an outside review of the environment. The state of documentation, patching and backups will tell you quickly.

Won’t bringing in an MSP make my internal team feel threatened?

It can, if you handle it badly. The framing matters. Co-managed IT is being introduced because the business has grown beyond what one or two people can sustain — not because the internal team has failed. The good ones are usually relieved. The ones who feel threatened often turn out to be the ones quietly hoping nobody finds out what they haven’t been doing.

How much does co-managed IT cost compared to hiring?

A mid-level Melbourne technician costs around $90-110k loaded once you add super, leave, training and overheads. Co-managed engagements vary by scope, but for a 50-100 staff business expect to spend less than a full-time hire while getting after-hours coverage, multiple skill sets and no recruitment risk. The honest answer is to get specific quotes against your environment.

Will my internal IT manager lose authority if we bring in an MSP?

Not if the scope is clear. In a proper co-managed setup, the internal manager owns strategy, vendor relationships and business context. The MSP owns execution capacity, after-hours coverage, and specialist skills they wouldn’t otherwise have access to. The manager becomes more effective, not less.

How fast can we actually get relief?

Faster than hiring. A reasonable co-managed onboarding is 4-6 weeks to fully embedded, but a good MSP will be absorbing tickets and after-hours load within the first two weeks. Compare that to a 3-4 month recruitment timeline plus onboarding. For a team that’s already burnt out, that gap matters.

The honest summary

An overwhelmed internal IT team is a solvable problem, but only if you name it early. The longer it runs, the more you lose — first in projects, then in security posture, then in your best person walking out the door. Hiring, restructuring and co-managed are all valid responses. Pick the one that matches your actual situation, not the one that feels least disruptive.

If you’d like a Melbourne-based perspective on which option fits your business, the team at TechAssist is happy to walk through it. We’ve been doing this since 2014 and we’d rather tell you honestly what we’d do than win work we shouldn’t have.

Co-managed IT makes sense when your internal IT person is drowning in user tickets and hasn’t touched the firewall in six months, when you’re growing past 80 staff and the after-hours pages are killing morale, or when your one IT hire just resigned and you can’t risk another single point of failure. It’s a split, not a replacement.

That’s the honest version. The marketing version — “best of both worlds, all the benefits, none of the trade-offs” — is what most MSPs will tell you. Sometimes it’s true. Often it isn’t. This piece is the conversation we have with Melbourne SMEs who ring us at 1300 028 324 asking whether co managed it services are right for them, and the answer is genuinely “it depends” — but the dependencies are knowable.

We’ve been running this model with Melbourne businesses since 2014. Some engagements have been outstanding. A handful have been awful. The difference between the two is almost never the technology and almost always the operational split and the politics around the internal IT person. So that’s what we’ll spend most of this on.

What co-managed IT actually is (and isn’t)

Co-managed IT means you keep your internal IT person or small team, and you bring in an MSP to handle specific parts of the stack alongside them. The internal team isn’t replaced. The MSP isn’t a back-up they call when things break. Both parties work on the environment continuously, with clearly divided responsibilities.

What it isn’t: an MSP that your internal IT person escalates tickets to when they’re stuck. That’s “ad hoc support,” and it’s a fine model, but it’s not co-managed. The difference is ownership. In a proper co-managed setup, the MSP owns whole categories of work outright — they don’t wait to be asked.

It also isn’t a stepping stone. Some businesses use co-managed as a polite way to phase out an internal IT person they don’t want to fire directly. That tends to end badly for everyone. If you want to fully outsource, look at fully managed IT services and have a direct conversation with your IT hire about what’s happening. Don’t drag an MSP in to do the awkward part.

When co-managed actually makes sense

Here are the specific triggers we see in Melbourne SMEs that point to co-managed being the right call. Not “you might consider this if” — actual triggers that move the needle.

You’re between 50 and 300 staff with one or two IT people

This is the sweet spot. Below 50 staff, you generally don’t need internal IT at all — a properly run MSP handles everything. Above 300 staff, you usually need a real internal team (3+ people) with proper specialisation, and the MSP role shifts toward niche work or project capacity. The 50-to-300 band is where one or two internal people simply can’t cover the surface area, no matter how good they are.

Your IT person is doing user support all day and infrastructure work never gets done

Classic. A construction firm in Hawthorn rang us last year — 110 staff, one IT manager, lovely bloke. He was answering 30+ tickets a day, mostly Outlook and printer issues. He hadn’t patched the Hyper-V hosts in four months. The backup hadn’t been test-restored since 2024. He knew it was a problem; he just couldn’t get to it. That’s not a competence issue, it’s a capacity issue. Co-managed fixed it: he stayed on user-facing work and projects, we took backups, patching, monitoring, security and after-hours.

You need 24/7 coverage but can’t justify a second IT hire

Paying a second internal engineer $110k+ to cover nights and weekends — when most nights nothing happens — is hard to justify. An MSP with a proper 24/7 NOC (ours runs out of Tecoma in the Dandenongs) spreads that cost across many clients. You get genuine after-hours coverage for less than half what a second hire costs.

You’ve got compliance pressure you can’t meet alone

Law firms, healthcare practices, businesses chasing ISO 27001 or working with government — the security and compliance workload is genuinely too much for one person to do well alongside everything else. Co-managed lets the internal person focus on the business while the MSP runs the security operations, patching cadence, vulnerability management and audit prep.

Your IT person is good but lonely

This one is underrated. A single IT person in a 90-staff business has no peers, no one to bounce decisions off, no one to cover holidays properly. We’ve had internal IT people tell us — quietly — that the best part of co-managed is having actual colleagues again. They ring our engineers to discuss a tricky migration the way they would have rung a workmate at their last bigger employer. Retention goes up.

When co-managed does NOT make sense

Equally important. Don’t sign up for co-managed if:

• You have fewer than 30 staff. The overhead of coordinating two teams isn’t worth it. Just go fully managed.
• Your internal IT person is openly hostile to the idea. We’ll come back to this. Forcing it never works.
• You’re trying to save money by reducing the MSP scope. Co-managed is usually cost-neutral or slightly more expensive than full management at the same staff count. If budget is the only driver, you’ll be disappointed.
• You don’t have a clear reason your internal IT person should exist. “We’ve always had one” isn’t a reason. If the role exists out of habit, fix that first.
• Your internal IT person is the business owner’s nephew. Sorry. This always ends badly. The political dynamics are unworkable.

The operational split that actually works

This is the most important section. Get the split right and co-managed sings. Get it wrong and you’ll have two teams pointing at each other when things break.

The split we use with most Melbourne SMEs:

Notice how few items are “joint.” That’s deliberate. Strategy and documentation have to be shared because they touch everything, but for any specific task someone is named as the owner. The MSP doesn’t wait to be asked to patch the firewall — patching the firewall is theirs. The internal person doesn’t escalate Outlook tickets to us — those are theirs.

The reason this works is that it eliminates the “who’s doing this?” question. When the backup fails at 2am, our NOC engineer at Tecoma sees the alert and starts working it. They don’t ring the internal IT manager first. When a user can’t print, the internal IT person handles it. They don’t open a ticket with us first.

The operational split that fails

The model we see fail most often is “everyone shares everything.” It sounds collaborative. It’s a disaster.

If you can’t draw a clear line through every operational responsibility and put one name on each side, the co-managed setup will rot within six months. Diffused ownership is worse than no ownership, because everyone thinks the work is being done.

The political problem nobody warns you about

This is the section your prospective MSP probably won’t write for you. We’ll be blunt about it because we’ve seen it kill engagements that should have worked.

When you bring an MSP in alongside an existing internal IT person, that person will feel — at minimum — uncertain about their job, and at worst, openly threatened. It doesn’t matter how many times you tell them otherwise. They’ve seen “co-managed” used as a phase-out tactic at other companies. They’ve heard the rumours. They will, consciously or otherwise, look for ways to demonstrate that the MSP is unnecessary.

What this looks like in practice:

• The internal IT person doesn’t share documentation, passwords or context with the MSP. “Oh, I’ll handle that one.” It happens for weeks.
• When the MSP recommends a change, the internal IT person finds reasons it won’t work in this specific environment.
• User complaints about the MSP — real or fabricated — get passed up to leadership without the MSP being told.
• The internal IT person quietly does work that’s the MSP’s responsibility, then mentions to leadership that they had to “fix it themselves.”
• Critical alerts get acknowledged by the internal person and not actioned, so the MSP looks slow.

This isn’t villainy. It’s a human response to feeling threatened. But it will absolutely destroy a co-managed engagement, and we’ve walked away from clients where leadership wouldn’t address it.

How to actually fix the political problem

A few things that work, in our experience:

1. Involve the internal IT person in selecting the MSP. If they were part of the decision, they own it. If it was imposed on them, they’ll resent it. Have them on the calls. Take their objections seriously.
2. Be explicit about job security in writing. If their role is safe, put it in writing. If it isn’t, don’t pretend otherwise — be honest about what co-managed means for the role over 12 to 24 months.
3. Give the internal person the more interesting work. They keep projects, strategy, user-facing wins. The MSP gets the unglamorous 2am patching and the security paperwork. They should feel like co-managed made their job better, not smaller.
4. Don’t have the MSP report on the internal person. The MSP reports on the environment. Leadership manages the internal person. Mixing those creates a snitch dynamic that poisons everything.
5. Pay attention to whether the internal person is actually engaging. If three months in they still won’t add the MSP to the documentation system, that’s a signal. Have the conversation.

Pricing — how co-managed compares

Honest pricing conversation. Co-managed isn’t cheaper than fully managed in most cases. Sometimes it’s slightly more, because you’re paying for the internal person AND the MSP, and the MSP scope only shrinks a bit (we still own the infrastructure, security, after-hours and tooling — that’s the bulk of the cost anyway).

The reason businesses pay the premium for co-managed isn’t cost savings — it’s capability and resilience. You get an IT function that doesn’t collapse when your one IT hire takes leave or resigns. You get genuine 24/7 coverage. You get specialists for things one generalist can’t keep up with (security, networking, cloud architecture). And you keep someone on site who knows the business intimately.

Our co-managed pricing follows the same per-user fixed monthly model as our fully managed service — we just adjust scope based on what the internal team owns. Full pricing transparency is on our pricing and SLA page, including the sub-15-minute response commitment for critical incidents.

A real example — a logistics business in Dandenong

To make this concrete. A logistics business in Dandenong came to us in 2023 — 140 staff across the warehouse and office, two internal IT people (a manager and a junior), running on a mix of on-prem servers, Microsoft 365, and a Warehouse Management System integrated with their TMS. Trucks moving 24/7. Tight margins.

The problem: the IT manager was burnt out. He was on-call 24/7, the junior was answering tickets all day, and any time something serious went wrong with the WMS overnight, the IT manager was woken up. He’d been there nine years. He was about to resign.

What we changed:

• Took over all infrastructure, network, security, backup and patching. Internal team handed over root credentials, joined our documentation system, and stopped doing infrastructure work entirely.
• Picked up 24/7 on-call. Our NOC at Tecoma handles all after-hours alerts and the first response on overnight WMS issues. They escalate to the IT manager only if it’s genuinely something only he can fix — which, with proper documentation and runbooks, is now maybe once a month instead of three times a week.
• The junior kept ticket queue, user onboarding, hardware refreshes, and got time to actually develop skills.
• The IT manager moved to strategy, vendor management, project work (a big WMS upgrade) and proper holidays.

Two years in, the IT manager is still there. The junior has been promoted. The business hasn’t had an after-hours outage that wasn’t resolved within the SLA. The IT manager rings us when he wants a second opinion on something, and our engineers ring him when they need warehouse context. It works.

What made it work: the IT manager was part of the decision. The scope was clear. Leadership didn’t ask us to report on him, and didn’t ask him to report on us. We solved a capacity and resilience problem, not a competence problem.

How to evaluate whether you’re ready

Quick self-assessment. If you answer yes to three or more, co-managed is worth exploring properly:

• Do you have one or two internal IT people supporting more than 50 staff?
• Has critical infrastructure work (patching, backup testing, security review) slipped in the last 6 months?
• Is your internal IT person on call 24/7 with no real backup?
• Have you had an outage in the last year where the response was slower than it should have been because the right person wasn’t available?
• Is your internal IT person also expected to handle strategic projects, but never seems to get to them?
• Are you worried about what happens if your IT person resigns tomorrow?
• Do you have compliance pressure (ISO, Essential Eight, sector-specific) that’s not being properly addressed?

If you said no to most of these and things are running smoothly, don’t fix what isn’t broken. If you said yes to most, you’re already paying the cost of an unsustainable IT setup — it’s just hidden in burnt-out staff, deferred work, and risk that hasn’t materialised yet.

What to ask a prospective MSP about co-managed

If you’re talking to MSPs about co-managed IT, here are the questions that actually surface whether they know what they’re doing. Most won’t.

1. How do you handle the relationship with the internal IT person, specifically? If they don’t have a clear answer involving early involvement and explicit scope, they’ve never properly done this.
2. What does the responsibility split look like, written down? They should be able to show you something close to the table above. If it’s vague, walk away.
3. How do you escalate when our internal IT person isn’t available? Co-managed only works if the MSP can act independently in defined areas. If everything has to route through the internal person, you don’t have co-managed, you have a slow help desk.
4. What happens if our internal IT person leaves? A good MSP can absorb the full scope within 30 days. If they say “we’d need to re-scope significantly,” they don’t have the depth.
5. Where’s your after-hours coverage actually based? “Offshore partner” usually means a slow, scripted response. We run our NOC out of Tecoma with 13 engineers, all Australian-employed. Different model, different result.

If you’d like to read more on our broader service approach, see managed IT services in Melbourne and our dedicated co-managed IT support page for how we structure these engagements. The IT support overview covers what day-to-day support looks like across both models.

Common failure modes — a checklist

If you do go co-managed, watch for these. Any of them showing up in the first six months means the engagement needs a reset conversation, not a quiet drift into dysfunction.

• Documentation in two places, neither complete.
• The internal IT person hasn’t logged into the MSP’s ticketing or documentation system in 30+ days.
• The MSP is asking the same access questions repeatedly because credentials aren’t being shared.
• Tickets are being closed by one team that the other team should have owned.
• Leadership is getting different stories from the two teams about the same incident.
• Either team is doing work outside their scope without telling the other.
• The internal IT person has stopped attending the monthly review meeting.
• Alerts are firing but nobody’s acknowledging them within SLA.

None of these are fatal individually. All of them are signals. Fix them when they’re small.

Frequently asked questions

Is co-managed IT cheaper than hiring a second internal IT person?

Almost always, yes — at least for the first 12 to 24 months. A second internal hire is $110k+ in salary plus on-costs, recruitment, equipment and ramp-up time, and you still don’t get true 24/7 cover from one extra person. Co-managed gets you specialist coverage, after-hours, and redundancy for less. Past a certain headcount (usually 250+) the maths shifts and a second internal hire becomes worth it alongside the MSP.

Will our internal IT person resent us bringing in an MSP?

Possibly, especially if they weren’t involved in the decision. The fix is to bring them in early, be honest about the scope, and make sure the work they keep is the work they actually enjoy. We’ve had internal IT people who initially resisted become the biggest advocates within six months — but only because leadership handled the introduction well.

What if our internal IT person resigns after we sign up?

A well-structured co-managed engagement can absorb the full scope within 30 days, because the MSP already owns the infrastructure, security, after-hours and documentation. You’d lose user-facing support and project capacity temporarily — but you wouldn’t have a crisis. That continuity is one of the main reasons businesses go co-managed in the first place.

How quickly can co-managed be set up?

Discovery and scoping takes about two weeks for a typical 100-staff Melbourne SME. Transition — getting the MSP onto the environment, documentation done, monitoring deployed, runbooks written — takes another 30 to 45 days. Most clients are running steady-state within 8 to 10 weeks of signing.

Do you require us to use specific tools?

For things we own (RMM, EDR, backup, monitoring, ticketing), yes — we run a consistent stack so our engineers can move fast across clients without constantly relearning environments. For things the business owns (line-of-business apps, productivity suites, internal tools), the internal team keeps choosing those.

Where to from here

Co-managed IT is the right answer for a real chunk of Melbourne SMEs in the 50-to-300 staff range, and the wrong answer for plenty of others. The difference comes down to the operational split, the politics, and whether the internal IT person is bought in. Tooling matters far less than most MSPs will admit.

If you’ve got an internal IT person and you’re wondering whether co-managed makes sense for your business, have a chat with us. We’ll tell you honestly whether it’s the right fit — including the cases where it isn’t and you’d be better off with fully managed or staying as you are. You can reach us via the contact page or on 1300 028 324. No sales pressure, no obligation, just a straight conversation about your setup.