Cloud Migration Services for Melbourne SMEs: How to Pick a Partner That Won’t Burn You

Cloud migration is the IT category where buyer disappointment is most common. The phrase covers projects from a five-day SharePoint setup to a two-year replatforming. Partners range from competent boutiques to outfits with junior consultants who will learn on your bill. Picking the wrong one locks in operational pain for five years.

This is a buyer’s guide written from the engineering side of the table. We will define what cloud migration services actually mean for an Australian SME in 2026 (mostly file server to SharePoint and OneDrive, on-prem Active Directory to Entra ID, and on-prem SQL or line-of-business systems to Azure). We will cover the three pricing models you will see and which one fits your situation. We will name the lift-and-shift trap that costs SMEs more in year three than the original project cost. And we will give you the 12 questions to ask a prospective migration partner before you sign anything.

TechAssist has been running migrations for Melbourne SMEs since we were founded in 2014. Our cloud services Melbourne team has migrated firms ranging from 8 to 250 staff, across professional services, manufacturing, healthcare, and not-for-profit. We have 13 Australian engineers, two offices (Tecoma and 575 Bourke St CBD), a 24/7 NOC, and per-user fixed monthly pricing for the run state after the migration. The engineering bias in this guide is real but the recommendations are the same we give clients we end up not working with.

What “Cloud Migration Services” Actually Means in 2026

The term has been used loosely for so long it has lost meaning. Let us define it concretely. For an Australian SME in 2026, “cloud migration” almost always means one or more of the following workstreams.

File server to SharePoint and OneDrive. This is the bread-and-butter SME migration. An on-premise file server (often a Windows Server running 2016 or 2019 that is past end-of-life on hardware) is being retired, and the file shares are being moved to SharePoint Online document libraries plus OneDrive for individual user files. The work is more nuanced than it sounds: permissions need to be modelled cleanly, mapped drive habits need to be transitioned, and the file structure usually needs to be restructured at the same time because the on-prem structure has accumulated 15 years of cruft.

On-premise Active Directory to Entra ID. The identity layer migration. Moving from a Windows Server domain controller to Entra ID as the primary identity provider, with hybrid join or full cloud join for Windows endpoints. This is the foundation for conditional access, device compliance, and most of the modern security controls. It is also the migration that quietly breaks the most legacy line-of-business applications, so the discovery work needs to be thorough.

On-premise SQL or line-of-business system to Azure. The infrastructure-as-a-service or platform-as-a-service migration. Moving a database or LOB application from on-premise servers to Azure SQL, Azure VMs, or App Service. This is where the lift-and-shift trap lives, and we will talk about it shortly.

Email migration. Moving from on-prem Exchange or a third-party mail provider to Exchange Online. This is increasingly a small workstream because most SMEs already moved email to the cloud years ago, but it still comes up for late-mover firms and for post-acquisition consolidation work.

Backup re-platforming. Moving from on-prem backup appliances to cloud-native or hybrid backup services that protect both on-prem and cloud workloads. This often gets bundled into the migration scope because the existing backup tool does not protect the new cloud workloads, and trying to bolt it on later costs more than rebuilding the backup strategy properly. See our backup and disaster recovery Melbourne 2026 guide for the broader picture.

For a typical Melbourne SME migration, two or three of these workstreams are bundled into a single engagement, with the file server and Entra ID work usually being the core, and the SQL or LOB workstream being the optional but heavier component.

The Three Pricing Models

The pricing model a partner offers tells you a lot about how they run projects. There are three common shapes for cloud migration engagements in the Australian SME market.

The honest take on which to choose: hybrid is the right answer for most Melbourne SMEs in the 30 to 100 staff range. Fixed-price discovery plus T&M build is the right answer when you have a legacy line-of-business application and the discovery phase needs to surface what the migration actually involves before anyone can credibly quote it. Full fixed price is the right answer when you have rigid budget approval processes that cannot tolerate any variance.

The model that should make you nervous: a low fixed price for an aggressive scope, where the partner is hoping to use change orders to recoup margin. This is the most common pattern of buyer disappointment we see. The kick-off feels great, the price feels right, and by week six you have approved $40,000 of change orders and the partner has rebuilt their margin on top of the original quote. The protection against this is a thorough discovery before the contract is signed.

The Lift-and-Shift Trap

This is the trap that costs Melbourne SMEs more in cloud cost over time than the migration itself. The partner takes your on-premise SQL Server, lifts it onto an Azure VM with the same specs, and shifts it to the cloud. The migration is fast, the bill at the end is low, and the project is declared a success.

The problem is what happens in year two and year three. The on-prem server was a one-time hardware capital cost amortised over five years. The Azure VM is a recurring operational cost forever. The specs that made sense on-prem (over-provisioned because hardware was hard to expand) are wasted in Azure because cloud workloads should be sized to actual load and scaled when needed. The result is a perpetual Azure bill that is two to four times what a properly designed cloud architecture would cost, with worse performance characteristics.

The fix is platform-as-a-service or refactoring during the migration, not after. Specifically: SQL Server should usually become Azure SQL Database (with elastic pool, or serverless tier for variable workloads), not an Azure VM running SQL Server. Windows Server file shares should become SharePoint and OneDrive, not Azure Files. Custom applications should be containerised or refactored to App Service where viable, not lifted onto VMs.

The reason partners default to lift-and-shift is that it is fast and low-risk for them. It avoids the architectural conversations that take time and require Azure expertise that not every partner has. It also positions them for a profitable optimisation engagement in year two, when the bill is hurting and you come back asking for help.

If you are evaluating a migration partner, the lift-and-shift conversation is the single best test of their depth. Ask them what they would do with your specific workloads. If the answer is “lift to Azure VMs first, optimise later,” that is a partner who is going to leave you paying the on-prem tax in Azure forever. Walk away. The right answer is “let us look at each workload and design the target architecture before we move, even if it takes longer up front.”

The 12 Questions to Ask Before You Sign

These are the questions we would ask if we were on the buyer side of a migration engagement. The answers will tell you more than any case study.

One. Show me the discovery deliverable from your last three SME migrations. The discovery document is the single best indicator of how seriously a partner takes scoping. If they cannot show you a sanitised example, or if the example is two pages of high-level boxes, they are not doing real discovery.

Two. How will you handle the Azure cost forecast for year one, year two, and year three? You want a projected monthly Azure bill at each milestone, with the assumptions stated. Partners who cannot do this are guessing on the cost side, and guessing means surprises.

Three. What is your specific approach to file permissions during the SharePoint migration? File permissions are where the migration’s hidden complexity lives. The right answer involves a permissions audit, a model for SharePoint sites and Teams, and a plan for the inevitable exceptions. The wrong answer is “we will replicate the existing structure.”

Four. How do you handle the legacy line-of-business application that does not support Entra ID? Every SME has at least one. The right answer involves identifying it during discovery, modelling the options (hybrid join, application proxy, replacement, retirement), and pricing the work accordingly. The wrong answer is “we will figure it out during the build.”

Five. What is your incident response if the migration goes sideways at 8pm on a cutover Saturday? You want to know who is on call, what their response time commitment is, and what the rollback procedure looks like. Cutover weekends are when migrations fail spectacularly, and you need to know there is a human and a plan when it happens.

Six. Who are the named engineers on this project, and what are their certifications? Not “our team has Azure certifications.” You want names, role descriptions, and which specific engineers will be doing the architecture and implementation. Partners who staff projects with rotating cast members give you inconsistent work quality.

Seven. What does your post-migration run state look like, and what is the handover process? Most migration disappointment is not during the migration. It is in the six months after, when something breaks and the partner is no longer engaged. You want clarity on the handover, the run state ownership, and the path to ongoing support.

Eight. Can you share a reference from a Melbourne SME of similar size and complexity, in the last 18 months? You want the reference to be both recent (so the partner is still operating at the same standard) and comparable (so the work has actually relevant similarity to yours). Generic enterprise references are not useful for SME engagements.

Nine. What happens if Azure costs come in higher than your forecast? Specifically: who eats the difference, and what is the process for re-evaluating the architecture? A partner who says “we will work with you to optimise” without committing to any responsibility is offloading the architectural risk onto you.

Ten. How do you handle change requests during the build? You want a written change request process with size thresholds, approval steps, and a commitment that changes below a certain dollar value will be absorbed rather than charged. Without this, change requests become the partner’s margin recovery mechanism.

Eleven. What is your approach to security during and after the migration? The migration is the perfect moment to uplift conditional access, MFA, application control, and Essential Eight alignment. A partner who treats security as out of scope for the migration is leaving the most valuable work on the table.

Twelve. Where will my data live geographically, and what is the data residency commitment? For most SMEs the answer is Azure Australia East or Australia Southeast, but you want this stated explicitly, with the specific workloads named. This matters more than buyers usually realise, especially for clients in government supply chain or regulated sectors.

The partner’s answers to these twelve questions will tell you who you are dealing with. The partner who hedges or generalises is the partner who will surprise you later. The partner who has specific, named, defensible answers is the partner worth talking to in detail.

A Sample Scope-of-Work Skeleton

Here is the structure of a sensible SOW for a Melbourne SME cloud migration. Adapt this for your situation. If the partner’s SOW is shorter or thinner than this, push back.

The SOW should be 25 to 50 pages for a typical mid-complexity SME migration. Less than that, the partner has not done the thinking. More than 80 pages, the partner is hiding complexity in volume.

A Melbourne Example: 65-Person Engineering Consultancy in Hawthorn

A 65-person mechanical and electrical engineering consultancy in Hawthorn engaged us in late 2024 for what they thought would be a SharePoint migration and turned into a broader cloud migration including identity, file shares, and an on-premise project management database.

The discovery surfaced more complexity than expected. The file server held about 14TB of project files including CAD models, which needed careful handling for SharePoint sync behaviour. The Active Directory had 11 years of accumulated permissions, roles, and group nesting that needed cleaning before any migration could be clean. The project management database was a SQL Server application with custom integrations to Outlook and to their cost-tracking spreadsheets that no one had documented in seven years.

The decision early in discovery: refactor where it materially reduces ongoing cost, lift-and-shift only where refactoring offered no value. SQL Server moved to Azure SQL Database (single database, with elastic pool option for future growth) instead of a VM. File shares moved to SharePoint with a redesigned site structure mapped to project workstreams rather than the old folder hierarchy. Identity moved to Entra ID with hybrid join during a transitional period, then fully cloud-joined endpoints by month six.

Timeline: 14 weeks from discovery start to final cutover, plus a 12-week post-migration support window. Cost: $148,000 fixed for the standard workstreams plus $34,000 T&M for the SQL refactor, against an internal budget envelope of $200,000. Azure run cost: $1,640 per month at steady state, against a forecast of $1,800. They are now on per-user fixed monthly managed service with us, with 24/7 NOC monitoring out of Tecoma and same-business-day on-site coverage when something needs hands on gear.

The lift-and-shift counterfactual: a partner who had simply lifted the SQL Server to an Azure VM would have charged less for the project (maybe $115,000 total) but the Azure run cost would have been roughly $3,400 per month due to the VM sizing and the SQL Server licensing on Azure. Over five years, the lift-and-shift would have cost the firm about $105,000 more in Azure spend, plus the future optimisation work to fix it. The architectural decision during the migration saved more than the migration cost over the asset lifetime.

Where TechAssist Sits in the Partner Landscape

We are honest about our positioning. We are not a Big Four consulting firm and we do not bid on $5m enterprise transformations. We are not a one-person operation working from a home office. We are a mid-market Melbourne MSP with 13 Australian engineers and the scale to handle SME migrations end-to-end while still being a partner you can call and get the principal engineer on the phone.

Our sweet spot is 30 to 250 staff Melbourne SMEs, professional services and skilled industries, where the migration needs to be done properly the first time, on a budget that is real but not unconstrained, with a transition into a managed service relationship afterwards. Our per-user fixed monthly pricing on the run state means we are not incentivised to leave you with brittle infrastructure that creates ongoing ticket volume.

We are Essential Eight aligned and ISO 27001 capable, which matters for clients moving into regulated sectors or pursuing certifications. We sub-15-minute respond to P1 incidents and provide same-business-day on-site coverage across Melbourne metro from our Tecoma office and our 575 Bourke St CBD office.

If our positioning does not fit your situation, that is fine. The questions in this guide will still serve you well with another partner. If it does fit, we are happy to run a discovery conversation. See our MSP Melbourne overview for the broader service description, our co-managed IT support page if you have an internal IT lead, and our managed IT services Melbourne page for the full service breakdown.

For vertical-specific context, see our law firms, manufacturers, and healthcare pages. For the broader provider selection framework, our how to choose an MSP Melbourne and top managed service providers Melbourne articles cover the ground.

The Six Red Flags That Should End the Conversation

If you see any of these during the sales process, the conversation should end. We have seen each of these cause migration disasters, and the partner’s behaviour during the sales cycle is the best predictor of how they will behave during the project.

One. They quote without discovery. A partner who gives you a fixed price for a migration without spending real time understanding your environment is either selling you a project they cannot deliver, or has priced in so much risk that you are overpaying.

Two. They cannot name the engineers. The salesperson is great. The case studies are slick. The actual delivery team is a mystery. This is the pattern where you find out, after signing, that the engineers are junior offshore staff or contractors with no continuity.

Three. The Azure cost forecast is “we will optimise after migration.” This is the lift-and-shift trap signalled in advance. Walk away.

Four. The change request process is “we will handle it.” No written process, no thresholds, no commitment. This will turn into endless change orders during the build.

Five. They will not provide a Melbourne SME reference of comparable scale. Generic references and enterprise references are not useful. If they cannot point you to a comparable client in the last 18 months, they have not done the work at your level recently.

Six. They are uncomfortable when you ask about security uplift during the migration. The migration is the moment to fix conditional access, MFA, and application control. A partner who treats this as out of scope is missing the point of why most SMEs are migrating in the first place. Read our zero trust security model explained and cybersecurity services Melbourne resources for the security framing.

Frequently Asked Questions

How long does a typical SME cloud migration take?

For a 50-person business with a moderate-complexity stack (file server, on-prem AD, one or two LOB applications), the engagement runs 12 to 20 weeks from discovery to final cutover, plus 8 to 12 weeks of post-migration support. Smaller and simpler migrations can be done in 6 to 10 weeks. Larger and more complex migrations can run 6 to 9 months. Anyone promising a serious migration in 2 to 4 weeks is selling you a rushed project.

Can we keep our existing IT person and just engage a partner for the migration?

Yes, and this is a common pattern, but it requires clear scope boundaries. The partner runs the project, the internal IT person handles end-user support, change communication, and the on-the-ground coordination during cutover. Our co-managed IT support model is built for exactly this arrangement. The pattern that does not work is the internal person trying to “help” with the technical migration work in parallel, which creates accountability gaps.

What does an Azure bill for a 50-person SME look like at steady state?

Depends entirely on the architecture and what workloads you have moved. For a 50-person business that has migrated file shares to SharePoint, identity to Entra ID, and one moderate SQL workload to Azure SQL, the Azure-side bill is typically $800 to $2,200 per month at steady state. The Microsoft 365 licensing is separate and runs $30 to $50 per user per month depending on tier.

Is hybrid cloud (some workloads on-prem, some in Azure) still a sensible choice?

For some workloads, yes. Specifically: industrial control systems, very large file shares where bandwidth economics matter (some video production and CAD scenarios), and certain LOB applications with vendor support constraints. For most SME workloads, hybrid is a transitional state, not a destination. Plan to be fully in the cloud within three years of starting the migration, or you will end up paying for the worst of both worlds.

What about Microsoft 365 Copilot during the migration?

Deploy after the migration, not during. The Copilot value comes from clean SharePoint structure, properly permissioned document libraries, and a tenant that has been hardened. Trying to roll out Copilot before the migration is finished produces poor user experience because Copilot is searching across the messy interim state.

How do we make sure we are not locked into the partner after the migration?

This is the right question to ask before signing. The protections are documentation (you should own all architecture documentation, including admin credentials and root-of-trust certificates), portable architecture (avoid partner-specific tooling for the run state), and a clean handover process. Our run-state pricing is per-user fixed monthly with no lock-in clause, and the architecture we deploy is standard Microsoft and Azure constructs that any competent partner can take over if you ever decide to move. Reach our team via the contact page for a discovery conversation.

Hospitality IT is a niche of its own. A Friday 7pm POS failure is a revenue event. A dropped EFTPOS during Saturday service costs you walk-outs, comped meals, and angry reviews. Technology decisions venues make casually, based on what the previous chef used, set the operational ceiling for the next five years.

This guide is the practical version for Melbourne hospitality operators. We will walk through the actual POS landscape (Lightspeed, Square for Restaurants, Hub by Now Book It, Impos), the reservations platforms (SevenRooms, OpenTable, Now Book It), the payments stack (Tyro, Mx51, Square), the customer Wi-Fi versus staff Wi-Fi separation that catches almost every venue out, RSA and compliance data storage obligations, and what after-hours support actually costs when you do the maths honestly. Plus the four big hospitality IT traps we see in every second venue we onboard.

TechAssist supports a number of Melbourne hospitality clients across Carlton, Fitzroy, South Yarra, and the CBD. Our managed IT services Melbourne team treats hospo as its own discipline because the failure modes are different. P1 incidents are responded to in under 15 minutes from our 24/7 NOC at Tecoma, and same-business-day on-site coverage across Melbourne metro is standard. For Friday and Saturday service, that is the only response window that matters.

The Melbourne Hospitality Stack: What Actually Gets Used

Let us start with the realistic landscape. We are not going to list 47 vendors. We are going to list the platforms that we genuinely see deployed in Melbourne venues, the size of operation each fits, and where each one shines or struggles.

POS Platforms

Lightspeed Restaurant remains the dominant cloud POS for Melbourne mid-tier venues. Sit-down restaurants, gastropubs, mid-sized cafes. Strong reservations integration, decent inventory, solid reporting, and a maturing payments stack. Where it struggles: large multi-venue operators with central kitchen workflows, and any venue that needs deep table management with floor plan complexity beyond moderate.

Square for Restaurants is the price leader and is genuinely good for cafes, casual dining, and bar-led venues under about $1.5 million revenue per year. The hardware ecosystem is clean, the back-of-house is intuitive, and payments are baked in (which is a feature for some operators and a constraint for others). Where it struggles: high-volume Friday-Saturday service in venues that need granular table management or complex menu modifiers.

Hub by Now Book It is the Australian hospitality platform that has been quietly winning the multi-venue mid-market. Especially strong in venues that prioritise reservations as a strategic capability. Reservations and POS are in one ecosystem, the Australian support is genuinely responsive, and the reporting is built for owner-operators. Where it struggles: venues that have already committed to a different reservations platform and do not want to consolidate.

Impos remains a serious option for venues that need on-premise resilience and deeper customisation. It is the option we see most often in established Melbourne CBD restaurants that have been running for ten-plus years and want offline-capable hardware. The Australian provenance is real and the support is local. Where it struggles: greenfield deployments where the operator wants a cloud-first stack with minimal hardware on premises.

Reservations Platforms

SevenRooms is the platform of choice for venues that treat guest data as a strategic asset. The CRM, the marketing automation, and the guest profiling are deeper than the alternatives. Used by most of the higher-end Melbourne dining group operators. The cost reflects the depth, and the platform is overkill for cafes or casual venues.

OpenTable is the global brand with the broadest discovery reach, especially for international visitors. The booking funnel converts well and the diner-facing experience is polished. The downside is the cover fee model, which adds up quickly for high-volume venues, and the integration depth is shallower than SevenRooms.

Now Book It (the reservations product, separately from Hub POS) is the Australian-grown option with strong local support and a fee model that suits high-volume operators better than OpenTable for many configurations. Good ecosystem integration including with Hub POS.

The reservations decision is less binary than POS because most venues run one reservations platform integrated to whichever POS they chose for other reasons. The integration quality between your POS and your reservations platform matters more than which reservations brand you choose.

Payments

Tyro is the dominant Australian merchant for hospitality. Integrates cleanly with Lightspeed, Hub, Impos, and several others. Reliability has improved significantly since the 2023 outage that affected a chunk of Australian hospo overnight, and the surcharge and fee structure is reasonable. The integration with Xero for end-of-day reconciliation is good.

Mx51 is the increasingly serious challenger, particularly for venues that want flexibility on the back-end acquirer relationship. Better suited to multi-venue operators with banking arrangements they want to preserve.

Square’s integrated payments work well for Square POS users and not at all for everyone else. If you are on Square POS, this is the natural answer. If you are not, it is irrelevant.

The honest take on payments: the difference between the major providers on rate is a few basis points. The difference on reliability and the failover story for when the integrated terminal stops working is huge. Always have a backup terminal that is not on the same network and not on the same provider. We will come back to this in the traps section.

Customer Wi-Fi vs Staff Wi-Fi: The Separation Almost Every Venue Misses

This is the most common Melbourne hospitality IT failure mode we see. The previous IT person or the NBN installer set up one Wi-Fi network. Staff use it, guests use it, the POS uses it, the EFTPOS uses it, the music streaming box uses it, the kitchen printer uses it, and the smart fridge thermometer uses it. Everything sits on the same flat network, and one compromised guest device can poke at everything else.

The correct configuration is three logically separated networks. Each on its own VLAN, with firewall rules between them.

That is the baseline. A venue with this structure has, in one configuration change, removed the most common Melbourne hospo network risk: an attacker pivoting from customer Wi-Fi to the POS network and capturing card data, or to the EFTPOS terminal and capturing transaction streams.

The cost to deploy this for a typical 80-seat Melbourne venue is roughly $3,500 to $5,500 in UniFi hardware plus six to ten engineer hours. The cost of not deploying it is, eventually, a card data incident, an insurance claim, and a regulator conversation. We covered the realistic cost of an incident in another article: for a venue, the productivity and revenue loss from a multi-day outage of POS or EFTPOS during peak service is brutal.

Our cybersecurity services Melbourne team treats network segmentation as table stakes for any hospitality client. Read our zero trust security model explained guide for the broader framework view.

RSA and Compliance Data Storage

Hospitality venues store more regulated data than they realise. RSA compliance records, ID verification records (especially for late-night venues), staff working hours under Fair Work, guest data including reservations preferences and dietary requirements, and CCTV footage of both staff areas and customer areas.

Each category has its own retention rules and access controls. The traps we see most often:

One. CCTV footage stored on a DVR with a default password, with no retention policy, and with access for anyone who knows the office PIN. The Australian Privacy Act applies to the CCTV footage in most venue configurations because the venue is collecting personal information about identifiable individuals. The retention should be defined (typically 28 to 90 days), access should be controlled, and there should be a process for handling subject access requests if they come up. They do come up, especially after incidents involving staff or patrons.

Two. Staff records stored on the kitchen office PC, with a shared password, and never backed up. This is a multi-failure scenario. The records are required for Fair Work compliance. If the PC dies (and the kitchen office PC always dies eventually because of the kitchen environment), the records are gone. The fix is moving staff records to a cloud HR platform like KeyPay, Tanda, or Deputy, which gives you backup, access control, and audit trails for free.

Three. Guest data being treated as the property of whichever staff member set up the reservations platform. When that staff member leaves, the data either goes with them or becomes inaccessible. The fix is treating the reservations platform as a business system with ownership clarity, admin access controlled by the operator, and exported backups on a regular cadence.

Four. Tip records, payroll exports, and EFT batch files stored on shared drives without access control. Anyone with the office Wi-Fi password can read or modify them. The fix is moving these to a properly permissioned cloud storage location with audit logging, and ensuring only operations and finance staff have access.

For the broader privacy framework, see our Australian Privacy Act for SMBs guide. Most hospitality venues fall under the Privacy Act because they collect personal information about identifiable individuals at scale, and the data handling expectations are not different from other industries even though the venue context feels different.

The Four Hospitality IT Traps

These are the four traps we see in roughly every second Melbourne hospo venue we onboard. None is exotic. All are preventable.

Trap One: Shared Admin Passwords

The POS admin password is “Manager01” or the year the venue opened. Every manager has it. The departing dishwasher had it. The casual who worked one shift in 2022 had it. There is no audit trail of who used it for what, and changing it is a multi-week project because no one is sure where it has been written down.

The fix is structural. POS admin access should be per-user, with named manager accounts and a clean offboarding process when staff leave. Most modern POS platforms support this; the venue just has not configured it. Add MFA on the POS admin login wherever the platform supports it. Change the back-of-house Wi-Fi password every time a manager-tier staff member leaves, or move to certificate-based device authentication so passwords are not the trust anchor.

Trap Two: The Cousin Who Set It Up

The venue’s IT was set up by the owner’s cousin, who is good with computers, did it as a favour during the fit-out, and is now uncontactable on a Saturday night when the POS server has stopped responding. There is no documentation, the admin credentials are in the cousin’s head, and the network diagram is on a sticky note that came off the wall in the kitchen renovation.

The fix is engaging an MSP for the structural work and accepting that the cousin saved the venue some money during fit-out but is not a sustainable operational answer. The fit-out IT is about 5 to 10 percent of overall fit-out cost in most Melbourne venues. The ongoing IT is the part that determines whether Friday service runs smoothly for the next decade.

Trap Three: No Failover EFTPOS

The venue has one integrated EFTPOS terminal per POS. When the integrated terminal stops talking to the POS (due to a software bug, a network issue, or a bank-side problem), the venue has no way to take payments. Saturday night service becomes a queue of customers who cannot pay, walking out, or paying via tap-to-phone on the manager’s personal Square reader, which then creates reconciliation headaches.

The fix is having at least one non-integrated, non-network-connected terminal as a failover. A mobile EFTPOS that connects via 4G, not via the venue Wi-Fi. Test it monthly. Have a written procedure for the duty manager to switch to manual mode and reconcile at end of day. Cost: roughly $30 per month for a standby Tyro mobile terminal. Cost of not having it: half a Friday night’s revenue, easily $8,000 to $25,000 depending on the venue size.

Trap Four: Wi-Fi From the Modem the NBN Guy Left

The venue is running on the NBN-provided modem-router with its single Wi-Fi network, default admin password, no VLANs, and no QoS. Every device in the venue shares one collision domain. The POS, the EFTPOS, the kitchen printer, the music streaming, the manager laptop, the guest phones. When 60 patrons all join guest Wi-Fi at 8pm, the POS terminals start dropping payments.

The fix is replacing the NBN modem-router with a proper small-business gateway and access point setup. UniFi is the most common choice for SME hospo: a Cloud Gateway, one or two access points sized for the venue, and a managed switch if there are wired devices. Total hardware cost typically $3,000 to $5,500 for a single-site venue. The performance and reliability difference on Saturday night is immediate.

The After-Hours Support Cost: The Realistic Maths

Hospitality operates outside of business hours, and any IT support model that does not is dangerous. Here is the realistic maths on the three common after-hours support arrangements we see.

The honest economics: for any venue with three or more POS terminals and an integrated payments setup, the managed service maths beats break-fix the first time a Friday or Saturday incident occurs that gets resolved in 15 minutes instead of 90. The peace of mind for the venue owner is worth more than the dollar value.

TechAssist provides this for Melbourne hospitality clients out of our 24/7 NOC at Tecoma. We have 13 Australian engineers and operate two offices (Tecoma and 575 Bourke St CBD) which is the response window that actually matters for a 7pm POS incident at a Smith Street venue. Our pricing is per-user fixed monthly, so the venue knows what it costs.

A Real Melbourne Example: 110-Seat Venue in Carlton

A 110-seat Italian restaurant in Carlton engaged us in mid-2024 after the third Friday-night POS outage in six months. The previous IT person was a friend of the head chef, was reachable about 30 percent of the time outside business hours, and had set up the venue with a flat network running on the NBN-provided modem.

The discovery surfaced the typical issues. One Wi-Fi network for everything. POS admin password was “Carlton2018” and known to every current and former manager. Integrated EFTPOS on the same network as guest Wi-Fi. CCTV DVR with the manufacturer’s default password and footage retained indefinitely. Staff records on the kitchen office PC, which had not been backed up since the bookkeeper changed in 2021.

The remediation took three weeks of evenings and one full Sunday installation. We deployed a UniFi stack with three VLANs (corporate, customer, AV/IoT), moved staff records to Tanda, rebuilt POS user accounts with named manager logins and MFA, added a 4G failover EFTPOS terminal, replaced the CCTV system with a network camera setup behind authentication, and put the venue on our managed service with 24/7 NOC monitoring.

Project cost: $14,800 one-off plus per-user fixed monthly managed service. Saturday-night incidents in the eighteen months since: two, both resolved remotely in under 25 minutes. Friday-night POS outages: zero. The owner has the maths in the venue’s annual review pack and brings it up at every fit-out conversation he has with other operators.

The Fit-Out Decision: Get It Right Before Service Day One

The single highest-leverage moment in venue IT is during fit-out, when the cabling, the network gear, the POS, the EFTPOS, and the CCTV are being installed at the same time. Decisions made (or not made) during this window are baked in for the next three to five years.

The fit-out checklist that we recommend for any new Melbourne venue:

Cat6A cabling to every POS terminal location, every CCTV camera location, every wireless access point location, the office, and the bar. Wi-Fi is the operational backbone but POS terminals on hard-wired connections are dramatically more reliable than Wi-Fi-only terminals. The cost of running an extra few cables during fit-out is trivial. The cost of running them after fit-out is enormous.

Two power points at every POS location, on different circuits where possible. POS failures during service are often power failures, not software failures, and dual circuits buy you resilience.

A dedicated comms cabinet with cooling, in a location that is not the kitchen and not the cellar. We see comms cabinets in walk-in cool rooms (humidity kills gear) and over the stove (heat kills gear). A small wall-mount cabinet in the office is fine.

A proper small-business gateway and managed switch, not the NBN modem-router. Specify this in the fit-out scope so it gets installed by the network installer alongside the other gear, not bolted on three months later.

CCTV running over IP through the same managed switch infrastructure, not on a parallel coax system. The cost difference is small, the maintainability difference is large.

4G backup for the gateway. A USB 4G dongle attached to the gateway is enough. When the NBN goes down (and it will), the POS and EFTPOS keep working on the 4G backup until the NBN comes back.

For multi-site operators, talk to us about managed IT services Melbourne as a programme rather than a per-venue arrangement. The economics improve significantly once you have three or more venues in the portfolio. For venue owners who want an internal manager handling the day-to-day and our team covering the structural and after-hours work, our co-managed IT support model works well.

What This Costs for a New Melbourne Venue

A realistic IT budget for a new Melbourne hospo fit-out, separated into capital and operational.

Total capital IT investment for an 80-seat venue: typically $30,000 to $48,000 including cabling and CCTV. Total operational IT cost: typically $1,200 to $2,800 per month before payments fees. These numbers scale roughly linearly with seat count up to about 200 seats, where the economics start to shift slightly in favour of larger systems.

Frequently Asked Questions

Can we just use Square for everything?

For a cafe or casual dining venue under about $1.5m revenue, yes, and it is a sensible choice. For mid-tier and higher venues, Square POS becomes constraining once you need deeper reservations integration, multi-venue reporting, or complex table management. The economics shift around the $1.5m revenue mark.

How important is 4G failover really?

Very, and the cost is negligible. About $30 to $60 per month for a 4G data plan that sits on the gateway as a backup path. When NBN goes down during peak service (and it does, every venue eventually), the POS and EFTPOS continue working on the 4G fallback for the 90 minutes or so it takes for NBN to recover. The first time it saves a Saturday night, it has paid for years.

Do we need PCI compliance?

If you process card payments through an integrated POS, you have PCI obligations, but most modern integrated payments setups (Tyro, Mx51, Square) push most of the technical compliance burden onto the payments provider through tokenisation and point-to-point encryption. The venue’s obligations are operational: not storing card data, controlling who has access to the POS, and following the payment provider’s compliance attestation process. A managed IT provider should handle the attestation work as part of the relationship.

What about CCTV in the kitchen?

Kitchen CCTV is legal under Victorian law with appropriate signage and a documented purpose (usually safety and incident review). The Fair Work and privacy obligations apply: staff should be aware, the footage retention should be defined, and access should be controlled. We recommend kitchen CCTV for venues that handle insurance claims involving slips, burns, or workplace incidents, because the footage is often determinative.

How do we handle staff using the office PC for personal browsing?

Either accept it and treat the office PC as a low-trust device (cloud HR system, cloud accounting, no sensitive data on the local drive), or lock it down and provide a separate staff break area device. The middle ground (a shared office PC with sensitive data on it) is the worst option because it eventually leaks data either deliberately or accidentally.

How do we find a hospitality-experienced IT provider?

Ask the question directly. How many Melbourne hospo clients do they support? What is their response time for a Friday 8pm POS incident? Have they integrated each of the major POS platforms? Do they understand the fit-out window? Most general MSPs do not have hospo experience and will treat your venue like an office, which is the wrong mental model. Reach our team via the contact page and we will arrange a venue walk-through. For broader provider selection, our how to choose an MSP Melbourne and top managed service providers Melbourne guides cover the framework.

For Australian SMEs under 200 seats, the four real cloud phone options in 2026 are Microsoft Teams Phone, 3CX, RingCentral, and Aircall. Each one is the right answer for a specific business profile and the wrong answer for others. This buyer’s guide compares them honestly on cost, fit, number porting, and resilience for Australian conditions.

Why this guide exists

Most Australian buyer’s guides for cloud phone systems read like a vendor brochure with a different cover. The advice is generic, the comparisons are shallow, and the local detail (porting timelines with TPG or Aussie Broadband, ACMA implications, what happens during an outage on the NBN) is missing. We have deployed and supported all four of these platforms inside our managed IT engagements since founding TechAssist in 2014, and the local detail is where most of the cost and risk hides.

This guide is opinionated. We will tell you which platform we recommend by default for which profile, and where we have seen each one go wrong. The goal is not to sell you on a particular vendor; it is to help you make a defensible choice that you will still be happy with in three years.

The four real options

Microsoft Teams Phone

The right answer for businesses that already run Microsoft 365 E3 or E5, want one platform for chat, video, and voice, and have a relatively standard office and remote staff mix without heavy call centre or sales dialler requirements.

Strengths:

• Single identity, single client, single admin centre with the rest of your Microsoft estate
• Native Teams app on every device people already have
• Tight integration with calendar, presence, and meeting recording
• Operator Connect or Direct Routing options give flexibility on the carrier side
• Compliance and call recording aligned to the broader Microsoft 365 compliance stack

Weaknesses:

• Native call queueing and IVR are basic compared to a dedicated UCaaS or contact centre platform
• Real call centre features (skill-based routing, advanced wallboards, supervisor monitoring) require add-ons or a third-party contact centre integration
• Sales-dialler workflows are clunky; no native power dialler
• Voice quality depends heavily on the network and the device; soft phones on personal Wi-Fi can be unreliable

Best fit: professional services, accounting, legal, healthcare admin, and any organisation where the phone is a normal-volume business tool rather than the primary production system. For a 38-staff South Yarra law firm we recently deployed, Teams Phone with Operator Connect through an Australian carrier was the obvious answer because the firm already had M365 Business Premium and the call volume was about 40 inbound calls per partner per day.

3CX

The right answer for businesses that want maximum control, are comfortable with a more technical platform, and either want to self-host or run on a tightly managed instance. Also the right answer for businesses migrating from a legacy on-premises PBX who want a familiar feature set.

Strengths:

• Strong feature parity with traditional PBX systems (call queues, ring groups, advanced IVR, hot desking)
• Can be self-hosted in Azure, AWS, or on-premises; or run on a 3CX-hosted instance
• Per-system pricing rather than per-user pricing, which can be significantly cheaper at scale
• Strong third-party SIP trunk support, so you can choose your Australian carrier
• Good softphone and mobile apps; reasonable Teams integration if needed

Weaknesses:

• Requires technical administration; not a ‘set and forget’ platform
• Self-hosted instances need patching, monitoring, and backup (real infrastructure work)
• UI is functional rather than polished; staff onboarding is harder than Teams
• 3CX itself has had security incidents in recent years (the 2023 supply chain compromise) which raised concerns; subsequent response has been adequate but worth noting

Best fit: businesses that already have IT capacity (internal or co-managed), value control over the platform, and have specific feature requirements that consumer-grade UCaaS platforms do not meet. We run 3CX in our own environment and for a number of clients where the cost model and the feature set are right. For a 65-staff manufacturing business in Dandenong South, 3CX with SIP trunks from an Australian carrier and a redundant pair of instances in Azure was the right call because the on-premises requirement (a few hundred handsets across two sites with paging integration) ruled out the pure-cloud UCaaS options.

RingCentral

The right answer for businesses that want a full unified communications-as-a-service experience with a polished UI, strong analytics, and built-in contact centre options for when the business grows into them.

Strengths:

• Polished, consumer-grade user experience across mobile, desktop, and web
• Built-in video, messaging, fax, SMS, and voice in one platform
• Strong analytics and reporting out of the box
• Contact centre add-on (RingCX) is mature and integrates natively when needed
• Strong CRM integrations (Salesforce, HubSpot, Zoho) without third-party connectors

Weaknesses:

• Per-user pricing is at the higher end of the market
• Australian carrier and number porting flexibility is more limited than 3CX
• Bundle includes features many SMEs do not use, which inflates the per-seat cost
• Account management can be inconsistent; SMEs sometimes feel underserved

Best fit: customer-facing businesses with 30 to 150 staff that have outgrown a basic phone system, want a single platform across all communication channels, and have a clear customer service or sales operation. For a 72-staff e-commerce business in Cremorne we work with, RingCentral with the contact centre module was the right call because the customer service team needed proper queueing, wallboards, and supervisor monitoring that Teams Phone could not match.

Aircall

The right answer when sales or customer experience is the dominant phone use case, when CRM integration is the highest priority, and when you are willing to add another tool to your stack to get a sales-optimised experience.

Strengths:

• Built specifically for sales and CX teams; the workflows reflect that
• Excellent CRM integration (Salesforce, HubSpot, Pipedrive, Zendesk) with screen pops and automatic logging
• Power dialler, click-to-call, and call coaching features are native
• Fast to deploy; user onboarding is friendly
• Good analytics for call outcomes and rep performance

Weaknesses:

• Not designed as a general business phone system; not the right tool for receptionist or main-line scenarios
• Australian number availability and porting can be slower; mostly serves international and metropolitan use cases
• Per-user pricing is competitive but stacks with whatever else you use for general office calling
• Voice quality is heavily dependent on the user’s network

Best fit: dedicated sales or customer success teams within a larger business that already has a general phone system. We have deployed Aircall for the sales team at a Hawthorn SaaS business while leaving Teams Phone as the general business platform. The two run side by side, the sales team gets the dialler experience they need, and the cost is contained to the 12 sales seats.

Side-by-side cost comparison

The table below assumes a 50-user Australian SME with a standard mix of office calling. Prices are 2026 Australian list, GST exclusive, and assume an annual commitment. Real negotiated prices for SMEs are often 10% to 20% below list.

The cost comparison hides important differences. Teams Phone looks cheap on this view because much of the platform cost is already paid for in your Microsoft 365 licence. 3CX looks cheaper still on a pure platform basis, but the operational cost of running and maintaining the platform is real and not captured in the per-user price. Aircall is the most expensive per seat, but in practice you only deploy it to a sales team subset, not the whole business.

Number porting timelines and carriers

Number porting in Australia is the most underestimated risk in a phone system change. Promised porting timelines and actual porting timelines often diverge by weeks. The factors that matter:

Carrier of the losing number

Porting away from Telstra is typically 4 to 8 weeks for a complex port (multiple numbers on a hunt group) and 1 to 3 weeks for a simple port (single number). Porting away from Optus or TPG is similar. Smaller wholesale carriers can be faster (1 to 2 weeks) but the process is also more dependent on the human being on the other side.

Carrier of the gaining number

For Teams Phone, you can use Operator Connect carriers (multiple Australian options including TPG, Vonage, and several smaller providers) or Direct Routing through your own carrier. Operator Connect is faster to provision but you trade flexibility. Direct Routing requires a session border controller setup but gives you choice of carrier.

For 3CX, you choose your SIP trunk carrier independently. Aussie Broadband, Maxotel, and TPG Wholesale are common choices for Australian SMEs. Maxotel in particular has a reputation for responsive porting support among smaller deployments.

For RingCentral and Aircall, the carrier is bundled. You do not choose; you accept the carrier the platform uses. This simplifies the buying decision but reduces flexibility.

The porting risk plan

Whichever platform you choose, plan the port itself as a discrete project with its own risk management. Recommended practice:

• Submit port requests at least 30 days before go-live
• Keep the old service active and paid until 7 days after port completion
• Test inbound calls from at least three external networks (mobile, landline from a different carrier, international if relevant) before decommissioning the old service
• Plan a fallback path: divert old numbers to mobile during the cutover window in case of disputed port
• Have a written escalation path with both carriers; know who to call when something stalls

For complex multi-site deployments, factor in 6 to 8 weeks of porting lead time. Trying to compress this is a frequent source of go-live failures.

ACMA and ATO implications

ACMA

The Australian Communications and Media Authority regulates how Australian businesses can use phone numbers and what carriers must do. The relevant points for a cloud phone deployment:

• You must use Australian-registered numbers for Australian business operations (you cannot just use a US-issued RingCentral or Aircall number for your Australian customers)
• Emergency calling (Triple Zero) must work and must report a usable location. Many cloud phone systems require explicit configuration of E000 location data per device or per user
• Lawful intercept obligations apply to carriers, not to you directly, but your carrier must be compliant

The E000 location requirement is the one most often missed. If your staff are working from home with a softphone, the system needs to know their location at sufficient detail that emergency services can be dispatched correctly. RingCentral and Teams Phone both handle this; 3CX requires explicit configuration; Aircall is more limited.

ATO and record keeping

The ATO requires businesses to maintain records of business transactions, which can include call records for sales and customer service interactions. Cloud phone systems typically retain call records and recordings for a default period (30 to 90 days), which is shorter than the typical ATO retention requirement of 5 years.

If you record calls, you need to store the recordings somewhere durable for the retention period. Most platforms offer extended retention as an add-on or via export to your own storage. Build this into the deployment design.

Fallback plans for outages

Cloud phone systems fail. They fail less often than on-premises PBXs, but when they fail they fail completely. Your fallback plan needs to be:

• Documented in writing and tested at least annually
• Triggerable by a non-IT staff member if needed
• Capable of routing inbound calls to mobiles within 5 minutes

The standard fallback is a carrier-level call forwarding rule that activates on platform unreachable. Most Australian carriers support this for inbound DID numbers. The rule sends all inbound calls to a designated mobile (usually the reception manager) when the cloud platform stops responding. When the platform recovers, the rule deactivates.

For businesses where the phone is mission-critical (medical practices, professional services with tight client SLAs, customer service operations), consider running two carriers in active-passive configuration. The cost is meaningful but the resilience is the highest you can achieve outside of a dedicated contact centre platform.

For a Camberwell healthcare practice we manage, the phone system runs Teams Phone with Operator Connect through one carrier and a secondary direct route through a different carrier as failover. The cost premium is about $400 a month for the secondary path. They have used it twice in 18 months and both times the failover saved the day.

How to decide

The decision tree we use with clients is:

1. Do you already have Microsoft 365 E3 or E5, or Business Premium with Teams Phone add-on? If yes, start with Teams Phone unless there is a specific reason not to.
2. Is your call volume primarily sales-driven, with CRM integration as a top requirement? If yes, evaluate Aircall as a sales-team overlay on top of a general phone system.
3. Do you have a customer service team of 5 or more that needs proper queueing, wallboards, and supervisor features? If yes, evaluate RingCentral or RingCX.
4. Do you have specific feature requirements (paging integration, dense IVR, hot desking) that consumer-grade platforms do not meet, and do you have or want technical control over the phone platform? If yes, evaluate 3CX.
5. If none of the above clearly dominates, default to Teams Phone for the Microsoft 365 integration alone.

Implementation realities

Cloud phone deployments fail more often than they should, almost always for the same reasons. The four to plan against:

• Underestimating the porting timeline. Already covered above. Treat it as the critical path.
• Underestimating user training. Phone behaviour is muscle memory. Switching staff to a new system without dedicated training results in two months of awkward calls and lost business.
• Underestimating the network impact. Voice traffic competes with Teams meetings, file syncs, and everything else on the network. QoS is essential; on a typical NBN connection, prioritising voice traffic prevents call quality degradation during peak hours.
• Underestimating the headset standard. A $35 headset is not the same as a $180 business headset. Voice quality complaints are 50% headset and 50% network in our experience. Standardise on a known-good business headset and budget for it.

This kind of deployment work sits naturally inside a managed IT services arrangement with per-user fixed monthly pricing. Our 13 Australian engineers handle cloud phone deployments out of our 24/7 NOC in Tecoma and our 575 Bourke Street CBD office, with sub-15-minute P1 response when something goes wrong post-go-live. The same-business-day on-site capability for Melbourne metro matters when you have 40 desk phones to physically replace.

If you want a sharper conversation about which of the four platforms is the right fit for your specific business, get in touch. The right answer depends on context that a buyer’s guide cannot fully cover.

Frequently Asked Questions

Can we keep our existing PBX and just add cloud features?

Yes, with hybrid models. 3CX in particular supports a hybrid mode where some users are on the cloud client and others remain on legacy SIP handsets. This is a sensible transition path for businesses with significant existing handset investment. Teams Phone also supports a hybrid model through Direct Routing, where your existing PBX can serve as the gateway during migration. The hybrid period typically lasts 3 to 6 months.

What about Zoom Phone?

Zoom Phone is a legitimate fifth option that we deliberately excluded from the main comparison because in our experience it sits awkwardly between Teams Phone and RingCentral without clearly winning on either dimension for Australian SMEs. If your business is Zoom-first for meetings (which is unusual in Australian SMEs but happens), Zoom Phone is worth evaluating. For most Australian SMEs already on Microsoft 365, the simpler answer is Teams Phone.

How do we handle remote and hybrid staff with the chosen platform?

All four platforms support remote work natively through softphone clients. The practical issues are home network reliability, headset quality, and emergency calling location data. The home network reliability question often pushes businesses toward providing a mobile data backup option for staff who do customer-facing calls from home.

What is the typical implementation timeline?

For a 50-seat deployment, expect 6 to 10 weeks end to end. Two weeks for design and procurement, two weeks for tenant configuration and pilot user testing, four to six weeks for porting (often the long pole), and one week for cutover and immediate post-cutover support. Rushed implementations are the single largest source of go-live failures.

How does the choice of cloud phone system intersect with cybersecurity?

Cloud phone systems are an identity surface and a data surface. Voicemail recordings, call recordings, and contact lists are all sensitive data subject to the Privacy Act. The platform’s identity model should integrate with your existing identity provider (Microsoft Entra ID in most cases), and the call recording retention and encryption should align with your broader data protection posture. This is why we evaluate cloud phone choices as part of a broader cybersecurity conversation rather than as a standalone procurement.

What is the right number of carriers to use?

For most SMEs, one carrier with carrier-level failover (call divert on unreachable) is sufficient. For mission-critical phone use cases, two carriers in active-passive configuration. Three or more is over-engineered for sub-200-seat businesses. The marginal resilience past two carriers does not justify the cost or complexity.

IT for Melbourne Retail SMEs: POS, EFTPOS, Customer WiFi That Actually Works

Retail IT failures cost money by the minute. A POS crash during Saturday lunch in a Richmond cafe is two hundred dollars of lost trade in fifteen minutes. The retail stack is small but every component is load-bearing, and the difference between “fine most of the time” and “actually reliable” comes down to choices made early.

The four-layer retail stack

Retail IT for an independent Melbourne SME splits into four layers, and the design choices at each layer dictate how the others have to be configured. The four layers are POS, payments (EFTPOS), connectivity (internet and Wi-Fi), and back office. They need to be designed together, even if they are bought separately.

The most common pattern we see in struggling retail IT environments is that each layer was bought independently — the POS chosen by the owner, the EFTPOS bundled with the bank account, the Wi-Fi installed by a sparky during fitout, the back office sorted out years later. Individually each is fine. Together they create the support nightmare that ends with someone calling at 11am on a Saturday because the POS cannot talk to the EFTPOS terminal.

POS choices and where each one breaks

The POS market for independent Australian retailers has consolidated around four serious options, plus a long tail of niche systems for specific verticals. Each has a real sweet spot and a genuine failure mode.

The honest assessment is that there is no single “best” POS. The choice depends on what the retailer actually needs to do.

For a single-site cafe in Cremorne doing 200 transactions a day, Square for Retail is a sensible default — low setup cost, simple to operate, integrated payments, accepts the tradeoff of limited inventory features for speed of deployment. We have onboarded several Melbourne cafes on Square and the failure mode is almost always related to internet reliability, not the POS itself.

For an independent fashion boutique in South Yarra with 2,000 SKUs, a fitting room workflow, and seasonal markdowns, Square is not enough. Lightspeed Retail is the right answer, and the additional monthly cost is repaid in saved time on inventory and reporting.

For a hospitality venue with bookings, table management, and serious EFTPOS volume, Tyro’s integrated stack works well, particularly when bundled with a compatible POS like Lightspeed Restaurant or Impos.

The point is that the POS choice should follow the workflow, not the marketing. Most of the Melbourne retailers we end up helping after the fact bought the POS based on a slick demo and discovered the gaps three months in. The discovery exercise — what do you actually do twenty times a day, what do you do twice a year, where does the current process hurt — is worth doing before signing the contract.

EFTPOS failover: the part most retailers ignore

EFTPOS failure modes are predictable and the failover strategy should be designed for them.

Failure mode 1: terminal hardware fault. A specific terminal stops working. The fix is to swap to a spare unit, which means you need a spare unit. For a single-terminal cafe, this means a backup terminal kept ready behind the counter. The cost of the spare is recovered the first time the primary fails during a busy service. For a multi-terminal store, the spare can rotate between terminals.

Failure mode 2: internet outage at the store. Most modern EFTPOS terminals require an internet connection to authorise transactions. The standard 4G failover is built into many terminals as a backup, but it is worth verifying that yours has it and testing it during onboarding. Tyro, Smartpay and Square’s newer terminals all support 4G failover. Some older terminals do not.

Failure mode 3: payment processor outage. Tyro had a serious multi-day outage in early 2022 that left thousands of Australian retailers unable to process card payments. The structural fix is to have a secondary merchant facility through a different processor — for example, a Square reader as a backup to a Tyro primary, or vice versa. The monthly cost is the secondary facility’s fees (often zero if it is transaction-based) and the operational discipline to test it monthly.

Failure mode 4: power outage. A UPS on the POS, EFTPOS and internet equipment buys 15 to 30 minutes of trading during a brief power cut. This is enough to clear the queue and process pending transactions. For a Port Melbourne wine bar we look after, this paid for itself in the first month when a transformer fault took out their street for forty minutes during dinner service.

None of these failover strategies are expensive. All of them are absent in most independent retail stores we audit. The conversation worth having with your POS and EFTPOS vendors before signing is: what happens when (each failure mode), what is the recovery time, and what is the cost.

Customer Wi-Fi without a PCI nightmare

Customer Wi-Fi sounds like a freebie to offer — a nice gesture, a small acquisition tool, something the cafe next door is doing. It becomes a serious problem if the network design is naive.

The cardinal sin is putting customer Wi-Fi and POS/EFTPOS traffic on the same network. The Payment Card Industry Data Security Standard (PCI DSS) is explicit that systems handling cardholder data must be segregated from untrusted networks. A flat Wi-Fi network with the iPad POS, the EFTPOS terminal, and the customer browsing Instagram all on the same SSID is a PCI compliance failure and a real attack surface.

The correct design has at least three logical networks:

• POS / payment network: The iPad, the EFTPOS terminal, the receipt printer, the barcode scanner if networked. Isolated from everything else. No client isolation issues because it is a small trusted set of devices.
• Staff network: The back-office PC, the manager’s laptop, the staff phones if they need authenticated access. Connected to the internet but separate from POS.
• Customer Wi-Fi: Open or captive-portal authenticated, internet-only access, no visibility of any internal network. Client isolation enabled so customers cannot see each other.

The implementation does not require expensive equipment. A managed firewall and a managed access point that support VLANs and multiple SSIDs handle this entirely. The hardware cost is in the $1,500-$3,000 range for a single-store fitout, which is a one-off and lasts the refresh cycle of the equipment.

The mistake we see in audits is not that retailers do not understand this. The mistake is that the fitout sparky installed a single consumer-grade modem-router with one Wi-Fi network because it was cheap, and nobody has revisited the decision since. We rebuilt the network for a Box Hill bakery chain across four stores in early 2025 and the audit found that three of the four had customer Wi-Fi and EFTPOS on the same flat network. The remediation took two weeks and removed a serious latent risk.

In-store vs back-office split

The IT environment in a retail store splits cleanly into two zones, and treating them as one is a recurring source of operational mess.

The in-store zone is everything that needs to work during trading. POS, EFTPOS, customer Wi-Fi, in-store music system, the staff iPad they use for stock checks, the digital signage at the front. The defining characteristic is that downtime during trading hours is expensive — every minute counts.

The back-office zone is the manager’s PC, the accounting system, the rostering app, email, file storage, payroll. The defining characteristic is that downtime during the day is annoying but not directly revenue-impacting. Most back-office work can happen at 9pm or on a quiet Monday morning.

The implications for IT design are significant. The in-store stack needs the kind of monitoring and SLA you would associate with a critical system — 24/7 monitoring, proactive alerting, fast response. The back-office stack can run on the same general business IT stack that most Melbourne SMEs use.

This is also where the SLA conversation gets real. A Saturday-trading SLA needs to commit to response time during weekend trading hours, not Monday-to-Friday business hours. Most generic IT support agreements offer the latter and pretend it covers the former.

What a Saturday-trading SLA should actually say

Retail businesses trade when other businesses are closed. The standard MSP agreement that promises “1-hour response during business hours” is fine for a law firm and useless for a cafe. A retail-aware SLA covers a few specific things.

Our standard managed IT services agreements for retail clients include all of the above explicitly. The sub-15-minute P1 response that applies during normal business hours extends to trading hours for retail, which is a real commitment backed by the 24/7 NOC in Tecoma rostering for it. Same-business-day on-site response in the Melbourne metro footprint covers Saturday trading. The reason this matters is that a retail outage cannot wait for Monday.

What to ask your POS vendor before signing

Most POS contracts are signed without the operational questions being asked. Here is the checklist we walk retail clients through before they commit.

• What happens if the store internet drops? Does the POS continue to take cash and card transactions, or does it stop entirely? Some POS systems handle offline mode well, others fail completely.
• What is the support phone number during Saturday trading? If it goes to voicemail, the answer is “no real support during trading”.
• What hardware do you provide vs what do I buy? Receipt printers, barcode scanners, cash drawers, customer-facing displays — every component should be specified.
• What integration does it have with my chosen EFTPOS provider? “Integrated” can mean anything from “tightly coupled” to “they send each other receipts via email”. Pin this down.
• What does the data export look like? Can you get your transaction history out in a usable format if you switch providers? Ask to see a sample export.
• What is the contract term and the exit process? Some POS contracts have 36-month lock-ins. Some have month-to-month flexibility. Know what you are signing.
• How do refunds, voids and returns work? Run through a sample return scenario step by step before signing. The friction in this workflow defines a lot of your daily operations.
• What reporting does it provide and how do I get it into Xero or MYOB? The accounting integration is the difference between an hour a week on reconciliation and a Sunday evening of pain.
• What is the failover terminal cost? Building this into the original contract is cheaper than adding it later.
• What happens if I want to add a second store? Multi-store pricing and feature differences should be understood up front.

None of these questions are aggressive. They are operationally honest. A POS vendor who cannot answer them clearly is one to be cautious about.

Realistic monthly IT cost for a 1-3 store independent retailer

The actual monthly IT cost for a Melbourne independent retailer with one to three stores breaks down roughly as follows. Numbers are typical for the Melbourne market in 2026.

The numbers vary based on retail format, transaction volume, staff size and POS choice. The pattern is consistent: a sensible IT stack for an independent Melbourne retailer is in the order of $1,000-$1,200 a month per store all-in. Trying to do it for less typically means cutting on the parts that matter (support response, backup, segregated networking) and paying for it later in downtime.

Where retail IT pays back on security

The Australian retail sector has been hit hard by cyber incidents in the past three years. Most of the headline cases have been larger chains, but the underlying patterns affect SMEs too. Three things matter for retail IT security at the SME scale.

Payment data exposure. Modern POS systems mostly handle this well — card data does not pass through the merchant’s systems in most flows, it goes directly to the payment processor. But back-office mishandling (storing card numbers in spreadsheets, processing manual key-entry on shared computers) creates exposure. The fix is policy and training, not technology.

Customer data. Loyalty programs, email marketing lists, customer order histories. This is personal information under the Australian Privacy Act and the obligations apply to retailers above the small business threshold and increasingly to those below it. A breach of a customer database is reportable and reputational.

Staff account compromise. Retail staff turn over and accounts get forgotten. A previous employee’s email account that still works is a phishing toehold. Offboarding discipline matters more in retail than in many other industries because of the staff churn.

Our retail clients are typically on the same security baseline as our other Melbourne SME clients — phishing-resistant MFA, conditional access, Defender for Endpoint, structured backup, documented offboarding. The retail-specific layer is the POS and EFTPOS configuration, which we treat as part of the cybersecurity baseline rather than a separate workstream.

How TechAssist supports Melbourne retail SMEs

Retail is one of our core service verticals. We have been supporting independent Melbourne retailers since 2014 and we have built our operational rhythm around the specific demands of retail IT — trading-hours support, fast response, segregated networking, integrated POS and EFTPOS, sensible monthly cost.

Our 13 Australian-employed engineers work across both our Tecoma headquarters and 575 Bourke Street CBD office, which is convenient for CBD retail clients in particular. The 24/7 NOC in Tecoma covers the trading-hours support need. Sub-15-minute P1 response applies to POS-down and EFTPOS-down incidents. Same-business-day on-site response for Melbourne metro store outages is standard.

The per-user fixed monthly pricing model works particularly well for retail because the user count is stable and the cost is predictable. The retail-specific cost components (in-store hardware, networking, POS integration) are quoted separately and transparently.

We support retailers across the inner Melbourne suburbs, with concentrations in Richmond, South Yarra, Hawthorn, Cremorne and the CBD itself. Where appropriate, we work alongside the retailer’s existing POS support relationship — we are not trying to replace Tyro or Lightspeed, we are trying to make sure the rest of the IT stack supports them properly.

Frequently Asked Questions

Can I run a small cafe POS without managed IT support?

You can, but the day the POS fails during a busy Saturday lunch you will wish you had not. For a single-site low-complexity cafe, the cheaper approach is a Square-based setup with good in-built support and a backup terminal. The middle ground — moderately complex POS with no managed support — is the worst of both worlds.

Do I need separate Wi-Fi networks for customers and POS?

Yes. This is a PCI DSS requirement, a security best practice, and easily achievable with modern managed access points. Anyone telling you a single flat network is fine is either uninformed or hoping you do not notice.

What is the right EFTPOS provider for an independent retailer?

Tyro, Smartpay and Square are the three serious options for independent Melbourne retailers. Tyro has the best POS integration story. Smartpay has competitive pricing. Square is the simplest to set up. The choice depends on volume, POS, and how much integration matters.

How quickly should my IT support respond on a Saturday?

For a P1 incident (POS down, EFTPOS down, store internet down), the same response time as a weekday — sub-15 minutes to a real engineer, with same-trading-day on-site if remote resolution is not possible. Anyone offering you “1 hour response during weekday business hours” is not retail-aware.

What is the typical lifespan of POS hardware?

Three to five years for the terminals themselves, depending on use. iPad-based POS systems last as long as the iPad is supported by iOS updates, which is usually five to six years from release. Refresh planning should be part of the original budgeting conversation.

Can I integrate my POS with Xero properly?

Most modern cloud POS systems have direct Xero integration that handles daily sales summaries, payment reconciliation, and stock movements. The integration is rarely perfect out of the box and usually needs a few hours of configuration to map account codes correctly. Done well, it removes most of the manual reconciliation work.

The summary for retailers

The Melbourne retail IT stack that actually works is built around four things: the right POS for your workflow, EFTPOS with documented failover, segregated networking that keeps customers off the payment network, and trading-hours-aware support. Get those four right and the rest of the IT environment looks after itself.

The mistakes that hurt retailers are predictable: choosing POS based on price not workflow, ignoring EFTPOS failover until it bites, flat customer Wi-Fi networks, and generic IT support agreements that do not actually cover Saturday trading. None of these mistakes are expensive to avoid if they are addressed during the original setup or refresh.

If you are a Melbourne retailer looking at a fitout, a multi-site expansion, or a refresh of a tired IT setup, have a chat with us. We will give you a straight assessment of the stack you have, the stack you should have, and what it takes to get from one to the other.

Multi-Site IT for Melbourne Businesses: Branches, Warehouses and Pop-Ups

When a Melbourne SME opens a second site — a warehouse in Dandenong, a pop-up in the CBD, a branch in Geelong — IT complexity compounds fast. By the fifth site you are running thirty different NBN contracts and nobody knows where the spare switch lives. This is the practical playbook for keeping multi-site IT under control.

Identity first, network second

The single most important shift in multi-site IT thinking over the past five years is moving from a network-centric model to an identity-centric one. In the old model, a “site” was defined by its network — the same VLAN, the same domain controller, the same file share. Anyone connecting to that network was on the corporate LAN and had access to corporate resources.

In the new model, a “site” is largely a power and connectivity convenience. The corporate resources live in Microsoft 365, Azure, or other cloud services. Access is granted based on user identity, device compliance and conditional access policies — not based on which Wi-Fi the user happens to be on. This is the practical version of zero trust thinking, and it changes the multi-site IT problem from “extend the corporate network to each location” to “make sure each user has reliable internet and a compliant device, regardless of where they are”.

If you are still thinking in the old model, multi-site IT looks expensive and complicated — SD-WAN, MPLS, site-to-site VPNs, domain controllers at each branch. If you have already made the identity-first shift, it looks much simpler — good internet at each site, a sensible Wi-Fi standard, identity through Microsoft Entra ID with strong conditional access, and you are most of the way there.

For a 25-person professional services firm opening a second office in Hawthorn, the right answer in 2026 is almost never to extend the corporate network. The right answer is to put a business-grade NBN connection in, deploy a managed Wi-Fi system, and let identity do the rest of the work. We have done this transition for several Melbourne clients and it consistently reduces the per-site IT cost by 40 to 60 percent compared to the old model.

When SD-WAN is overkill

SD-WAN gets pitched aggressively to mid-market businesses by carriers and resellers because it is a high-margin product. For most Melbourne SMEs with one to three sites, it is overkill. Here is when it pays back and when it does not.

SD-WAN is overkill when:

• You have one to three sites and the WAN traffic is mostly to cloud services (Microsoft 365, Azure, Salesforce, etc.) rather than between sites.
• Site-to-site latency is not business-critical (you are not running real-time voice over a private WAN or replicating large databases between sites).
• Your existing internet links are reliable enough — business-grade NBN with a 4G failover usually is.
• You can solve specific site-to-site needs with point solutions (a managed site-to-site VPN for the one application that needs it, rather than SD-WAN for everything).

SD-WAN starts to pay back when:

• You have four or more sites with active site-to-site traffic.
• You are running voice or video that needs QoS guarantees you cannot get from the public internet.
• You have a real need for application-aware routing — sending Microsoft 365 traffic out the local internet break while sending finance system traffic back to head office, automatically.
• You have specific compliance or contractual requirements for traffic segregation that point-solution VPNs cannot meet.

The Box Hill construction firm we onboarded last year had three sites and was being quoted $4,200 a month for SD-WAN by their incumbent telco. The actual requirement was a reliable internet connection at each site, identity-driven access to cloud apps, and a managed VPN between head office and the warehouse for a legacy job costing system that did not have a cloud version. We delivered that for $1,150 a month all-in across the three sites and the legacy system was migrated to a cloud equivalent six months later, eliminating the VPN entirely.

The hardware standard kit

One of the unglamorous secrets of multi-site IT is that the per-site hardware should be boringly consistent. Same firewall model, same switch model, same access point model, same configuration template, every site. This makes troubleshooting fast, sparing strategy obvious, and refresh cycles predictable. We use a standard kit per site type, scaled to size.

The point is not the exact equipment choice. The point is consistency. Pick a vendor stack (we tend to favour Fortinet for SMB and Cisco Meraki for businesses where the simpler cloud-managed model is more important than the deeper feature set), document the standard configuration, and apply it everywhere. When the access point dies at the Geelong branch, a same-model spare ships overnight and a remote engineer can reconfigure it from the template.

The on-site support response time problem

This is the issue that bites every Melbourne SME the moment they open a second site, and it is almost never addressed in the original IT planning.

Same-business-day on-site support is easy to deliver in the Melbourne metro area. It is harder when the second site is in Ballarat, Bendigo, or further afield. Most national MSPs solve this by paying break-fix technicians on demand at country rates, which is fine for occasional incidents but expensive and inconsistent for ongoing operations.

The honest answer is that on-site response time is a zone-based pricing question. Our Tecoma headquarters and CBD office at 575 Bourke Street let us deliver same-business-day on-site support across the Melbourne metro footprint, and we are transparent about response times for outer-metro and regional locations. For a multi-site business, the right conversation is “what is your business tolerance for a Ballarat user being offline for 24 hours versus 4 hours, and what is that worth paying for?”. Often the answer is that day-to-day support is delivered remotely (which works for 90% of issues), and on-site is reserved for hardware replacement and physical incidents, with a defined hours-to-on-site SLA per site zone.

For an outer-metro warehouse where downtime costs $4,000 an hour, paying for 4-hour on-site response is good economics. For a regional branch with five staff doing administrative work where downtime costs $200 an hour, next-business-day on-site is the rational choice.

This is the conversation that should happen during multi-site planning, not after the first regional outage. Zone-based response SLAs need to be in the agreement, with the cost difference made explicit. Anyone who quotes you “same SLA at every site” is either charging you for outer-metro response everywhere, or going to disappoint you when the Geelong site goes down.

The three governance rules that stop site sprawl

Multi-site IT becomes a mess not because of any single bad decision, but because of dozens of small decisions made independently at each site over years. Three governance rules, applied from day one of multi-site operations, prevent this.

Rule 1: one ISP relationship, not thirty

The single biggest contributor to multi-site IT chaos is each site having its own ISP contract, billed separately, with separate account managers and separate support paths. By site five, you have five different ISPs, five different bill cycles, five different sets of router credentials, and an IT manager who is on the phone to a different call centre every week.

The rule: every site’s internet connection runs through one ISP relationship, ideally aggregated by a single business-grade provider that can deliver to all your locations. The cost is usually within 5-10 percent of buying separate connections, and the operational saving is enormous. When a site goes down, there is one number to call and one technical contact who knows your business.

This rule applies even when the underlying technology has to vary — NBN at one site, Enterprise Ethernet at another, 4G at a pop-up. The aggregator handles the underlying carrier; you handle one relationship.

Rule 2: every site has a documented sponsor

Each site needs a named business owner who is responsible for the IT environment there. Not the IT manager — the local business sponsor. They are the person who notices when something is broken, who escalates when remote support is not responding fast enough, who is the local point of contact for hardware replacement deliveries, and who signs off on local IT changes.

Without a sponsor, sites accumulate undocumented changes — the warehouse manager who hard-wired the printer to bypass print server policy, the branch manager who plugged a personal Wi-Fi extender into the corporate switch, the pop-up coordinator who set the firewall admin password to “password123” so the marketing agency could plug in their demo equipment. Each of these is a small problem. Cumulatively they are how site IT environments rot.

The sponsor does not need to be technical. They need to be accountable. We require this as a condition of taking on multi-site management contracts, because without it the support quality degrades over time no matter what we do.

Rule 3: hard quarterly site audits

Every site gets a documented audit every quarter. Equipment inventory, configuration check against the standard template, network performance baseline, security posture review, sponsor interview about what is working and what is not. This costs about two engineer-hours per site per quarter and is the single most effective control against drift.

The audit produces a list of variances from standard. Most are trivial and get fixed during the visit. Some surface real changes — a site has grown headcount and needs more capacity, the local landlord has changed the building’s electrical layout, a department has started a workflow that needs a different printer configuration. The audit is where these get picked up and handled deliberately, rather than being discovered during an outage.

This is part of how our managed IT services model works for multi-site clients — a structured operational rhythm rather than reactive break-fix.

Backup, disaster recovery and the multi-site twist

Multi-site businesses have an interesting backup and disaster recovery profile because the sites can serve as recovery locations for each other in many scenarios. A flood at the head office is bad, but if the warehouse has internet, power, and a few desks, head office staff can work from there for a fortnight.

The implication is that multi-site DR planning should explicitly identify each site’s potential role in a recovery scenario for each other site. Most of the time this just means making sure that staff from each site have credentials that work everywhere, that there is enough physical capacity to absorb displaced staff, and that critical applications are cloud-hosted and accessible from anywhere.

The legacy file server at head office becomes a single point of failure that breaks this model. So does the on-premises application that only works on the head office LAN. Modern backup and DR design for multi-site SMEs explicitly identifies these single points of failure and either eliminates them (move to cloud) or designs around them (replicate to a second site, document the recovery process). We have rebuilt backup and DR for multi-site Melbourne businesses where the original design pre-dated the second site by years and was still treating head office as the only thing that mattered.

The cloud-first multi-site stack

For a Melbourne SME starting fresh, or for one going through a multi-site refresh, the cloud-first stack is now the default. It looks like this:

• Identity: Microsoft Entra ID with phishing-resistant MFA and Conditional Access policies. No on-premises domain controllers anywhere.
• Devices: All endpoints enrolled in Microsoft Intune. Compliance policies enforced as a precondition for accessing corporate resources. Wipe capability for lost devices.
• Productivity: Microsoft 365 with SharePoint and OneDrive as the canonical document storage. No file servers.
• Line of business: Cloud-hosted wherever possible. SaaS for accounting, CRM, ERP. Where on-premises is unavoidable, hosted in Azure or AWS, accessed via published web app or Azure Virtual Desktop.
• Networking per site: Business NBN or Enterprise Ethernet, managed firewall, managed Wi-Fi, 4G failover. No site-to-site VPN unless required for a specific application.
• Voice: Microsoft Teams Phone or a comparable cloud PBX, with handset standards documented per site type.
• Print: Cloud print or per-site MFD with direct printing from Intune-managed endpoints.

This stack is genuinely site-agnostic. Adding a new site means provisioning internet, deploying the standard hardware kit, and confirming identity policies apply. The business systems do not change. The “cutover” for a new site is hours, not weeks.

This is also where cloud services design matters more than network design. The cloud stack is the thing the business runs on. The network is the dial tone.

Common multi-site mistakes we see

A few patterns come up repeatedly in multi-site engagements. Worth listing.

Buying the wrong internet at the new site. Going for the cheapest available NBN connection at a warehouse where 30 staff need to use cloud services is false economy. The right line at the right speed costs maybe $80 a month more and removes a category of frustration.

Not standardising on switch and access point models. Different equipment at each site means different troubleshooting, different sparing, different configurations. Pick one. Live with it for the refresh cycle.

Letting each site choose its own SaaS. The Geelong branch using a different scheduling tool than head office because “it works better for our team” is fine until a customer interaction crosses sites and the tools cannot talk to each other. SaaS standards are a head-office decision.

Forgetting the physical security of the comms cupboard. A switch in an unlocked corner of the warehouse is a security incident waiting to happen. Lock the rack, log access.

Not having a sponsor at each site. Already covered, but the most common failure mode.

Underestimating the support cost of regional sites. Same-business-day on-site in regional Victoria is genuinely more expensive than in Hawthorn. Build it into the budget honestly rather than hoping nothing breaks.

How TechAssist supports multi-site clients

We support multi-site Melbourne businesses across construction, manufacturing, logistics, professional services and healthcare. The model is per-user fixed monthly pricing with zone-based on-site SLA tiers, which means a client knows exactly what each user costs to support regardless of which site they sit at, and the on-site response commitment matches the business value of each location.

Our 24/7 NOC in Tecoma handles monitoring and remote response across all sites for all clients. Same-business-day on-site is available across the Melbourne metro area from our two offices — Tecoma and 575 Bourke Street CBD. For outer-metro and regional Victorian sites, the SLA is set during onboarding based on the business risk profile and is honest about response time and cost.

Founded in 2014, we have 13 Australian-employed engineers and run an Essential Eight aligned, ISO 27001 capable operations practice. The reason that matters for multi-site clients is that consistency across sites is a security and audit problem as well as an operational one. The same standards, the same monitoring, the same documentation, every site, every time.

If you are about to open a second site, or are managing three sites that have grown organically into a mess, we have done this enough times to know where the traps are. Have a look at our MSP Melbourne page for the broader service description.

Frequently Asked Questions

Do we need SD-WAN for our second site?

Almost certainly not. SD-WAN is a real product with real use cases but for most Melbourne SMEs with two to three sites running mostly cloud applications, a managed business NBN at each site with 4G failover is the better answer. SD-WAN gets pitched hard because it is high margin for the seller.

Should we have a domain controller at each branch?

No. If you are still thinking in those terms, the broader architecture probably needs a refresh. Identity should live in Microsoft Entra ID, devices should be Intune-managed, and the branch becomes a power-and-internet location rather than a network outpost.

How do we handle internet failover at a regional site?

4G or 5G failover through the firewall is the standard answer. The throughput is lower than the primary line but enough to keep cloud applications running while the NBN fault is being resolved. Telstra and Optus business mobile data plans are the usual carriers; choose the one with better coverage at the specific site.

What happens when a site needs urgent hardware replacement?

If the equipment is standardised across sites, we usually have a spare ready to courier the same day for Melbourne metro and next business day for regional. For sites where downtime is critical, we recommend keeping a cold spare on-site, configured and ready to swap. The cost is the price of a backup access point or switch, and it is cheap insurance.

Can we use the same Wi-Fi network name across all sites?

Yes, and we recommend it. Same SSID, same identity-based authentication (typically WPA3-Enterprise via Entra ID), automatic roaming for staff who move between sites. This is part of the identity-first design — the user does not need to know they are at a different site.

How do we budget for multi-site IT?

The two main components are per-user costs (which scale with headcount and are largely site-agnostic in a cloud-first stack) and per-site costs (which cover internet, hardware, on-site support response). A reasonable rule of thumb is to budget the equivalent of one month’s per-user fee per site per quarter for ongoing site-specific costs, plus the standard kit cost for new site setup.

What to do next

If you are about to open a second site, the right conversation is identity-first design, business NBN with failover, standardised hardware kit, and a documented site sponsor. Skip the SD-WAN pitch unless you are at four-plus sites with real site-to-site traffic.

If you are already running three or more sites and feel like the wheels are coming off, start with a site audit. Inventory what is at each location, who the sponsor is, what the ISP relationship looks like, and where the variances from a sensible standard have crept in. The list itself will tell you the priority order for cleanup.

If you want a hand designing or untangling multi-site IT for a Melbourne business, get in touch. We will give you a frank assessment and a realistic plan.

Not-for-profit IT in Melbourne is different from commercial SME IT in four practical ways: discounted Microsoft 365 nonprofit licensing through TechSoup Australia, much higher user churn from volunteers, stricter donor-data privacy obligations under the APPs, and a board that expects IT spend justified against the mission and ACNC reporting.

That mix changes how we scope, price, and run support for charities and community organisations. If you treat an NFP like a 30-person law firm, you’ll over-engineer some things, miss compliance gaps elsewhere, and quietly burn through the small operating surplus the board has fought to protect.

This piece walks through what genuinely differs about not for profit it services melbourne organisations need, where the savings really are, where the risks hide, and what we’ve learned running IT for charities, community legal centres, peak bodies, and social enterprises across Greater Melbourne.

Why NFP IT is its own discipline

Most MSPs treat NFPs as small businesses with a tighter budget. That’s lazy and it costs you money. A 40-person charity in Carlton running donor records, a volunteer roster of 200, an ACNC Annual Information Statement, and a Salesforce NPSP instance has more compliance surface than a 40-person engineering firm. The complexity sits in different places, not in fewer places.

The four pressure points we see consistently:

• Licensing eligibility and renewals. Microsoft 365 Business Premium retails around $30 per user per month. For eligible NFPs through TechSoup Australia, equivalent licensing can drop to a small admin fee per year. Get the eligibility wrong, or let DGR status lapse, and the saving evaporates.
• Volunteer lifecycle. Paid staff might churn at 10 to 15 per cent per year. Volunteer access turns over far faster — short placements, event crews, board members rotating off. Identity hygiene is the single biggest control gap we find in NFP audits.
• Donor-data sensitivity. A donor list is regulated personal information under the Privacy Act and the Australian Privacy Principles. Fundraising compliance varies by state. Most boards don’t know where their donor database actually lives or who can export it.
• Mission-aligned spend. Every dollar spent on IT is a dollar not spent on programs. The board will ask. Your MSP needs to be able to defend the spend in plain English against program outcomes, not feature lists.

Microsoft 365 nonprofit licensing — what actually qualifies

This trips people up more than any other single thing. Microsoft’s nonprofit program in Australia runs through TechSoup Australia (the merged Connecting Up service). To qualify, your organisation generally needs:

• Endorsement as a charity by the ACNC, or eligibility as a deductible gift recipient (DGR) under the ATO, or recognition as an NFP under specific categories Microsoft accepts
• A mission that meets Microsoft’s anti-discrimination policy
• Re-validation roughly every two years

Common stumbles: a social enterprise structured as a company limited by guarantee but without ACNC endorsement, an auxiliary or fundraising entity that doesn’t itself hold DGR status, or a hospital foundation that assumes the parent entity’s status carries across. None of those automatically qualify.

When eligibility is confirmed, the savings are significant. Business Premium grants for up to ten users plus discounted licensing beyond that, free Exchange Online Plan 1 grants, and discounted Power Platform and Azure credits. For a 40-staff charity, the annual Microsoft saving versus commercial pricing typically runs $12,000 to $18,000. That’s a part-time program worker. It’s worth getting right.

We handle the TechSoup validation, link the tenant to the nonprofit program, set up the grants correctly, and diarise the re-validation so it doesn’t lapse mid-financial-year. More on the platform piece at our Microsoft 365 page.

TechSoup Australia beyond Microsoft

Worth naming because most NFP managers under-use it. TechSoup Australia (connectingup.org) brokers donated and discounted software, hardware, and services for eligible NFPs. Beyond Microsoft, the catalogue covers Adobe, Autodesk, Bitdefender, Cisco Webex, Tableau, Zoom, and a long tail of sector-specific tools.

Hardware is more limited but worth checking — refurbished laptops and desktops are sometimes available at sharp prices for small charities. Where new hardware is needed, we’ll often spec mid-range business-grade machines and budget for a 4-to-5 year refresh cycle rather than the 3-year cycle commercial clients run, because the cashflow profile suits NFPs better and the warranty exposure is manageable.

The governance burden — what your board actually needs

Commercial directors care about uptime and cost. NFP boards care about uptime, cost, mission alignment, risk, and the Annual Information Statement. The reporting cadence is different.

A useful NFP IT governance pack, delivered quarterly to the board, contains:

• Operational summary — tickets resolved, P1 incidents, average response, uptime
• Risk register update — top three IT risks with current mitigations and residual rating
• Privacy and donor-data control status — who has access to the CRM, MFA coverage, recent access reviews
• Spend against budget and mission alignment — what was spent and how it served the program
• Compliance calendar — ACNC due dates, cyber insurance renewals, software re-validations

This is not heavy. Done properly it’s two pages plus appendices. But it’s the artefact that lets the board sign off the IT spend without flinching, and it’s the artefact that auditors (internal and external) lean on at year end. If your current MSP isn’t producing something like this, ask why.

Donor data and the Privacy Act

If your NFP has annual turnover over $3 million, the Privacy Act applies in full and the Australian Privacy Principles are mandatory. Below that threshold, you may still be caught — for example, if you provide health services, hold tax file numbers, or have opted into the Act voluntarily. Many DGR-status charities are caught regardless of turnover because of the type of information they hold.

Practical implications for IT:

• Donor records must have access controls and an access log. A shared “fundraising” mailbox with the password on a sticky note is not defensible.
• Exports of donor lists need to be auditable. Power Automate alerts on bulk exports from your CRM are simple and cheap to set up.
• The Notifiable Data Breaches scheme applies. You need an actual incident response plan, not just a vague “we’ll call the MSP” — including who notifies the OAIC and on what timeframe.
• Fundraising agencies and external suppliers handling donor data need contractual privacy clauses and an annual review.

This sits alongside broader security posture work — MFA everywhere, conditional access, endpoint protection, mailbox audit logging. The full picture is on our cybersecurity services page.

Volunteer access — the silent risk

A community legal centre in Footscray we onboarded had 47 active Microsoft 365 accounts on a paid-staff headcount of 22. The rest were volunteers and former volunteers who’d never been offboarded. Three accounts hadn’t logged in for over two years but still had access to client matter folders. None had MFA enrolled. The original IT contact had left 18 months earlier and the handover was a single shared spreadsheet.

We cleaned it up over a fortnight — proper joiner-mover-leaver process, a volunteer access tier with restricted permissions, time-boxed accounts that auto-disable after 90 days of inactivity, and MFA enforced via conditional access. Annual cost impact: minimal once the cleanup was done. Risk reduction: enormous.

The pattern repeats. NFPs need a different identity model — one that assumes high volunteer churn and treats short-term access as the default, not the exception. Group memberships driven by HR data, not manually maintained. Self-service password resets so the operations manager isn’t fielding calls on a Saturday.

Pricing models that actually work for NFPs

The fully managed, per-user fixed monthly model still works for NFPs — it just needs to be priced honestly against the user mix. We bill paid staff at the standard per-user rate and volunteer accounts at a reduced rate that reflects the lower support load and lighter device footprint.

Some MSPs offer “pro bono” arrangements. Treat them carefully. Pro bono can mean genuinely donated time from a community-minded MSP, or it can mean a junior tech with no backup and no SLA. Ask the questions: who covers if the named engineer is on leave, what’s the response time, what happens at midnight when ransomware lands. If those answers are vague, the arrangement will fail when you most need it.

Our model: 13 Australian-based engineers, sub-15-minute P1 response, 24/7 NOC at Tecoma, per-user fixed monthly with NFP rates for eligible organisations. Predictable, accountable, defensible to the board.

NFP-specific platforms — Salesforce NPSP, Blackbaud, iMIS, Donortec, ThankQ

The CRM choice in the NFP sector is more fragmented than commercial. We see and support:

• Salesforce Nonprofit Cloud / NPSP — powerful, scales well, free for first 10 users via Salesforce.org, but real implementation costs and admin overhead. Best for organisations $5m+ turnover or with complex program data.
• Blackbaud Raiser’s Edge NXT — donor-focused, strong for traditional fundraising charities, weaker for case-management workflows.
• iMIS — common for peak bodies and member associations, integrates membership and events.
• Donortec / ThankQ — Australian-grown, strong fit for mid-sized fundraising charities, sensible licensing.
• Microsoft Dynamics 365 (with nonprofit accelerator) — viable if you’re already deep into Microsoft and want tighter integration.

Where we add value isn’t reimplementing the CRM — there are specialist NFP CRM partners who do that well. Our role is the Microsoft 365 integration layer: single sign-on so volunteers don’t have ten passwords, Power Automate workflows that move data between the CRM and finance system, mailbox routing for donor communications, document storage that respects the privacy controls in the CRM. That’s where most of the day-to-day friction lives.

NFP IT vs commercial SME IT — the practical differences

A worked scenario — Carlton health-promotion charity

A health-promotion charity in Carlton came to us with 28 paid staff, around 60 active volunteers, and a Salesforce NPSP instance about three years old. They were paying full retail for Microsoft 365 because their previous IT provider had never enrolled them in the nonprofit program. MFA was on for finance staff only. The board was asking for cyber insurance and the underwriter had sent back a 47-question security questionnaire that no one knew how to answer.

What we did over the first 90 days:

• Validated ACNC and DGR status, completed TechSoup registration, migrated their Microsoft 365 tenant to the nonprofit grant tier. Annual saving: $11,800.
• Built a tiered identity model — paid staff, board, standing volunteers, event volunteers — with conditional access policies for each. MFA enforced across the tenant.
• Cleaned up 14 dormant accounts, recovered 9 unused Salesforce licences.
• Implemented a joiner-mover-leaver workflow tied to their HR system so volunteer access auto-expires.
• Wrote the responses to the cyber insurance questionnaire and produced an evidence pack. Premium came in 30 per cent lower than the original quote.
• Set up the quarterly board IT report template, walked the operations manager through delivering it.

Net result: annual IT spend dropped by roughly $7,500 versus their previous arrangement (after our fees), security posture moved from poor to defensible, board confidence in IT measurably improved. Nothing exotic — just NFP-aware execution.

Where to start if you’re reviewing your IT now

If you’re an NFP exec or operations manager and any of the above is unfamiliar, three practical first steps:

1. Confirm your Microsoft 365 licensing tier. Log into the admin centre, look at the subscription page, and check whether you’re on commercial or nonprofit SKUs. If commercial, you’re probably overpaying.
2. Audit your active user accounts against your current paid staff list and current volunteer roster. Anyone in the directory who isn’t on either list is a risk and a cost.
3. Check who can export your donor database. If the answer is “anyone in fundraising” or you’re not sure, that’s the first control to tighten.

None of those need an MSP to do. They need 90 minutes and a willingness to look. What an MSP brings is the execution capacity to fix what you find, and the ongoing discipline to keep it fixed.

For broader context on how the day-to-day support model works, our managed IT services overview covers the operational side, and the IT support page covers helpdesk specifics.

FAQ

Do you offer NFP discounts?

Yes. Eligible NFPs — ACNC-endorsed charities, DGR-status organisations, and recognised community organisations — receive reduced per-user rates on our managed plans. Volunteer accounts are billed at a further reduced rate that reflects the lighter support profile. We’ll quote transparently against your user mix and you can defend the spend to the board line by line.

How do we qualify for Microsoft 365 nonprofit licensing?

You’ll need ACNC charity endorsement, DGR status, or recognition as an NFP under one of Microsoft’s accepted categories, plus a mission that meets their anti-discrimination policy. Validation runs through TechSoup Australia and is typically required every two years. We handle the registration, tenant configuration, and re-validation reminders so it doesn’t lapse.

What about ACNC reporting requirements for IT spend?

The ACNC Annual Information Statement doesn’t break IT out as a separate line, but your audited financials will, and your board expects justification. We produce a quarterly IT governance report covering spend against budget, risk register status, privacy controls, and mission alignment. It’s two pages plus appendices and it’s designed to drop straight into board papers.

Can volunteers safely use Microsoft 365 without compromising donor data?

Yes, with the right configuration. The model we use is a tiered identity setup — volunteers get accounts with restricted permissions, no access to donor databases or finance, conditional access policies that enforce MFA, and time-boxed access that auto-disables after defined periods. Done properly, volunteers can collaborate effectively without ever touching regulated data.

What if we already have an MSP but suspect they’re not NFP-aware?

Ask three questions. One, are we on Microsoft 365 nonprofit SKUs and when does the validation renew. Two, can you show me the last access review for our CRM. Three, can you produce a one-page IT report I can take to the board. If any of those land badly, it’s worth a second conversation. Reach out via our contact page or call 1300 028 324 — happy to talk through it without pressure.

NFP IT done well is quiet, predictable, and defensible at the board table. It’s not magic. It’s just attention to the things that genuinely differ — licensing, identity, donor data, governance — and the discipline to keep them right year after year. If you’d like a sanity check on where your organisation sits, get in touch.

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

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

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

Why a pre-renewal audit matters

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

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

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

Before you start: what to gather

You’ll need:

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

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

The 10-point audit checklist

1. Pull real ticket data and check the numbers

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

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

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

2. Test SLA compliance against the contract

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

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

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

3. Audit the asset register against your invoices

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

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

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

4. Check security posture against current standards

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

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

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

5. Audit licence usage versus licence cost

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

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

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

6. Review documentation completeness

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

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

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

7. Check after-hours response performance

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

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

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

8. Evaluate strategic input (the vCIO function)

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

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

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

9. Review project work scope creep

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

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

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

10. Evaluate cultural fit and communication quality

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

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

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

A concrete example: how this plays out

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

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

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

What to do with the findings

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

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

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

How TechAssist would look under this audit

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

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

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

Frequently asked questions

How long does an MSP audit take?

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

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

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

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

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

How often should I audit my MSP?

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

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

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

Per-user fixed monthly suits most Australian SMEs with 15-150 staff and standard office setups. Per-device works for shops heavy on servers, kiosks or shared workstations. Hourly retainers fit businesses with internal IT who only need overflow help. Hybrid models suit complex environments mixing cloud, on-prem and field staff.

If you’ve put three Melbourne MSPs in front of your finance team, you’ve probably had three completely different quote structures land in your inbox. One charges $135 per user per month. Another quotes $89 per device. A third wants a $4,500 monthly retainer plus T&M on anything outside scope. They’re all “managed IT” — but the way they bill changes everything about how the relationship actually plays out.

This post is about managed it pricing models as a structural choice, not the totals. If you want the dollar ranges Melbourne MSPs typically charge in 2026, read our Melbourne managed IT pricing breakdown first. What follows is about which billing mechanism actually suits your business, and why the wrong structure leaves you either overpaying or fighting your MSP every month over what’s in-scope.

Why the billing model matters more than the headline price

Two MSPs can quote the same monthly total and deliver wildly different experiences. The billing model dictates three things that compound over the life of the contract: what counts as “included,” how the MSP’s incentives line up with yours, and how predictable your IT line item is when you grow, shrink or change.

I’ve seen a 40-staff accounting firm in Hawthorn switch from per-device to per-user and watch their monthly bill drop 18% — not because the new provider was cheaper, but because they had a lot of part-time staff sharing workstations. The per-device model was counting hardware their team barely used. Conversely, a manufacturing client in Dandenong South tried to move from per-device to per-user and the numbers blew out — they had two PLCs, six shop-floor terminals and a server room per staff member, and per-user pricing assumed a desk-and-laptop world that didn’t exist in their business.

The model has to match the shape of your environment. Here’s how each one actually works.

Model 1: Per-user fixed monthly

You pay a flat fee per active staff member each month. That fee covers everything the MSP defines as standard support — typically one or two devices per user, mobile device management, email, identity, common SaaS apps, security stack, helpdesk, after-hours coverage and patching.

How it actually works

The MSP audits your headcount monthly. New starter joins on the 14th? You’re billed pro-rata. Someone leaves? Their licence is decommissioned and they come off the next invoice. The price is fixed per person regardless of how many tickets they raise, which is the whole point.

Most Australian per-user agreements sit between $110 and $185 per user per month in 2026, depending on stack inclusions and SLA. The number on the proposal isn’t really negotiable — what you negotiate is what’s inside the bundle.

What’s typically included

• Helpdesk during business hours and after-hours P1 response
• Endpoint security (EDR), patching, monitoring
• Microsoft 365 or Google Workspace administration
• One or two endpoints per user (laptop + phone, or desktop + laptop)
• Identity and access management
• Backup of cloud data (sometimes excluded — check the SOW)
• Onboarding and offboarding of staff

Who it suits

Knowledge-work businesses with 15-150 staff, mostly cloud-based, fairly uniform setups. Professional services, agencies, advisory firms, allied health, NFPs, small wholesalers. If your people each have a laptop and a phone and they live in Microsoft 365 or Google Workspace, per-user is almost always the cleanest fit.

Where it fails

It falls apart when your headcount understates your IT footprint. A 25-staff manufacturer with 80 devices on the floor will get murdered on per-user pricing — or, more accurately, the MSP will quietly add a “per-device surcharge” for non-user devices, which makes the whole thing less transparent than per-device would have been. Same problem for retail with POS, hospitality with kiosks, or logistics with handheld scanners.

TechAssist runs per-user fixed monthly as our standard model. We chose it because it makes our incentives line up with the client’s — we get the same revenue whether your staff raise three tickets a month or thirty, so we’re motivated to fix root causes, not to keep the lights flickering. It also means finance teams know exactly what next month looks like.

Model 2: Per-device

You pay a fee per managed endpoint — server, workstation, laptop, sometimes mobile. Each device class usually has its own rate. Servers might be $250-$450/month, workstations $55-$95, laptops similar, mobiles $15-$25.

How it actually works

The MSP runs discovery, builds an asset register, agrees the per-device rates with you and then invoices monthly based on what’s under management. You add a device, it gets onboarded and added to the bill. You retire a device, it comes off. Users are basically invisible to the billing — the MSP doesn’t care if one person uses ten laptops or ten people share one.

What’s typically included

• Monitoring and patching on each managed device
• Endpoint security on each device
• Backup and recovery (usually charged separately for servers)
• Helpdesk for issues on managed devices
• Hardware lifecycle management

What’s usually NOT included on a strict per-device model: user support that isn’t device-specific (password resets, M365 admin, identity issues), project work, and after-hours unless explicitly bolted on.

Who it suits

Asset-heavy businesses where devices outnumber users — manufacturing, warehousing, retail chains, hospitality groups, healthcare with diagnostic kit, logistics. Also a reasonable fit for small businesses with very few staff but a couple of servers, where per-user feels like you’re paying for nothing.

Where it fails

Two places. First, user-centric problems don’t fit cleanly — a staff member who can’t log in isn’t a device problem, but they’ll still ring the helpdesk. Second, the asset register becomes a fight. Is the meeting room TV a managed device? The receptionist’s iPad? The MD’s home laptop? Per-device billing pushes both sides to argue about scope every time something new appears.

Model 3: Hourly retainer or block hours

You pre-purchase a block of engineering hours each month — say 20, 40 or 80 hours at a negotiated rate — and burn them down on whatever you need. Unused hours sometimes roll over (rarely past 30 days), sometimes expire.

How it actually works

The MSP quotes a blended hourly rate, usually $165-$235/hour in Melbourne in 2026 depending on seniority and after-hours loading. You commit to a minimum monthly spend. Tickets are logged with time, you get a monthly report showing burn-down, and you top up when the block runs low.

What’s typically included

Nothing is “included” in the per-user/per-device sense. You pay for what you use. Monitoring and security tooling are usually billed separately as monthly licence costs, then engineering time is drawn from your hour block.

Who it suits

Businesses with capable internal IT who only need overflow, escalation or specialist help. Government departments with their own IT but needing M365 specialist hours. Larger SMEs with a one-person internal IT lead who needs backup. Also fits businesses doing a project-heavy phase — migration, fit-out of a new office — where work is bursty rather than steady. This is the model most often seen in our co-managed IT engagements, where there’s an internal IT lead and we plug in capacity.

Where it fails

It penalises proactive work. If every hour the MSP spends gets billed, they have a perverse incentive to be reactive — and you have a perverse incentive to avoid calling them, which means small problems become big ones. It’s also brutal during incidents: a six-hour outage can chew through a month’s block in one afternoon. And it makes budgeting harder, not easier, because your spend tracks your bad weeks.

Model 4: Hybrid

A fixed per-user or per-device base for “everything routine” plus an hourly rate for project work, after-hours emergencies, or anything outside a defined scope. Probably the most common model in Australia in 2026, even when MSPs market themselves as pure per-user or pure per-device.

How it actually works

The contract defines an inclusion list — the routine stuff covered by the fixed fee — and an exclusion list, which is everything billable at T&M. The cleaner the inclusion list, the more predictable your bill. The fuzzier it is, the more arguments you’ll have.

What’s typically included in the fixed portion

• Helpdesk, monitoring, patching, security stack — same as per-user
• Routine admin (user adds/removes, password resets, standard config changes)
• Standard reporting and reviews

And billed hourly on top:

• Projects (migrations, new site fit-outs, hardware refreshes)
• After-hours work outside SLA
• Anything the SOW classifies as out-of-scope

Who it suits

Most growing SMEs eventually end up here, because pure per-user can’t absorb major project work without inflating the per-seat rate, and pure hourly is too volatile. A 60-staff law firm in South Yarra running a fixed per-user fee for day-to-day but commissioning us hourly for a Practice Evolve migration is a textbook hybrid scenario.

Where it fails

Scope creep on both sides. If the inclusion list isn’t tight, the MSP starts pushing routine work into project hours. If it’s too tight, the client feels nickel-and-dimed. The hybrid model is only as good as the SOW that defines it — read ours under our pricing and SLA terms before you sign anything from anyone.

The four models, side by side

The honest version: why TechAssist runs per-user fixed

We’ve used three of these four models across the business since we were founded in 2014. We settled on per-user fixed monthly as our standard because of incentive alignment more than anything else. With 13 Australian-based engineers and a 24/7 NOC in Tecoma, we carry the cost of being available whether or not your staff need us in any given month. Per-user fixed means we’re paid the same whether your team raises five tickets or fifty. So we spend our energy fixing root causes, building reliable platforms and reducing the ticket rate over time — because that’s how we stay profitable.

The other reason: it’s the model SMEs find easiest to justify to the board. “We pay $X per head per month, full stop” is a clean line item. It scales when you hire. It shrinks when you don’t. And it doesn’t generate surprise invoices that have your CFO ringing us in week three of the month.

It’s not the right model for everyone. We’ve recommended per-device or hybrid arrangements to manufacturing prospects where per-user would have understated their footprint and resulted in either a padded per-seat number or constant out-of-scope billing. The right billing model is the one that matches your environment honestly, and we’d rather refer that work than misprice it.

How to pressure-test an MSP’s quote

Before you sign anything, ask these questions in writing:

1. What’s the exact inclusion list? Not the brochure version — the SOW version.
2. What triggers an out-of-scope billable hour? Give me three examples.
3. What’s the after-hours and weekend loading on hourly rates?
4. How is a “user” or “device” defined? When does a contractor count? A shared workstation?
5. What happens to the bill if headcount drops 20% in a quarter?
6. What’s the SLA for P1, P2 and P3? What’s the credit if you miss it? (Ours sits under 15 minutes for P1 — see our SLA detail.)
7. What’s the minimum contract term, and what’s the exit clause?

An MSP that answers all of these clearly is operating an honest pricing model. One that gets vague on any of them is going to be vague on the invoice too.

Matching the model to your business

A few quick patterns we see in Melbourne SMEs:

• Professional services (legal, accounting, consulting), 20-100 staff: per-user, almost always.
• Allied health, NFP, education admin: per-user, with care taken on shared devices in clinics or classrooms.
• Manufacturing and warehousing: per-device or hybrid, with explicit server-class pricing.
• Retail and hospitality groups: per-device for POS-heavy sites, per-user for head office staff.
• Construction and trades with field staff: per-user works if everyone has a phone and laptop; hybrid if you’ve got site-based servers or specialty kit.
• Businesses with internal IT (1-3 person team): hourly block or co-managed arrangement, with the MSP handling escalation, security and after-hours. Worth reading our breakdown of co-managed IT pricing for Australian SMEs if this is you.

If you’re somewhere between two patterns — which is most growing businesses — hybrid is usually the right answer, with a tight SOW.

FAQ

Is per-user pricing always more expensive than per-device?

No. For knowledge-work businesses with one or two devices per user, per-user is usually cheaper because the MSP is sizing the contract to your actual support load — humans raise tickets, devices generally don’t. For asset-heavy businesses it can be more expensive, because you’ll either pay a higher per-seat rate or end up on a hidden hybrid. The right comparison is total cost over 12 months, not the headline rate.

Can I negotiate the per-user rate down?

A bit, but not much. The real negotiation is what’s inside the bundle. Push for explicit inclusions on after-hours, backup, M365 administration, security stack and onboarding/offboarding. Those clauses are worth more than $5-10 off the per-user fee.

What about pure break-fix (call us when something breaks)?

We don’t offer it and most credible MSPs won’t either. The economics don’t work for either side — you pay too much per incident, the MSP can’t invest in proactive monitoring, and security cover is patchy. If your IT spend is genuinely that small, you probably need a one-person IT contractor on retainer, not a full MSP.

If I have 200 staff but only 50 use computers regularly, do I pay for all 200?

You pay for active users — people who have an identity, a mailbox or a managed device. Shop-floor workers without a login don’t count. We define this in the SOW so there’s no ambiguity at month-end.

How often can I change billing models with my MSP?

Usually at contract renewal — most agreements run 12 or 24 months. Mid-term changes happen but require a fresh SOW. If your environment has changed materially (acquisition, new site, restructure), most MSPs will reopen the model rather than force you through to renewal on the wrong terms.

Where to next

If you want the dollar ranges to go with this structural picture, read our Melbourne managed IT pricing post for 2026. If you’ve got internal IT and you’re weighing co-managed options, the co-managed pricing breakdown is the right next read.

If you’d rather just have someone look at your environment and tell you which model actually fits, our managed IT team runs a 30-minute scoping call at no cost — we’ll be honest if per-user isn’t right for you. Get in touch or call us on 1300 028 324.

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

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

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

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

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

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

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

The 30-day playbook at a glance

That’s the skeleton. Now the meat.

Week 1: Discovery and scoping

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

The environment audit

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

The deliverable from the audit is a written inventory covering:

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

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

Credentials capture

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

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

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

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

Documentation transfer

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

Things we look for that are nearly always missing:

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

RACI matrix sign-off

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

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

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

Week 2: Tooling rollout

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

RMM deployment

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

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

EDR rollout

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

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

Backup monitoring

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

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

NOC enrolment

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

Week 3: Runbook writing

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

BAU runbooks

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

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

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

After-hours playbooks

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

Three things the after-hours playbook must include:

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

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

Escalation tree

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

Week 4: Shakedown and the first QBR

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

Live ticket testing

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

Failover drill

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

QBR preparation

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

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

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

The 90-day plan

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

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

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

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

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

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

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

What good MSPs do differently in onboarding

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

They want to talk to your existing IT person before signing

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

They have a written onboarding methodology

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

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

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

Their engineers answer the phone

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

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

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

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

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

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

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

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

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

What this should cost

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

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

Where to from here

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

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

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

FAQs

How long should co-managed IT onboarding actually take?

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

Do we need to replace our existing tools during onboarding?

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

What if our internal IT person resists the engagement?

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

Will we get the same engineer every time?

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

What happens if onboarding falls behind schedule?

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

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

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

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

What each model actually means in practice

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

Internal IT

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

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

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

Fully managed IT

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

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

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

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

Co-managed IT

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

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

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

Who each model actually suits

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

Fully managed: the sweet spot

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

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

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

Co-managed: the sweet spot

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

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

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

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

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

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

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

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

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

What each model costs (real AUD ranges)

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

Internal IT cost

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

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

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

Fully managed IT cost

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

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

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

Co-managed IT cost

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

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

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

The comparison matrix

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

What breaks under stress in each model

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

Internal IT failure modes

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

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

Fully managed IT failure modes

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

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

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

Co-managed IT failure modes

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

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

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

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

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

Three honest options:

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

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

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

How to actually decide

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

Do you have someone internal already?

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

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

What’s your growth trajectory?

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

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

How much does after-hours matter?

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

What’s the compliance picture?

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

FAQ

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

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

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

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

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

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

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

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

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

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

The honest answer

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

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

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