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
| Factor | On-premises | Colocation | Cloud (Azure/AWS) |
|---|---|---|---|
| Cost model | Capex — you buy the hardware | Capex (hardware) + opex (rack/power) | Opex — consumption-based, never ends |
| Who owns the hardware | You | You | The provider |
| Control | Total — and total responsibility | Full software control; facility outsourced | Configuration only; shared responsibility |
| Physical security | Your comms-room door | Biometric, 24/7, audited data centre | Provider-managed, abstracted away |
| Power & cooling | One AC, a UPS, your problem | Redundant power, generators, industrial cooling | Multi-zone, industrial-grade |
| Latency | Lowest — same building | Very low — nearby Melbourne DC | Region-dependent; egress costs to move data |
| Scalability | Buy more hardware (weeks) | Buy more hardware (weeks) | Elastic — scale in minutes |
| Data residency | Unambiguously onshore | Unambiguously onshore (Melbourne) | Onshore if configured correctly |
| Best for | Single-site, latency-sensitive, predictable cost | Owned hardware needing real uptime | Variable, web-facing, rapidly scaling workloads |
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.