UniFi vs Cisco for SME Networks

For most Australian businesses between 10 and 200 staff, UniFi is the right answer and Cisco is over-specified. That is not a statement about quality. It is a statement about what the two vendors charge you in ongoing licence obligation, in required skill, and in what happens when a device dies on a Tuesday afternoon. We deploy both, and the deciding factor is almost never throughput.

The comparison below is between Ubiquiti’s UniFi platform and Cisco’s two relevant lines: cloud-managed Cisco Meraki, and on-premises Cisco Catalyst. They are three different operating models, not two.

The three platforms you are actually choosing between

UniFi is Ubiquiti’s single ecosystem covering networking, cameras, door access, voice and more, split into applications called UniFi Network, UniFi Protect, UniFi Access, UniFi Talk and UniFi Connect. The network gear runs UniFi OS on a console: a Cloud Gateway such as the UCG-Ultra, UCG-Max or UCG-Fiber, a rack-mounted Dream Machine Pro, Special Edition or Pro Max, or a dedicated Cloud Key. Access points run in tiers from U7 Lite up through U7 Pro, U7 Pro Max and U7 Pro XG, with the older Wi-Fi 6 U6 line still sold as the value option. Switches run Standard, Professional, Pro Max, Pro XG, Enterprise and Aggregation lines.

Cisco Meraki is cloud-managed. MX security appliances, MS switches and MR or CW access points all report to a single cloud dashboard, and configuration lives there rather than on the device. Cisco has been converging the two brands, so Catalyst switch hardware such as the C9300-M and C9200L-M can now be managed from the Meraki dashboard as well.

Cisco Catalyst on IOS-XE is the traditional on-premises line, managed by CLI or by Catalyst Center (the platform formerly called DNA Center). This is enterprise campus equipment. In an SME it appears when someone has inherited it, or when a specific requirement drags it in.

Feature parity is closer than the price gap suggests, at SME scale

The features an SME network actually uses are VLAN segmentation, inter-VLAN routing, PoE for phones, cameras and access points, decent wireless roaming, guest isolation, a firewall, a site-to-site VPN, and remote access. Every one of those exists on all three platforms.

UniFi does VLANs, firewall zones and rules, traffic and application filtering, WPA3, 802.1X with dynamic VLAN assignment from a RADIUS server, and a built-in IDS/IPS engine at no additional cost. It does site-to-site VPN between UniFi gateways automatically through Site Magic in UniFi Site Manager. For a single-site business with a few dozen staff, a couple of dozen access points and a handful of switches, there is no capability gap that a Cisco product closes.

Where the gap opens is not in the feature list. It is in everything around the feature list.

Licensing: free is a real difference, but read the whole model

UniFi Network is licence-free. Ubiquiti’s own documentation describes UniFi as offering scalable, licence-free cloud management, and that covers both the Network application and remote multi-site management through UniFi Site Manager. You buy hardware. The controller software and the cloud portal cost nothing ongoing. Site Magic, the SD-WAN feature that automates tunnels between UniFi gateways, sits inside Site Manager.

There are paid subscriptions in the UniFi world, and you should know their names. UniFi CyberSecure is a subscription that layers commercial threat intelligence feeds, including Proofpoint ET Pro signatures, on top of the free built-in IDS/IPS. There is a higher tier that requires specific enterprise gateway hardware. Ubiquiti also sells a paid professional phone support subscription. None of these are required for the network to keep working.

Meraki works the opposite way. The licence is not optional and it is not a support contract. It is the right to operate the hardware. Meraki uses two models: co-termination, where every licence in an organisation shares one common expiry date calculated across all devices, and Per-Device Licensing, where licences attach to serial numbers. You cannot mix the two models in one organisation.

The consequence people miss is what happens at expiry. Meraki’s documentation is explicit: there is a 30-day grace period once the co-termination date passes or once your device count exceeds your licence count, and after that grace period the organisation is shut down. The devices stop being operational. This is not a degraded mode, it is off. A business whose renewal falls through a gap in an accounts payable process loses its network.

Two more Meraki licensing details worth writing into a budget:

• Licence editions must be uniform across the organisation. MX appliances run Enterprise, Advanced Security or Secure SD-WAN Plus, and you cannot mix editions in a single organisation. If one site needs Advanced Security, either everyone gets it or you split into separate organisations and manage them separately.
• Licences do not move between hardware models. An MX64 licence does not cover an MX65. Replacing a device with a newer model is a licensing event.

Cisco also changed its Meraki refund position on 26 October 2025, retiring the previous licence-only return exception and aligning Meraki with Cisco’s standard all-sales-are-final policy. Order carefully.

Catalyst on-premises uses a third model again: a perpetual Network Essentials or Network Advantage licence that grants the on-box features and never expires, plus a separate term subscription (the Cisco Networking Subscription, previously branded Cisco DNA Essentials and Advantage) for Catalyst Center automation and assurance. Compliance is reported through Smart Licensing Using Policy. The perpetual layer means a Catalyst switch keeps switching if you stop paying. That is a genuine architectural difference from Meraki and it matters if you are nervous about vendor dependency.

We are not publishing prices here. The models above are what actually drive the total, and the model is knowable in advance where the price is not.

Support and RMA in Australia is where the argument usually gets decided

This is the section most comparisons skip, and almost all of it online is written for American buyers. Australia works differently, and the difference is legal before it is logistical.

The Australian Consumer Law governs this, not the warranty card

Start here, because this is the part that binds. Under the Australian Consumer Law, consumer guarantees are automatic rights owed by the business that sold you the goods. The ACCC states plainly that these rights cannot be taken away by anything a business says or does, that a manufacturer warranty is an extra promise sitting on top of them rather than a replacement for them, and that a business must not tell you to go to the manufacturer for a remedy.

Business purchases are covered far more often than buyers assume. The ACCC’s published test is that a product bought for business use is covered if it meets at least one of three conditions: it costs less than $100,000 including GST, it is a product commonly bought for personal, domestic or household use, or it is a vehicle or trailer used mainly to transport goods on public roads. A gateway, a switch stack and a dozen access points for a 60-person office sits comfortably under the threshold, so the guarantees apply.

Three exclusions matter, and they apply even under the threshold. Goods are not covered when they are bought for resupply, for use or transformation in production or manufacturing, or to repair or treat other goods. The first one catches your IT provider rather than you: hardware an MSP buys to on-sell is acquired for resupply, so the MSP’s own purchase falls outside the guarantees while your purchase from the MSP does not.

The remedy depends on how bad the failure is, and this is where most people get it wrong. For a major failure, which includes a product that cannot be used for its normal purpose and cannot easily be fixed within a reasonable time, you choose between a refund and a replacement, and the ACCC states a refund must be the full amount paid with no deduction for the use you have had. For a minor failure the supplier must at least repair it free, and if it will not or cannot do so within a reasonable time you can have it fixed elsewhere at the supplier’s cost, or take a refund or replacement instead. Where the fault is the manufacturer’s, the manufacturer must reimburse the supplier. That is the supplier’s problem, not yours.

One practical point before you post anything back. If the product does have a fault, the supplier must reimburse your reasonable return costs. If no fault is found, the supplier can charge you collection and inspection costs, but only if it gave you a reasonable estimate of those costs before collecting the product.

Ubiquiti: the Australian distributor handles the replacement

Ubiquiti’s published limited warranty runs one year for products bought through an authorised distributor or reseller, and two years for products bought direct from an official Ubiquiti webstore. Read the one-year term carefully: it runs from the date the product was shipped to the distributor, not from the date you bought it, so a unit that sat in a warehouse for four months arrives with eight months left. The sole remedy under the manufacturer warranty is replacement with a new or refurbished unit at Ubiquiti’s discretion, and removal and reinstallation labour is excluded.

Ubiquiti’s warranty page also sets out conditions for RMAs raised directly with Ubiquiti from outside the United States: your own shipping account, a commercial invoice declaring “return for repair” and “no commercial value”, and duties and customs at your cost. Those terms describe a direct-to-Ubiquiti RMA, they are expressly qualified by the words “unless otherwise prohibited by applicable law”, and the same page states that the warranty terms do not exclude, restrict or modify your mandatory statutory rights and are in addition to them. They are not how a warranty replacement normally happens here.

In practice you go back to where you bought it, and the goods stay in the country. Ubiquiti sells into Australia through authorised distributors and resellers, and those distributors run their own RMA processes locally. Streakwave Pty Ltd, an authorised distributor on St Kilda Road in Melbourne, publishes a typical example: a warranty claim form with proof of purchase and the MAC or serial number, the product returned to Streakwave in Australia within 30 days of the claim being approved or the ticket is void, and a service and delivery fee charged if no fault is found. Ubiquiti’s current list of authorised distributors is at ui.com/distributors. An Australian business does not have to ship a faulty access point to the United States.

What Ubiquiti does not publish is a turnaround commitment. There is no advance replacement product and no stated number of days to a replacement. That is the real gap, and it is a scheduling problem rather than a legal one.

Which is why the operational answer is unchanged regardless of who processes the paperwork. You do not run a UniFi site on the assumption that an RMA is your continuity plan. You keep a cold spare gateway and a spare access point on the shelf, because the hardware is cheap enough that a spare costs less than the downtime. Any provider deploying UniFi without holding spares is transferring risk to you quietly.

Meraki: a published clock, and freight from the United States

Meraki publishes what Ubiquiti does not. Advance replacement is available on request, and Meraki’s support policy states that unless you have purchased Cisco RMA Upgrade (formerly branded Meraki Now), advance replacement orders ship within one business day on a best-effort basis. Cisco ships warranty RMAs to the original shipping country or region listed on the original order, and a service contract such as Cisco RMA Upgrade is what allows shipment to a different country based on the install address, subject to Cisco’s Service Availability Matrix.

Factor international transit in before you treat that as a same-week answer. Meraki’s published shipping policy states that shipments to Australia and New Zealand ship from its United States distribution centres, and that Australian shipments go via DHL. A one business day ship commitment is a ship commitment, not a delivery commitment.

Note the return obligation too, because it catches people. Defective parts must go back within ten calendar days of receiving the replacement, and if they are not returned within thirty calendar days Cisco may charge the full undiscounted list price for the parts and reduce or deny services until it is paid.

Meraki’s hardware warranty terms are worth stating precisely, because “lifetime warranty” is doing some work in Cisco’s marketing. Per Meraki’s own warranty documentation: MX and Z-series, MG cellular gateways, MS and CS switches including the C9300-M, and indoor MR and CW access points carry a lifetime warranty. Outdoor MR and CW access points carry one year. MV Gen 1 and MV2 cameras carry three years and later MV generations five years, MT sensors three years, and accessories such as SFPs, mounts, antennas and PoE injectors one year. “Lifetime” here means the warranty ends at the product’s end-of-support date, not that it runs forever. A warranty is also not a licence: a device with three years of licence remaining and an expired warranty is not replaceable.

Meraki includes 24×7 technical support with active licensing rather than selling it separately. Catalyst is the reverse: TAC access requires an active service contract such as Smart Net Total Care, entirely separate from the licensing stack.

Cisco’s Smart Net Total Care service description lists hardware replacement service levels of two hour, four hour, next calendar day, next business day and ship next business day, with an onsite field engineer option on every level except ship next business day. What Cisco does not publish is which of those you can buy at your address. The service description states that advance replacement services are subject to geographic and weight restrictions and directs you to check availability in Cisco’s Service Availability Matrix, which is an address-level lookup run through Cisco or a Cisco partner rather than a published list. Cisco also notes that an advance replacement crossing a national boundary ships Delivered At Place, exclusive of import duties and taxes, and that customs processes can condition actual delivery times.

So there is no honest way to tell you from a web page which service levels are available in Croydon, Bayswater or Belgrave. Before you price a Catalyst stack on the strength of a four hour response, have your Cisco partner run the exact install address through the Service Availability Matrix and put the answer in writing. A four hour commitment in a Melbourne CBD tower and a four hour commitment at a Dandenong Ranges address are not the same product, and the Matrix is the only thing that tells you which one is on offer.

Controller architecture: who holds the configuration matters more than where it runs

UniFi gives you four deployment options and they are genuinely different. The controller can run on a Cloud Gateway that is also your router, on a separate Cloud Key so the applications are offloaded, on Ubiquiti’s own hosted service, or self-hosted on your own server or cloud instance. Whichever you choose, the local control plane keeps managing devices when the internet is down, and remote access and multi-site orchestration through UniFi Site Manager is free.

Meraki has one option. Configuration lives in Cisco’s cloud. Devices keep forwarding traffic if the dashboard is unreachable, and Meraki fails over between its own data centres, but you cannot configure anything without the dashboard and you cannot manage the network on a laptop plugged into the switch. For a business that has just lost its internet service, that is the exact moment you want to change something.

Catalyst is the opposite extreme: the configuration is on the box, reachable by console cable, and nothing external is required to change it. This is why it still turns up in environments with genuine air-gap or regulatory constraints.

The honest read is that UniFi’s architecture is the most flexible of the three, and this is one of the few places where it wins outright rather than winning on price.

Security depth is where Cisco is genuinely ahead

Do not let the licensing critique above obscure this. Meraki’s MX security stack is deeper than UniFi’s, and if security inspection is your reason for buying, that is a real argument.

Meraki MX runs a Snort-based IDS/IPS, Cisco’s Advanced Malware Protection for file inspection against Cisco’s threat intelligence, content and web filtering, and DNS-layer filtering through integration with Cisco Umbrella applied per SSID or group policy. Threat Grid sandboxing for unknown files is available as an additional subscription on top of Advanced Security. Auto VPN builds site-to-site tunnels automatically, and the SD-WAN capability does application-aware path selection with cellular failover.

UniFi’s IDS/IPS is real and included, and CyberSecure improves the signature feeds materially, but the ecosystem behind it is not Talos. There is no equivalent to Umbrella’s DNS intelligence, no file sandboxing, and no comparable threat research operation. If your cyber insurance questionnaire or a client security review asks specifically about advanced malware protection at the perimeter, UniFi will need a compensating control elsewhere, usually a good EDR product and DNS filtering bought separately.

That said, most SME perimeter compromise does not come through the firewall. It comes through identity. Money spent on multi-factor authentication, conditional access and endpoint detection buys more risk reduction per dollar than money spent uplifting a perimeter licence tier. Spend in that order.

Scale ceilings are higher than most SMEs will reach, on both sides

Ubiquiti publishes figures per console. A Dream Machine Special Edition is rated for 100 or more UniFi devices and 1,000 or more clients. A Cloud Key Enterprise is rated for over 1,000 devices and 10,000 clients. The Enterprise Fortress Gateway is rated for 5,000 or more clients. A 200-person single-site business is nowhere near any of those numbers.

Cisco’s published SME-relevant guidance is different in kind. Meraki recommends keeping a dashboard network to 400 switches or fewer to avoid topology and interface performance problems, with no hard technical ceiling stated.

Neither platform’s scale ceiling is what will limit you. Density will. A 200-person office with everyone on a video call is a wireless design problem, not a controller capacity problem, and the answer is access point placement, channel planning and a proper site survey. That work is identical regardless of which badge is on the equipment, and it is the same discipline as designing wireless for a warehouse or workshop, just with different obstacles.

The skills each platform actually demands

UniFi can be configured by a competent generalist. That is its commercial advantage and its biggest risk. The interface will happily let someone build a flat network with one VLAN, no RADIUS, a guest network bridged to the LAN and a firmware version from three years ago, and it will work well enough that nobody notices until it does not. The skill UniFi demands is not driving the interface. It is knowing what the design should be before you open it.

Meraki demands roughly the same level, plus licensing administration discipline that UniFi does not require. The dashboard is deliberately approachable and does not need CCNA-level knowledge for day-to-day operation.

Catalyst on IOS-XE genuinely demands CCNA-level knowledge, and CCNP-level for the routing, SD-Access and policy features the Advantage subscription enables. If a Catalyst switch stack is installed in an SME and the person who configured it leaves, the next provider inherits a device they may not be able to change safely. That is a real business risk and it is the strongest single argument against Catalyst at this size.

Lifecycle and firmware discipline, which is a process problem not a product problem

Meraki publishes an end-of-life process: an end-of-sale announcement typically up to six months before the last order date, with support typically continuing for five years past end-of-sale. That gives you a planning horizon you can put in a budget.

Cisco’s SMB switching line has already turned over on the back of exactly that process, so if someone quotes you Cisco Business switches, know where they sit. Cisco announced end-of-sale for select models of both the Cisco Business 250 and Cisco Business 350 series on 30 April 2024. The last order date was 30 May 2024 for the CBS350 models and 29 October 2024 for the CBS250 models, and the last date of support is 31 May 2029 and 31 October 2029 respectively. Cisco’s own migration tables in those bulletins point CBS350 models at the Catalyst 1300 series and CBS250 models at the Catalyst 1200 series, so yes, Catalyst 1200 and 1300 are the current SMB replacement. The Cisco Business 220 series is a separate line, still listed as a current product, and Cisco has not published an end-of-sale bulletin for it. Check the series end-of-life notice listing before you commit to it, because that is where the announcement will appear first.

Ubiquiti’s position is different in kind, and this is the finding rather than a gap. Ubiquiti does publish release channels: in UniFi you choose between the Official and Early Access channels under Settings, Control Plane, Updates, and release notes for every application and firmware build are posted publicly at community.ui.com/releases. What Ubiquiti does not publish is a hardware end-of-life policy. There is no Ubiquiti equivalent of Meraki’s end-of-sale announcement, end-of-sale date and end-of-support date, no committed support period stated at launch, and no published schedule of end-of-life dates you can put in a budget. If you standardise a fleet on UniFi, your refresh planning has to come from your own asset register rather than from a vendor calendar. That is a real cost and almost nobody prices it.

Whatever the vendor publishes, the operational answer is the same on both platforms and it is the answer almost nobody follows: firmware gets applied on a schedule, in a change window, with a documented rollback, and someone owns it. We see far more outages caused by firmware nobody updated for four years than by firmware updated too eagerly.

The same discipline applies to the physical layer. A network is only as good as structured cabling, how the comms room is built and power protection in the rack. Replacing a switch does not fix a patch panel that was never labelled.

Where UniFi is genuinely the wrong choice

Be specific about this, because “UniFi is fine for small business” is a lazy answer.

• Where the network is a safety or revenue-critical system with a hard uptime obligation. Manufacturing lines, clinical environments, anything where an hour of network downtime has a defined cost. Meraki’s advance replacement and 24×7 support, or a Catalyst stack under a Smart Net Total Care contract at a service level Cisco confirms is available at that address, buys a continuity guarantee you cannot buy from Ubiquiti.
• Where a client security review or a tender explicitly requires named perimeter capabilities. Sandboxing, advanced malware protection, or a specific vendor’s threat intelligence. Arguing equivalence is possible but expensive in consulting hours.
• Where you need advanced routing. BGP, VRF separation, MPLS handoff, IS-IS. Catalyst does these properly and UniFi does not pretend to.
• Where the site already runs Catalyst and the team knows it. Ripping out working equipment to save on hardware that was already bought is not a saving.
• Where nobody will own it. UniFi rewards ownership and punishes neglect more visibly than Meraki does, because Meraki’s cloud will at least keep telling you what is wrong.

Where Cisco is over-specified for the site

Equally specific.

• A single-site professional services office of 10 to 80 staff with cloud-hosted line-of-business applications, no on-premises servers, and no unusual compliance obligation. The Meraki licence is buying redundancy of capability, not redundancy of service.
• Any site where the recurring licence would be renewed by someone who does not understand that non-renewal turns the network off. The 30-day grace period and organisation shutdown behaviour is a real operational hazard in a business without an IT manager.
• Retail, hospitality and multi-tenanted small sites where the real requirements are guest Wi-Fi separation, PoE and a firewall that does not fall over. Meraki does these beautifully and so does a device costing a fraction as much.
• Businesses growing fast enough that hardware will be replaced within three years anyway. Licence terms that do not transfer between models are a poor fit for a moving target.

The recommendation, and its trade-off

For most Australian SMEs, deploy UniFi, design it properly, hold cold spares on site, and put the money you did not spend on licences into identity security and endpoint detection instead. That is the recommendation.

The trade-off is explicit and you should accept it consciously: you are giving up a contractual replacement commitment and a deep perimeter security stack, and replacing them with your own spares inventory and your own discipline. If your business cannot maintain that discipline, or cannot tolerate an outage while a replacement device is sourced, the Meraki licence is not overpriced. It is the correct purchase and you should stop trying to talk yourself out of it.

The decision is usually made properly at only two moments: when you audit what you actually have, and when you are moving office or working through the fit-out decisions that have to be made before the walls close. If you are about to open a second location, read connecting a second office before you buy anything, because the WAN choice constrains the LAN choice. And if the network has to carry meeting room AV as well, size the wireless for it now rather than after the first bad call. Whatever you choose, it has to be documented properly or the next provider will be guessing.

TechAssist has designed and run both UniFi and Cisco networks for Melbourne businesses for over 20 years, with 13 certified specialists across the team, and we install the cabling and comms rooms ourselves rather than subcontracting them. If you want a straight assessment of which platform your site should be on, call 1300 028 324 or get in touch at https://techassist.au/contact/. We will tell you when the answer is to leave what you have alone.

Most small business comms rooms fail within two years for the same reason: nobody chose the room, the room was left over. A comms room is the space that houses your network rack, your patch panels, your carrier equipment and your UPS, and everything in your business that touches the internet or the network passes through it. Treat it as a room with a design brief, not a cupboard with a door.

Here is what to get right, and why the usual shortcuts stop working around the eighteen month mark.

Why they fail

Three failure modes, in order of frequency.

Heat. Every watt that goes into the rack comes out as heat. A sealed cupboard with no air path reaches equilibrium at a temperature well above what the equipment is rated for, and the result is not a dramatic failure, it is switches that reboot occasionally, drives that die early and a UPS whose batteries age at several times their rated rate. Nobody connects the symptom to the room.

Growth. The rack was sized for the equipment on day one. Then came a second switch, a firewall, a NAS, the carrier’s equipment, a patch panel for the extra desks and a UPS. There is now no vertical space, no depth and nowhere to route the cables, so equipment sits on shelves and cables run diagonally.

Discipline. The first patch was neat. The two hundredth was not. Without a labelling scheme and a rule that every change gets documented, a comms room degrades into something nobody will touch, which means changes get made badly because tracing the correct cable takes too long.

All three are design problems, and all three are cheap to prevent.

Siting: where it must not go

Not the kitchen or a kitchen cupboard. Water, steam, heat from appliances and food traffic.

Not under the stairs. It is a heat trap, it usually has no dedicated circuit, and the headroom means you cannot get a ladder or a person behind the rack.

Not against a west-facing external wall or anywhere with direct sun. Solar gain on a wall is significant and it peaks at the same time as the afternoon load.

Not the store room that will later hold stock, cleaning chemicals or the Christmas decorations. Shared rooms fill up, and equipment ends up boxed in.

Not near the plant room, lift motor room, or the main switchboard if you can avoid it, because of electrical noise and heat.

What you want instead is an internal room or a dedicated cupboard with a solid door, no water services above or adjacent, a way for air to move, a dedicated power circuit, room to open the rack front and rear, and a lock. AS/NZS 3084:2017 covers telecommunications pathways and spaces for commercial buildings and is the standard your cabling contractor should be designing the space against.

Central is better than convenient. Cable runs are limited in length, and a comms room in one corner of the floor plate means longer runs and, on larger floors, a second room.

Rack sizing and depth

Two dimensions and both are usually got wrong.

Height, measured in rack units. Count everything going in: patch panels, cable management bars between them, switches, firewall, carrier equipment, UPS, any server or NAS, and a power distribution unit. Then add the growth. A rack that is full on the day it is commissioned is a rack that will have equipment sitting on a shelf within a year. Vertical space is the cheapest thing in the room.

Depth. This is the one that catches people out. Wall-mounted cabinets are often too shallow for anything with a real chassis, and once you add patch leads at the front and power leads at the rear, the door will not close. Depth also determines whether air can move around the equipment. As a concrete example of how specific carrier requirements get, nbn’s Enterprise Ethernet BNTD location guide specifies a minimum rack depth of 300mm for the equipment tray, a mandatory 1RU clearance for cooling, a minimum 26mm clearance at the cooling vents, and a recommended minimum 900mm clearance at the front of the rack for installation and maintenance access. If your rack is jammed against a wall in a corridor, the carrier’s installer may simply refuse the job.

Access. Front and rear access is the difference between a ten minute change and a two hour one. A floor-standing rack you can walk behind beats a wall cabinet you have to unscrew, every time. If a wall cabinet is genuinely the only option, get a swing-frame type so the body hinges away from the wall.

Mounting height. The nbn guide caps equipment height at 2.4m and prefers below 1.8m, with a minimum clearance from the ground. That is a reasonable rule for everything in the room, not just carrier gear. Anything you cannot reach without a ladder will be maintained badly.

Power and dedicated circuits

The comms room needs its own circuits, not a spur off the office ring that the cleaner’s vacuum also lives on.

Specify at least one dedicated circuit for the rack, sized for the full load with headroom, and have your electrician design it under AS/NZS 3000. Two circuits from separate breakers is better if you have dual-corded equipment. Put the outlets where the rack is, not across the room, and use a rack-mounted power distribution unit rather than a power board on the floor.

You also need a communications earth or rack earth. This is standard practice and, for carrier equipment, it is a stated requirement.

One more thing that costs nothing: label the breaker in the switchboard, clearly, and label the outlets in the room. The number of outages caused by someone turning off the wrong circuit during unrelated works is not small.

UPS sizing: the method, not a number

Do not buy a UPS by guessing. Work through this sequence.

1. Inventory the actual load. Every device going in the rack, at its real draw, not its nameplate maximum. Nameplate ratings are worst case and buying to them wastes money.
2. Add the growth. Whatever you are going to add over the life of the unit, plus PoE budget if your switches power access points, cameras and phones, because PoE load is real load.
3. Add headroom. Running a UPS at the top of its rating shortens battery life and leaves nothing for a future addition.
4. Convert correctly. UPS capacity is quoted in volt-amps and in watts, and they are not the same number. Size against the watts figure for your real load, and check the power factor rather than assuming.
5. Decide what runtime is for. There are two different answers and they lead to very different units. If the UPS exists to ride through brief interruptions and to shut equipment down gracefully, you need enough runtime for an orderly shutdown plus a margin. If it exists to keep the business trading through a longer outage, you need a much larger unit, or a generator, and you should say so out loud because the cost difference is substantial.
6. Plan for the batteries. UPS batteries are consumables. Decide now who monitors their health, who gets alerted, and what the replacement interval is. A UPS with dead batteries is a very expensive power board, and heat in a badly ventilated room shortens battery life considerably.
7. Test it. An untested UPS is an assumption. Test under load, on a schedule, and record the result.

Set the runtime target against your actual recovery requirement rather than a number that sounds reassuring. There is more detail on UPS and power protection if you want to go deeper on the equipment side.

Ventilation and heat load

The physics is simple. Almost all electrical power drawn by IT equipment is converted to heat, so the heat you have to remove is close to the power you put in. Add the UPS, which produces heat of its own.

Work out the total load in watts, treat that as the heat you need to shift, and then decide how it leaves the room.

Passive means vented door, vented cupboard, air path in at low level and out at high level, and a room that is part of the building’s conditioned volume. This works for genuinely small loads in a room with a decent air path. It stops working the moment you add a server.

Active means a dedicated split system or a supply and return into the room from the building system, sized for the heat load and not for the floor area. A room-sized calculation will undersize it every time, because the load per square metre in a comms room is nothing like an office.

Two rules. The room’s cooling must not depend on the building air conditioning being on, because building systems run to office hours and your equipment does not. And someone must be alerted when the room gets hot, which means a temperature sensor with alerting, not someone noticing on a Monday.

Also keep the rack airflow front to back. Blanking panels in unused rack units cost almost nothing and stop hot exhaust air recirculating to the front of the equipment.

Cable management and patching discipline

The rule is one cable, one path, one length.

Patch leads should be the correct length for the run, not a 3m lead coiled behind a 200mm connection. Horizontal cable management bars between every patch panel and switch. Vertical management down at least one side. Fixed cabling terminated onto patch panels, never directly into switches, because a patch panel is what lets you change equipment without re-terminating.

Keep power and data separated in the rack as well as in the walls. AS/CA S009:2020 requires separation between telecommunications cabling and electrical cabling, and it applies inside the cabinet, not only in the building fabric.

The discipline part matters more than the hardware. Set a rule that no temporary patch survives the day it was made, and that every change is recorded. A comms room degrades one shortcut at a time.

Labelling

Administration of communications cabling systems is covered by AS/NZS 3085.1:2004. Decide the scheme before termination and apply it consistently.

At minimum: every outlet labelled at the wall plate and at the patch panel with the same identifier; every patch panel labelled; every switch and port range labelled; every circuit and PDU labelled; carrier services labelled with the service ID so a fault call does not start with ten minutes of searching.

Labels must be machine printed and permanent. A handwritten label on masking tape is a label with a one year lifespan.

Physical security and access

The comms room holds the network. Anyone with physical access to it has physical access to everything on the network, and physical access defeats most software controls.

Lock it, and control the key. If you have access control on the building, put the comms room on it so you get an access log. Do not put it on the general cleaner’s key. Do not leave the key in the door because the cleaner needs to get to the mop sink, which is another reason not to share the room.

Fit a door contact so you know when it has been opened outside hours, and put a camera on the door rather than inside the room. Keep a visitor rule: contractors are escorted, and their work is recorded.

Smoke detection in the room should be on the building system. Do not put a sprinkler head directly over the rack if you have any say in it, and do not store anything flammable in there.

What good looks like at handover

Ask for all of this before you sign off. If the contractor cannot produce it, the job is not finished.

• Certification test results for every cable run, per outlet, from a calibrated tester, against the specified performance class.
• The registered cabler’s written statement certifying compliance with the Wiring Rules, which the Telecommunications Cabling Provider Rules 2014 require them to give you as the customer who commissioned the work.
• A rack elevation drawing showing what is in every rack unit.
• A patch schedule mapping every outlet to a panel port to a switch port.
• Floor plan with outlet numbers matching the labels physically applied.
• Carrier service details, service IDs and the fault reporting number.
• Photographs of the front and rear of the rack at handover, so future changes can be compared against a known good state.
• Confirmed power circuits, breaker labels and earth.
• UPS model, load at handover, calculated runtime and battery replacement date.
• A temperature reading in the room under normal load, taken with the door closed.

That last one is worth insisting on. A room that is already warm at handover, with the lowest load it will ever carry, is a room that will be a problem by the second summer.

Where this fits in the bigger job

If the comms room is part of a new tenancy, it needs to be on the drawings before the layout is frozen, which is covered in the fit-out checklist. The cabling that terminates in it is covered in professional data cabling and structured cabling, and the choice of the switches and gear that go in it is a separate decision that follows the room, not the other way around. If you already have a comms room and you are not sure how bad it is, audit what you already have first.

If your rack is in a cupboard and you are not sure whether it is a problem yet, take a photograph of the front and the back, and a temperature reading with the door shut, and send them to us. TechAssist builds comms rooms in-house across Melbourne’s outer east and greater Melbourne. Call 1300 028 324 or use https://techassist.au/contact/ to book a site visit.

There’s no single right answer to cloud vs colocation vs on-premises — the right home depends on the workload. Cloud suits variable, web-facing and rapidly scaling systems. Colocation suits steady, hardware-heavy workloads you want to own. On-prem still earns its place where latency, data volume or predictable cost rule. Most Melbourne SMEs end up running a mix.

“Cloud-first” became the default advice somewhere around 2018, and a lot of businesses moved everything to Azure or AWS on that logic alone. Some of those migrations were right. Plenty quietly cost more than the server they replaced, ran slower for the people using them, and locked the business into a bill that never stops. The honest version of this decision is workload-by-workload, not a blanket policy. Here’s how the three models actually compare.

The three models, in plain terms

On-premises

On-premises means your server lives in your building — usually a comms room or a cupboard with a UPS, an air conditioner working harder than it should, and a network switch. You own the hardware outright, you control everything, and you’re responsible for everything: power, cooling, physical security, replacement when a disk dies at 2am. For a single-site business with a line-of-business application that doesn’t need to leave the premises, this is often perfectly sensible, despite what the cloud marketing says.

Colocation

Colocation (colo) is the middle path. You still own the server hardware, but instead of sitting in your office it lives in a professional data centre — in Melbourne that means facilities like NEXTDC’s M1 in Port Melbourne, M2 in Tullamarine, M3 in Brunswick, or Equinix’s ME1/ME2 in the CBD. You rent rack space, power and cooling; the data centre provides redundant power feeds, industrial cooling, fire suppression, carrier-neutral connectivity and 24/7 physical security with biometric access. You keep full control of the box and what runs on it. You just stop being responsible for the building it sits in.

Cloud

Cloud — Microsoft Azure, Amazon Web Services, and the rest — means you run on someone else’s hardware and pay for what you consume. No box to buy, no rack to rent, no disk to replace. You spin up a virtual server, a database or a storage account, and the bill scales with usage. The trade is that you give up ownership and physical control in exchange for someone else handling the infrastructure entirely. The point here isn’t which cloud provider to pick, but what cloud as a model gives and costs you against the other two.

The honest trade-offs

Every comparison you’ll read from a cloud vendor frames their model as the obvious winner. The reality is a set of genuine trade-offs where each model wins on some axes and loses on others.

Cost model: capex versus opex

On-prem and colo are mostly capital expenditure — you buy the hardware up front, depreciate it over three to five years, and the running cost after that is power, cooling and maintenance. Cloud is operating expenditure — a monthly bill that scales with use and never ends. Neither is automatically cheaper. For a steady, predictable workload running 24/7, owning the hardware is frequently cheaper over its life than renting equivalent compute in the cloud, because you’re not paying a margin on every CPU hour forever. For bursty or unpredictable workloads, cloud wins because you only pay for what you use. The mistake is assuming “opex good, capex bad” without modelling your actual usage.

Control and security

On-prem gives you total control and total responsibility — including the parts you’d rather someone else handled, like patching the hypervisor and physically securing the room. Colo keeps your control of the software but hands physical security to a data centre that does it far better than your comms-room door lock. Cloud abstracts the hardware away entirely: you control your configuration, the provider controls the infrastructure, and the security model becomes shared responsibility — they secure the platform, you secure what you put on it. That shared-responsibility line is where a lot of breaches happen, because businesses assume the cloud provider is securing things they’re actually responsible for themselves. Whichever model you choose, the controls still need to align with frameworks like the Essential Eight; see our cybersecurity services for how that applies across hosting models.

Latency and data gravity

This is the axis cloud-first advice ignores most often. If you have an application that shifts large volumes of data, or one where staff feel every millisecond of delay — CAD and rendering, video editing, large databases, manufacturing systems talking to floor equipment — running it in a distant cloud region can be noticeably slower than a server in the same building or a nearby data centre. Data has gravity: once you’ve got terabytes sitting somewhere, moving it is slow and, in the cloud, expensive (egress charges). Latency-sensitive and data-heavy workloads are exactly the ones that often belong on-prem or in colo, not cloud.

Reliability, power and cooling

This is where on-prem usually loses badly. Your comms room has one air conditioner and, if you’re lucky, a UPS that buys you fifteen minutes. A data centre has N+1 (or better) redundant power with generator backup, industrial cooling, and uptime guarantees backed by an SLA. Cloud providers run the same industrial-grade infrastructure across multiple availability zones. If continuous uptime matters and your building can’t deliver it, on-prem is the weakest of the three — which is the most common reason businesses move to colo or cloud in the first place.

Scalability

Cloud wins this outright. Need more compute for end-of-month processing? Scale up for a few days and back down. With on-prem or colo, scaling means buying and installing hardware — a lead time of weeks and a cost you can’t easily reverse. If your demand is genuinely variable, that elasticity is the single best reason to be in the cloud.

Data residency

For Australian businesses handling regulated data — patient records under the Privacy Act and OAIC expectations, or data with contractual residency clauses — where the server physically sits matters. On-prem and Melbourne colo keep data unambiguously onshore. Cloud can too: Azure and AWS both run Australian regions. But cloud residency is a configuration discipline, not a default — you must confirm backups, logs and replicas don’t quietly land offshore. With on-prem and colo, the answer is simply “in this building.”

Side-by-side comparison

Why “cloud-first” isn’t automatically right

Cloud is the right answer for a great many workloads — web applications, anything seasonal or spiky, software-as-a-service products, and businesses that genuinely value never touching hardware again. But three situations regularly make cloud the wrong default.

The first is latency-sensitive or data-heavy work. A workload that moves large files constantly, or one where staff notice every delay, can run worse in a distant region than on local hardware — and the egress charges for shifting that data make it expensive too. The second is predictable, steady cost. A line-of-business server running flat-out 24/7 with no real variation often costs more to rent forever than to own and depreciate; the cloud premium only pays off when elasticity is doing real work. The third is regulatory or contractual constraint that’s simpler to satisfy with hardware you physically control than with a cloud configuration you have to audit continuously.

None of this is anti-cloud. It’s anti-dogma. The question is never “is cloud good?” — it’s “is cloud right for this specific workload?”

The hybrid reality most SMEs land on

In practice, almost no Melbourne SME we work with runs purely one model. The sensible setup is hybrid, decided workload by workload: email, collaboration and identity in Microsoft 365 and Azure where the cloud genuinely shines; a latency-sensitive line-of-business application on a local or colocated server; backups copied to a second location so a single site failure doesn’t take you out. The goal isn’t ideological purity. It’s putting each workload where it runs best for the cost.

This is exactly the kind of architecture decision a virtual CIO should be making with you, rather than defaulting everything to one model because it’s easier to manage or sounds modern.

How to decide, workload by workload

Run each workload through a short set of questions and the right home usually becomes obvious:

• How variable is demand? Spiky or seasonal leans cloud; flat and steady leans owned hardware.
• How latency-sensitive is it? If users or equipment feel every millisecond, keep it close — on-prem or colo.
• How much data does it move? Heavy data gravity makes cloud egress costly and on-prem/colo cheaper.
• What does uptime actually need to be? If your building can’t deliver it, colo or cloud beats on-prem.
• Are there residency or compliance constraints? Onshore-only data is simplest in Melbourne colo or on-prem.
• What’s the real total cost over five years? Model it — don’t assume opex beats capex.

A Dandenong scenario

A manufacturer in Dandenong we work with had been told by a previous provider to “move everything to the cloud.” They did — including the ERP system that talks constantly to machinery on the factory floor and a large file store of engineering drawings. Within weeks, staff were complaining that file opens that used to be instant now lagged, and the monthly Azure bill, padded by data egress every time someone pulled a drawing, had crept well past the cost of the server it replaced.

We didn’t reverse the whole thing — email, Teams and identity belonged in the cloud and stayed there. But the ERP and the drawing store went back onto a server, this time colocated in a Melbourne data centre rather than the old comms room. Latency dropped back to instant, the egress charges disappeared, and the colo facility gave them the redundant power and uptime their factory had never had on-site. The lesson wasn’t “cloud bad.” It was that the workloads had been placed by slogan instead of by fitness.

Frequently asked questions

What’s the difference between colocation and cloud?

With colocation you own the physical server hardware and rent space, power and cooling in a data centre; you keep full control of the box. With cloud, you own no hardware at all — you rent virtual compute and storage from a provider like Azure or AWS and pay for consumption. Colo is “your hardware, their building”; cloud is “their hardware, their building.”

Is on-premises dead?

No. On-prem still makes sense for single-site businesses with latency-sensitive or data-heavy applications, predictable steady workloads where owning hardware is cheaper over its life, and situations where physical control of data simplifies compliance. Its main weakness is reliability — a comms room can’t match a data centre’s redundant power and cooling — which is the usual reason to move to colo or cloud.

Where are Melbourne’s data centres?

The major carrier-neutral facilities include NEXTDC’s M1 in Port Melbourne, M2 in Tullamarine and M3 in Brunswick, plus Equinix’s ME1 and ME2 in the CBD. These offer redundant power, industrial cooling, fire suppression and 24/7 secured physical access, and keep your data unambiguously onshore.

Is cloud always more expensive than owning a server?

No — it depends entirely on the workload. For variable or bursty demand, cloud’s pay-for-what-you-use model is usually cheaper. For a server running flat-out 24/7 with stable demand, owning and depreciating hardware is often cheaper over its life, because you avoid paying a margin on every compute hour indefinitely. Always model your actual usage rather than assuming.

Making the call

The honest answer to where your servers should live is “it depends on the workload” — and that’s not a cop-out, it’s the only correct answer. Cloud, colocation and on-prem each win on different axes, and a well-run SME uses all three where each fits. The failure mode is treating it as a single ideological choice instead of a series of small, costed decisions.

If you’d like a straight assessment of where each of your workloads should live — and the real five-year cost of each option rather than a vendor pitch — explore our cloud services or get in touch with our team. We run Australian-employed engineers out of Tecoma and the Melbourne CBD, and we’ll tell you honestly which workloads belong in the cloud and which don’t.

Server virtualisation runs several independent virtual machines on a single physical host, so one server can do the work of many. Most Melbourne SMEs still keep some on-premises compute for performance, control or cost reasons. The 2026 question isn’t whether to virtualise — it’s which hypervisor, and whether you need hyperconverged infrastructure at all.

This post explains virtualisation in plain terms, walks through the hypervisor shake-up after Broadcom’s acquisition of VMware, and tells you honestly when hyperconverged infrastructure (HCI) earns its keep — and when it’s overkill. Most small SMEs don’t need it.

What server virtualisation actually is

A physical server has finite CPU, RAM and disk. Run one operating system on it directly and most of that hardware sits idle most of the time. Virtualisation inserts a thin software layer — a hypervisor — between the hardware and the operating systems, so you can run multiple virtual machines (VMs) on the one host. Each VM behaves like its own separate server: its own OS, its own applications, its own network identity, isolated from its neighbours.

The payoff is consolidation. A business that once had a domain controller, a file server, a line-of-business application server and a print server on four ageing boxes can run all four as VMs on a single modern host, with capacity to spare. Fewer machines to power, cool, patch and replace. VMs are also portable — you can back one up as a file, move it to another host, or spin up a copy for testing without touching the others.

Why SMEs still run on-premises compute

The cloud handles a great deal of what used to live in a server room, but on-premises compute hasn’t gone away, and for good reasons:

• Latency-sensitive applications — CAD, large file editing, manufacturing line systems and some practice-management software perform better when the server is on the same LAN as the users.
• Data gravity — when you hold terabytes of project files, shifting it all to cloud egress charges and re-downloading it daily makes no financial sense.
• Specific software — plenty of legacy line-of-business applications simply aren’t built to run as SaaS.
• Control and predictability — a fixed capital outlay every five years can beat an ever-climbing monthly cloud bill for steady, predictable workloads.

A construction firm in Box Hill we work with keeps its estimating and document servers on-premises precisely because the project files are enormous and the estimators can’t tolerate cloud latency mid-tender. Their email and collaboration live in Microsoft 365; their heavy compute stays local. That hybrid split is typical.

The hypervisor landscape in 2026

For over a decade VMware vSphere was the default choice and the safe one. That changed when Broadcom acquired VMware and overhauled the licensing — moving to subscription-only bundles, raising minimum core counts, and discontinuing the free ESXi hypervisor and the perpetual licences many SMEs relied on. For a small business running two or three hosts, the renewal quotes have in many cases multiplied. The result is a genuine migration away from VMware among cost-conscious SMEs, and a healthier set of alternatives than the market has had in years.

For most Melbourne SMEs already invested in Windows Server, Hyper-V is the pragmatic answer. It’s a Type 1 hypervisor that ships with Windows Server, it’s well documented, and the live migration and replication features that used to cost extra in VMware are built in. Proxmox is a strong open-source alternative where there’s no appetite for licence fees and the IT partner is comfortable supporting it. Nutanix and Azure Local are HCI platforms — which brings us to the next question.

What hyperconverged infrastructure (HCI) is

Traditional virtualisation often kept three things separate: the servers that provide compute, a shared storage array (a SAN or NAS) that holds the VM data, and the network switching that ties them together. That works, but it means buying, managing and troubleshooting three distinct systems, often from three vendors.

Hyperconverged infrastructure collapses compute, storage and networking into clustered nodes — standardised server units that each contribute CPU, RAM and local disk to a shared pool, managed as one system through a single software layer. Add capacity by adding another node. There’s no separate SAN to maintain; the storage is software-defined across the cluster. A three-node HCI cluster can lose a whole node and keep running, because the data is mirrored across the others.

When HCI suits a growing SME

HCI makes sense when an SME has outgrown a single host but doesn’t want the complexity and cost of a traditional SAN-plus-hosts build. The signals we look for:

• You’re running enough VMs that one host is no longer enough, and you need genuine high availability — workloads that must survive a hardware failure without downtime.
• You expect to grow and want to scale by adding nodes rather than forklifting in a bigger array.
• You want fewer moving parts and a single support relationship rather than separate storage, compute and hypervisor vendors.
• You have, or your MSP provides, the discipline to manage a clustered platform properly.

A manufacturer in Dandenong we support moved to a three-node HCI cluster when their ageing single host couldn’t run their ERP, MES and file workloads with any headroom — and a hardware failure would have stopped the production line. The cluster gave them the ability to patch and reboot a node during business hours without anyone noticing, which a single host never could.

High availability, backup and disaster recovery

Virtualisation makes resilience easier, but it does not provide it automatically. Three distinct things often get muddled, and the distinction matters when a server room floods or ransomware hits.

High availability (HA) keeps workloads running when a host fails. In a cluster, if one node dies, its VMs restart automatically on the surviving nodes. HA protects against hardware failure — it does not protect your data from deletion, corruption or encryption.

Backup is your independent, recoverable copy. The cardinal rule is that a VM snapshot is not a backup — snapshots live on the same storage as the VM and vanish with it. You need proper, application-aware backups written to separate storage, ideally following a 3-2-1 approach with at least one immutable, off-site copy that ransomware can’t reach. We go deeper on this in our guide to backup and disaster recovery for Melbourne businesses.

Disaster recovery (DR) is the plan and the tested capability to get the whole environment running again somewhere else after a serious incident. Virtualisation helps enormously here — because a VM is just a file, you can replicate it to a second site or to the cloud and bring it up there. The numbers that govern this are your recovery time objective and recovery point objective, which we unpack in RTO vs RPO explained. Set those targets before you design the platform, not after.

Cloud vs on-premises vs hybrid

The honest position is that this is rarely all-or-nothing. Three broad paths:

• Cloud-first — run workloads in Azure or AWS, or replace servers with SaaS entirely. Best for businesses with variable demand, distributed teams, or no desire to own hardware. You trade capital cost for an operating bill that scales with use.
• On-premises — keep compute local for latency, data gravity or cost predictability. Best for steady, heavy workloads where the maths favours owning the kit.
• Hybrid — the common reality. Keep latency-sensitive and data-heavy workloads on-premises, push email, collaboration and backup targets to the cloud, and use the cloud as a DR site. Our cloud services work is mostly designing and running exactly this kind of split.

The mistake we see is treating cloud as automatically cheaper. For a server that runs flat-out twenty-four hours a day, owning the hardware over five years often beats the equivalent cloud instance. For a workload that’s busy three days a month, the cloud wins easily. Match the model to the workload.

Right-sizing: most small SMEs don’t need HCI

Here’s the part the appliance vendors won’t lead with: the majority of small businesses do not need hyperconverged infrastructure. A five-to-twenty-person professional services firm with a couple of VMs is perfectly well served by a single well-specified Hyper-V host with solid backups and a tested cloud DR plan. HCI starts to earn its cost at three nodes and a real high-availability requirement — below that, you’re paying for resilience and scale you won’t use.

Equally, plenty of SMEs we onboard are running more on-premises than they need to. If your file server, line-of-business app and identity could all sensibly move to Microsoft 365 and Azure, the right answer might be fewer servers, not a fancier cluster. Right-sizing cuts both ways — sometimes up to HCI, often sideways to hybrid, occasionally down to almost nothing on-site. The discipline is matching the architecture to the actual workload and risk tolerance rather than the brochure.

The MSP role in design and management

Virtualisation and HCI are easy to buy and easy to get wrong. The value of a competent MSP is in the design decisions made before anything is purchased: sizing the hosts to the workload with genuine headroom, choosing the hypervisor that fits your licensing and skills, designing HA and backup so they actually protect you, and setting RTO and RPO targets you’ve signed off on.

Then there’s the ongoing work — patching hosts and guests, monitoring capacity before you run out of it, testing DR restores so you know they work rather than hoping, and keeping the platform aligned to the Essential Eight. TechAssist is a Melbourne-based MSP founded in 2014 with 13 Australian-employed engineers — not offshore — and our managed IT services include this design-and-run work under fixed per-user monthly pricing rather than scope-creeping hourly billing. Our 24/7 NOC in Tecoma watches the hosts overnight so a failed node at 2am gets handled before you walk in.

Frequently asked questions

Is server virtualisation still worth it for a small business in 2026?

Yes, for almost any business running more than one server workload. Consolidating several roles onto one virtualised host saves on hardware, power and management, and makes backup and recovery far simpler because each VM is portable. The only businesses that genuinely don’t benefit are those that have moved everything to SaaS and the cloud and keep nothing on-premises.

Should I move off VMware because of the Broadcom changes?

Not reflexively — but it’s worth pricing the alternatives at your next renewal. If your VMware subscription quote has jumped substantially, Hyper-V (which you likely already licence through Windows Server) or Proxmox can deliver the same outcomes for an SME at far lower cost. Migration takes planning, so don’t leave it to the week before renewal.

What’s the difference between virtualisation and hyperconverged infrastructure?

Virtualisation runs multiple VMs on a host. HCI is an architecture that combines compute, storage and networking into clustered nodes managed as one system, removing the need for a separate storage array. All HCI involves virtualisation, but you can virtualise perfectly well on a single host without any HCI at all.

Do I need high availability or just good backups?

They solve different problems. High availability keeps you running through a hardware failure; backups let you recover from data loss, corruption or ransomware. A single host with excellent, tested backups is fine for many small businesses. If even an hour of downtime is unacceptable, you need HA as well — but never HA instead of backups.

Getting the architecture right

Server virtualisation is settled technology; the interesting decisions in 2026 are which hypervisor, how much resilience you genuinely need, and where the line between on-premises and cloud should sit for your business. Get those right and you spend nothing you don’t have to. Get them wrong and you either over-build a cluster you’ll never fill or under-protect a server you can’t afford to lose.

If you’re facing a VMware renewal, an ageing host, or a growth jump that’s straining your current setup, get in touch. We’ll look at what you actually run before recommending anything — and quite often the right answer costs less than you expect.

Azure is worth it for a small business when you have a workload that genuinely needs cloud infrastructure — a server to retire, a line-of-business app to host, virtual desktops for a hybrid team. For most Melbourne SMEs, though, Microsoft 365 plus a small NAS does the job, and Azure becomes a bill you didn’t need.

Microsoft Azure small business deployments fail in one of two ways: a business pays for cloud infrastructure it doesn’t need, or it lifts a server into Azure with no cost controls and gets a quarterly bill that triples overnight. Both are avoidable. The trick is knowing what Azure actually does, where it earns its keep for an SME, and where a cheaper option does the same job without the meter running.

What Azure actually is, in plain terms

Azure is Microsoft’s public cloud — a set of data centres you rent compute, storage and networking from by the hour or the gigabyte. Instead of buying a physical server, racking it in a cupboard at your office and replacing it every five years, you run the same workload on Microsoft’s hardware and pay for what you use.

The catalogue is enormous — hundreds of services — but a small business touches a small slice of it. The services that matter for an SME are virtual machines (a server in the cloud), identity (Microsoft Entra ID, formerly Azure AD), file storage, backup, and virtual desktops. Everything else is for software developers and large enterprises, and you can safely ignore it.

One point of confusion worth clearing up: Microsoft 365 is not Azure. Microsoft 365 — your email, Teams, SharePoint and Office apps — runs on Microsoft’s cloud, but it’s a finished, fixed-price product. Azure is the raw infrastructure underneath. Plenty of businesses run entirely on Microsoft 365 and never touch Azure at all, and that’s a perfectly good place to be.

Where Azure earns its keep for an SME

Azure makes sense when you have a specific workload that needs infrastructure. Here are the use cases we actually deploy for Melbourne small businesses, rather than the marketing list.

Lift-and-shift a server as a virtual machine

The most common entry point. You’ve got an ageing physical server running an accounting package, a file share or a legacy app, and it’s due for replacement. Rather than spend $8,000 on new hardware that sits idle most of the day, you rebuild it as an Azure virtual machine. No cupboard, no UPS, no five-year refresh cycle. This is genuinely useful when the app can’t move to a SaaS alternative — but it’s also where the bill-shock stories start, because a VM bills every hour it’s switched on whether anyone’s using it or not.

Identity with Microsoft Entra ID

If you’re on Microsoft 365 you already use Entra ID — it’s the directory your staff log in against. Azure lets you extend it: conditional access, single sign-on to other apps, and proper multi-factor enforcement. We treat identity as the foundation of any cloud build, and we’ve written separately about conditional access policies in Microsoft 365 because getting them right is what stops a leaked password becoming a breach.

Azure Files and Azure Backup

Azure Files gives you a cloud file share that maps like a normal network drive. Azure Backup and Azure Site Recovery protect servers and workloads — Backup for restoring files and machines, Site Recovery for failing a whole server over to the cloud if your primary site goes down. These are solid, and we use them, but they’re only one ingredient in a proper recovery plan. The thinking that matters is your RTO and RPO — how long you can be down and how much data you can afford to lose — not the tool itself.

Hosting a line-of-business app

If your business runs on a specific Windows application — a job-management system, a CAD licence server, an old ERP — and the vendor won’t or can’t move it to SaaS, Azure is a sensible home for it. You get a reliable, monitored, backed-up environment without owning the hardware. This is where Azure clearly beats a server in the cupboard.

Virtual desktops: Azure Virtual Desktop and Windows 365

If you have staff who need a full Windows desktop from anywhere — contractors, a hybrid team, people on locked-down or BYO laptops — virtual desktops put that desktop in Azure. Azure Virtual Desktop is the flexible, consumption-priced option; Windows 365 is the simpler fixed-per-user-per-month version (a Cloud PC). Windows 365 is usually the better fit for a small business precisely because the price is predictable. AVD is more powerful but needs someone watching the meter.

The cost model reality

This is the part nobody enjoys, and it’s the part that decides whether Azure is worth it. Azure is consumption-based: you pay for compute by the hour, storage by the gigabyte, and data movement by the transaction. There’s no fixed monthly number on the box. That flexibility is the whole appeal, and it’s also exactly how businesses overspend.

A few realities to hold onto:

• VMs bill while they’re running, not while they’re being used. A server left on 24/7 that’s only needed during business hours is burning roughly three times the cost it should. Auto-shutdown schedules fix this in minutes.
• Reserved instances cut compute costs sharply. If a VM is going to run for the long haul, committing to a one- or three-year reservation can cut the compute price by 40 percent or more versus pay-as-you-go. Most SMEs leave this money on the table.
• Storage and egress add up quietly. Old backups, orphaned disks from deleted VMs, and data being pulled out of Azure all bill in the background. These are the line items that make a quarterly invoice mysterious.
• Data residency matters. For Australian businesses, you deploy into the Australia East region (Sydney). Your data stays onshore, which keeps you comfortable for privacy and contractual reasons under the Privacy Act and the OAIC’s expectations. Don’t let a default drop your data into a US region.

Azure vs Microsoft 365 plus a NAS vs staying on-prem

Azure is not the default answer. For a lot of Melbourne SMEs, the right call is the cheaper one. Here’s how we frame the decision.

The pattern is simple: if your needs are documents, email and collaboration, Microsoft 365 with sensible backup is enough, and Azure is overkill. The moment you have a server-based workload, virtual desktops, or a recovery requirement you can’t meet locally, Azure starts earning its place.

FinOps: the cost-control discipline that makes Azure worth it

FinOps is just the practice of treating cloud spend like any other managed expense — measured, budgeted and reviewed, not left to drift. For a small business it doesn’t need to be a department. It needs a handful of controls:

1. Budgets and alerts. Set a monthly budget in Azure Cost Management with alerts at 50, 80 and 100 percent. You should hear about an overspend the week it happens, not on the invoice.
2. Auto-shutdown and right-sizing. Switch off VMs out of hours and match the VM size to the actual workload. Most environments are over-provisioned because someone picked a bigger size “to be safe”.
3. Reservations for steady workloads. Anything running long-term should be on a reservation, not pay-as-you-go.
4. Tagging and clean-up. Tag resources by purpose so you can see what’s costing what, and delete orphaned disks, snapshots and old backups on a schedule.

None of this is exotic. It’s the difference between Azure being a controlled line item and Azure being a surprise.

A scenario from the eastern suburbs

A surveying firm in Box Hill we work with came to us after a self-managed Azure setup. They’d lifted their old file-and-app server into a VM, which was the right call — but the VM ran 24/7, the original oversized disk was still being billed alongside its replacement, and there were no budget alerts. Their spend had crept to nearly double what the workload justified. Adding an out-of-hours shutdown schedule, right-sizing the VM, moving it onto a one-year reservation and deleting the orphaned disk brought the monthly cost down by roughly a third — for the same performance. Nothing clever; just the discipline that should have been there from day one.

The MSP role: governance, not just deployment

Anyone can spin up a VM in Azure. The value an MSP adds is everything around it — making sure the build is sized correctly, deployed to Australia East, backed up to a tested standard, secured with proper identity controls, and watched so the bill doesn’t run away. That’s governance, and it’s the part a business can’t easily do for itself between everything else it’s juggling.

At TechAssist we’re a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers — no offshore helpdesk. Our 24/7 NOC at Tecoma monitors the environments we run, so a backup that silently fails or a cost that spikes gets caught by us, not discovered by you on the invoice. We build and manage Azure as part of our broader cloud services, and we’ll tell you plainly when Azure is the wrong answer and Microsoft 365 plus a NAS would serve you better and cheaper. We’re also Essential Eight aligned, which matters once you’re putting business data into the cloud.

The honest position is this: Azure is a powerful tool that’s worth it for the right workload, with the right controls, in the right region — and an expensive mistake without them. The job is matching the tool to your actual needs.

Frequently asked questions

Is Azure cheaper than buying a server?

Sometimes. Over five years, a well-governed Azure VM with a reservation and an out-of-hours shutdown can beat the total cost of owning, powering and replacing a physical server — and you avoid the capital outlay. Without those controls, Azure is usually more expensive. The cost discipline is what decides it.

Where is my data stored if I use Azure in Australia?

If you deploy into the Australia East region, your data sits in Microsoft’s Sydney data centres and stays onshore. This is the right default for Australian businesses with privacy or contractual obligations. Always confirm the region at deployment — don’t assume it.

Do I need Azure if I already have Microsoft 365?

Usually not. Microsoft 365 already covers email, documents and collaboration. You only need Azure on top of it when you have a workload that needs actual infrastructure — a server, a hosted line-of-business app, or virtual desktops.

How do I avoid a surprise Azure bill?

Set budgets and alerts in Azure Cost Management, switch off VMs out of hours, use reservations for steady workloads, and delete orphaned resources. An MSP managing the environment should be doing all of this and reviewing the spend with you regularly.

Can a small business run virtual desktops affordably?

Yes. Windows 365 gives you a fixed per-user-per-month Cloud PC, which keeps costs predictable for a small team. Azure Virtual Desktop is more flexible but consumption-priced, so it needs the cost discipline to stay affordable.

Not sure whether Azure is worth it for your situation, or worried an existing setup is costing more than it should? Talk to us — we’ll give you a straight answer, not a sales pitch.