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.

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.

When your accounting server falls over at 9:47am on a Tuesday, the postcode on your MSP’s business card suddenly matters a great deal. The difference between an engineer arriving at 10:35am and one arriving at 1:15pm is the difference between a small disruption and half a day of staff sitting around being paid to do nothing.

This is the part of choosing a managed IT provider that almost nobody talks about properly. Everyone benchmarks on price, ticket SLAs, certifications and the shiny dashboard in the sales deck. Very few prospects ask the question that actually predicts how their first bad day will go: where does your nearest engineer physically sit, and how long does it take them to be standing in my server room?

I run engineering at a Melbourne MSP. We’ve deliberately built around two offices — one in Tecoma at the foot of the Dandenongs, one at 575 Bourke Street in the CBD — and the reason for that setup is the subject of this post. Let’s get into why MSP office location in Melbourne is a real operational issue, not a marketing detail, and how to read a provider’s address like the signal it actually is.

The geography problem nobody costs out properly

Melbourne is not one city when it comes to drive times. It’s at least three. A van leaving Cremorne at 8:30am can be in Richmond in twelve minutes and in Ringwood in an hour and twenty. The same van leaving Tecoma at the same time is in Ringwood in twenty-five minutes and the CBD in just over an hour — if the Burnley Tunnel is behaving, which it often isn’t.

Most MSPs draw a circle on a map labelled “service area” and tell you they cover all of metropolitan Melbourne. Technically true. Operationally meaningless. What you actually want to know is: when something is on fire at my office in Box Hill, where does the engineer leave from, what time of day is it, and how does that translate to wheels-on-the-ground?

Here’s the rough drive-time reality for a typical weekday morning in Melbourne. These aren’t Google’s optimistic estimates — they’re what our engineers actually experience.

That last row is not a joke. A surprising number of “Melbourne IT support” providers are actually Sydney-headquartered operations with a serviced-office mail drop in Southbank and a contractor network they call when something needs hands on hardware. If your business is in Glen Waverley and your provider’s nearest actual employee is in Parramatta, your same-day on-site is going to be whatever the cheapest contractor on Airtasker is doing this afternoon.

What “same-day on-site” actually means

Every MSP website promises same-day on-site response for Melbourne metro. Read that promise carefully. Some of them mean “a technician will be on site before close of business if you log the ticket before 11am, weather and traffic permitting, subject to availability.” Some of them mean what we mean, which is: if the ticket is logged before about 2pm and the site is in the metro, an engineer is in your car park that afternoon.

The reason we can promise the second version is geography. Our Tecoma office covers the entire eastern corridor — Ferntree Gully, Boronia, Bayswater, Ringwood, Croydon, Lilydale, Mooroolbark, all the way out to the Yarra Valley — without anyone fighting the Monash. The CBD office covers the inner ring — Richmond, South Yarra, Cremorne, Collingwood, Brunswick, Hawthorn, Camberwell — without anyone fighting the freeway. Between the two offices, almost every postcode in Melbourne sits inside a 45-minute drive from at least one of our engineers, off-peak. That’s the operating envelope our managed IT services in Melbourne are built around, and it’s why our sub-15-minute response on P1 critical incidents actually holds up in practice rather than just in the contract.

An MSP working out of a single CBD office will quote you the same same-day promise, and they’ll usually keep it for inner-suburb clients. Out at Ringwood or Frankston, that promise quietly degrades into “we’ll get someone out tomorrow morning” the third or fourth time it’s tested. The contract doesn’t change. The reality does.

The case for a CBD office (when you actually need one)

I’m not going to pretend an outer-east-only MSP is always the right answer. There are very real reasons to want a provider with a genuine CBD presence, and those reasons are mostly about your people, not theirs.

If your business is headquartered in the CBD or inner ring — a law firm in William Street, a fintech in Cremorne, a consultancy in South Yarra — your staff and your decision-makers don’t want to drive to Tecoma for a quarterly review meeting. They want to walk five minutes from their desk, sit in a meeting room near Southern Cross, do an hour on roadmap and security posture, and walk back. That’s a legitimate need and one of the reasons we maintain meeting space at 575 Bourke Street.

Inner-city clients also tend to need a different style of on-site work. The issues we see at a Hawthorn architecture practice are mostly user-facing: a partner’s laptop, a printer that’s lost its mind, a meeting room AV that won’t play with someone’s MacBook. These are walk-up jobs. Having an engineer who can take a tram and be at your front desk in twenty minutes, no parking fee, no van required, is genuinely more efficient than dispatching a vehicle from forty kilometres east.

Here’s where the CBD-only MSP makes sense:

• Your offices are all inside the inner ring (roughly Footscray to Hawthorn, Brunswick to St Kilda)
• Your on-site needs are mostly user support, not server/network/cabling work
• You don’t have warehouses, manufacturing sites or distribution centres in the outer suburbs
• Your senior team wants to meet face-to-face often, and they don’t want to leave the CBD to do it

If that describes your setup, a good inner-Melbourne MSP can absolutely look after you. Our IT support in Melbourne serves a lot of clients in exactly this profile.

The case for an outer-east office (when you actually need one)

Now flip it. Plenty of Melbourne businesses are headquartered or operationally based in the east — Box Hill, Doncaster, Ringwood, Bayswater, Knoxfield, Scoresby — or out toward Dandenong and the south-east industrial belt. For these clients, having an MSP whose nearest engineer is in the CBD is genuinely worse.

We worked with a logistics business in Dandenong a couple of years back, before they came across to us. Their previous provider was a well-known Melbourne MSP with a single Collins Street office. The contract promised four-hour on-site response. In practice, with the Monash being the Monash, every site visit became a half-day write-off for the engineer and a multi-hour wait for the client. The client was paying senior engineer rates for someone who spent forty per cent of their billable time in traffic. We took the account over, started running it out of Tecoma, and the average on-site arrival dropped from about three hours to under forty-five minutes. Same SLA on paper. Completely different lived experience.

The outer-east-only MSP makes sense when:

• Your business is in the eastern, south-eastern or outer-suburban belt
• You have physical infrastructure that needs hands on it — servers, network gear, structured cabling, factory floor PCs, warehouse barcode systems
• You don’t need anyone driving into the CBD to meet your team — your senior people are happy to meet at your office or at the MSP’s office in the east
• You want client parking that doesn’t cost $18 an hour (our Tecoma office has free off-street parking, which sounds trivial until you’ve tried to host a client meeting in Melbourne city)

For these clients, our IT support for the eastern suburbs is run end-to-end out of the Tecoma office, with engineers who actually live in the area. That last bit matters more than people realise, and we’ll come to it.

Why two offices is the honest answer for most mid-size businesses

Here’s the thing nobody in the MSP industry wants to say plainly: most Melbourne SMEs in the 20-150 staff range don’t fit neatly into either box. They have a head office in the inner ring and a warehouse in Bayswater. Or a CBD showroom and a manufacturing site in Dandenong. Or three sites scattered from Werribee to Glen Waverley because that’s where the property was available when they were growing.

For these clients, the right answer is a provider with real coverage on both sides of the city. Not a marketing claim of city-wide service, but actual engineers leaving from offices on both sides of the Monash. That’s the reasoning behind our two-office structure, and it’s not a coincidence that almost every multi-site client we’ve onboarded in the last few years has cited geography as one of the deciding factors.

The comparison looks something like this:

You’ll notice the two-office model wins or draws in every row. That’s not me being clever — it’s just that having a second office is mostly a cost the MSP absorbs to give the client optionality. For us, running both our CBD office at 575 Bourke Street and our Tecoma office means a 13-person engineering team can be deployed from whichever location makes sense, and clients aren’t paying for an hour of drive time on a thirty-minute job.

After-hours and on-call: where geography becomes brutal

Daytime drive times are one thing. The 2am call when a ransomware indicator fires on your file server is another.

After-hours support is the part of MSP work where the location of the engineer’s home — not the office — becomes the actual variable. An on-call engineer who lives in Belgrave can be at a client site in Ferntree Gully in eight minutes at 3am. An on-call engineer who lives in Footscray can’t, no matter what the SLA says, because they have to wake up, get dressed, get in a car, and drive across the city on roads that are mercifully empty but still finite.

This is the bit you can’t really fix with policy. You can only fix it by hiring engineers who live in the geographic spread your client base needs. Our team is deliberately mixed: some live in the eastern hills near the Tecoma office, some live in the inner north and west near the CBD office, a couple are in the south-east. That spread is the actual on-call coverage, not the rota on a wall.

When you’re vetting an MSP, the question to ask isn’t “do you offer 24/7 support?” — everyone says yes. The questions are: where do your on-call engineers live? Are they employees or third-party contractors? What’s the typical actual response time to a P1 after-hours incident in the last six months? If they can’t answer the first two without checking, that tells you something about how the after-hours service really works.

Parking, meeting rooms and the unglamorous logistics

This sounds trivial. It isn’t. When you visit your MSP — for a quarterly business review, a security workshop, a roadmap session — the experience of getting there sets the tone for the meeting.

If your provider’s only office is in the CBD, your visit means: book a park at Wilson’s for forty bucks, walk three blocks, sit in a borrowed meeting room on the eighteenth floor, watch the clock because your park expires at 2pm. Or take public transport in, lose ninety minutes of your day, and arrive slightly frazzled.

If your provider has an outer-east office with real parking, your visit means: drive in, park out front for free, walk into a meeting room that the MSP actually owns rather than rents by the hour. For clients based anywhere in the east, that’s a one-hour visit instead of a half-day excursion.

It also matters for the inverse — when the MSP visits you. An engineer dispatched from a CBD office to a client in Knoxfield is going to bill you for at least an hour of travel each way during peak. An engineer dispatched from Tecoma is going to bill twenty minutes. Over a year of on-site technical support visits, that’s not a rounding error — it’s thousands of dollars of avoidable travel time.

The Sydney-pretending-to-be-Melbourne problem

I touched on this earlier and want to come back to it, because it catches people out. There are a handful of larger MSPs operating in Australia where the head office, the engineering team, the NOC and the help desk are all in Sydney or Brisbane, and “Melbourne presence” means a sales rep with a Southbank address on her email signature.

You can usually spot this by reading the website carefully. Look for the office addresses (real street addresses, not just “Melbourne, VIC”), look for the team page with engineers whose LinkedIn says they live in Melbourne, and check who answers the phone when you call. If the receptionist says “thanks for calling [company], how can I direct your call?” without naming a city, and you can’t find a Melbourne-based engineer on staff, you’re dealing with a Sydney shop with a Melbourne mailbox.

That isn’t always disqualifying. For purely remote-managed services — cloud, M365, SOC monitoring, that kind of thing — geography genuinely doesn’t matter. But the moment your environment needs hands on hardware, or your team wants someone in the room, the cracks show up fast. Our team is thirteen engineers, all directly employed, all based in Melbourne. We don’t subcontract on-site work. That’s deliberate, and it’s one of the things you should be probing for when you talk to any provider.

What to actually ask when you’re evaluating an MSP

If you’re partway through choosing a new provider — or thinking about switching — here’s the location-related checklist I’d run through before signing anything. None of these questions are aggressive; they’re just specific enough that the answers tell you the truth.

1. Where is your nearest physical office to my main site, and what’s the actual address?
2. How many of your engineers live within thirty minutes of that office?
3. If we log a P1 ticket at 10am from my main site, who dispatches, from where, and what’s your last-six-months average?
4. For after-hours P1, where does the on-call engineer leave from?
5. If we need a face-to-face meeting at your office, where do we park and what does it cost?
6. Is on-site work done by your employees, or do you sub-contract it?
7. For multi-site clients, can you cover all sites from a single office, or do you have multiple offices we should know about?

You don’t need to grill the salesperson. Just ask, listen to whether the answers sound rehearsed or specific, and notice whether they can give you names and addresses or whether they retreat into language about service areas and coverage zones.

Where TechAssist sits in all this

To be straightforward about our own setup, because the post is about office location and we’d be dodging if we didn’t lay our cards down: TechAssist has been operating since 2014, has thirteen engineers all employed directly in Melbourne, and runs out of two offices — Tecoma (with free parking, covering the eastern corridor and outer east) and 575 Bourke Street in the CBD (covering the inner ring). We commit to sub-15-minute response on P1 critical incidents and same-business-day on-site for Melbourne metro, and the geography of the two offices is what makes those commitments actually work rather than just sound good.

That setup suits a particular kind of client: Melbourne-based SMEs, typically 20-150 staff, with at least some physical infrastructure or sites that need on-site attention, and senior people who don’t want to be playing geography roulette every time something breaks. If that sounds like your situation, our locations page has the addresses and direct numbers for both offices, or you can reach us on 1300 028 324.

Frequently asked questions

Does it really matter where my MSP’s office is if most support is remote?

For day-to-day helpdesk tickets — password resets, software issues, M365 administration — no, geography is largely irrelevant. Where it matters is the 5-10% of issues that need physical presence: hardware failures, network gear, on-site project work, staff inductions, quarterly reviews, and any kind of emergency where a remote session won’t cut it. Across a year, those incidents are where you find out whether your provider’s address is operationally real or just a line on the website.

Is a CBD-based MSP automatically worse for businesses in the outer suburbs?

Not automatically, but the maths is against them for anything that involves drive time. A good CBD-only MSP serving an eastern-suburbs client will lean heavily on remote support and book on-site visits in batches to amortise the travel. That works if your environment is straightforward. It starts to wear thin if you have frequent ad-hoc on-site needs, multi-site coverage, or after-hours requirements.

How do I know if an MSP is actually Melbourne-based or just claiming to be?

Look for a verifiable street address (not a serviced-office or virtual-office number), a team page with engineers whose LinkedIn profiles show Melbourne, and a local phone number that’s answered by a person rather than routed to a Sydney call centre. Ask the salesperson where the engineers who’d be assigned to your account physically work from. If the answer is vague, that’s the answer.

What’s the practical difference between a one-office and a two-office MSP for a multi-site client?

Travel time and dispatch flexibility. A two-office MSP can send the closest engineer to whichever of your sites has the issue, rather than having every job leave from the same address regardless of geography. For a client with a CBD head office and an outer-suburbs warehouse, that typically halves the average on-site arrival time across the year.

What if my business is entirely cloud-based and we don’t have a physical office?

Then office location matters a lot less, and you should weight the decision toward other factors: depth of cloud expertise, security maturity, response times on remote tickets, and cultural fit. The geographic question is really about hands-on-hardware work, so if you have none of that, it drops down the priority list.

The short version

The MSP industry doesn’t talk about office location much because, frankly, most providers don’t have a good story to tell about it. They cover everywhere on the map, which is the same as saying they cover nowhere properly. The honest answer is that geography is one of the strongest predictors of how an MSP relationship will actually feel once you’re past the sales cycle and into the day-to-day grind of running your business.

If you’re weighing up providers and want to talk through how the geography of your sites maps to the right kind of support model, get in touch via our contact page or call 1300 028 324. We’ll give you a straight answer — including, if it’s the right call, that you’d be better off with someone closer to where your business actually operates.