When to move to colocation? The same business, stage by stage
Nobody rents a rack on day one, and nobody should wait for the first serious outage to think about it. In between, an infrastructure always grows the same way: in stages, each one triggered by a business event, never by technology. This guide details those stages in order, with their concrete translation: what you rent, what it costs, what breaks next.
The question is not “how many servers” #
People look for a magic threshold: “from N machines on, you need a rack”. That threshold does not exist. What exists is a sequence of business events that make each step inevitable: the site that must stay up overnight, traffic that doubles after press coverage, the insurer who asks for a recovery plan. Technology never precedes the business, it answers it. So this guide follows a simple thread: a business that works, and its infrastructure growing stage by stage, each time with the only question that matters here: what does it change about what you rent in a data centre?
In practice: three facts to settle before reading #
- Your current stage. Where does your service run today: an office computer, a rented server, the public cloud, already a rack? It is the first question our Architect asks, and the answer changes the whole calculation.
- Your machines, today and in three years. No clever forecast needed: about the same, half more, twice as many? Growth picks the rack format, and changing format later costs hundreds of euros a month and an outage.
- What would wake you at night. One hour of downtime? A day of lost data? Your answer decides the last stage of this guide, and it is the most expensive one: pointless to pay for it before you need it, dangerous to ignore it when you do.
Stage 0: everything runs on a computer, somewhere #
The early site runs on someone's computer, at the office or at home. As long as it is an experiment, that is fine: nothing is cheaper. The limits arrive with the first real users, and they are always the same: the machine must stay on around the clock, the office connection has neither a stable public address nor serious upstream bandwidth, a power cut stops everything until someone is physically there to restart it, and the backup lives in the same room as the original. None of these flaws can really be fixed at home: a data centre treats them as its trade, backed power, cooling, two network feeds, staff on site. That is exactly what colocation buys, and nothing else: a place built so that things do not switch off.
Stage 1: the first server in a rack #
The first colocation move is modest: one server in a fraction of a rack. Two words to know, and this guide will define every term this way, right where it is needed. The U: the unit of height in a rack, 4.45 cm; an ordinary server takes 1 or 2 U, a full rack offers 42 to 47, and you often rent a quarter (~10 U) or a half (~20 U). The kVA: the electrical power you reserve from the site, not what you consume; it, far more than space, will drive your bill. On the sites in our catalogue that publish their prices, a quarter rack reads between roughly €330 and €680 per month depending on site and city (read on 13 September 2026): that is colocation's real entry ticket, far from the “big accounts only” image.
Stage 2: split the app from the database, and read the power envelope #
The service works, traffic climbs, and the first serious optimisation is almost always the same: separate the application from its database, because both fight for the same machine's resources. Two servers, then. This is where a little-known rule changes the math: colocation offers generally include 1 kVA in the price (the 51 sheets in our catalogue that publish included power all state 1 kVA, read on 13 September 2026), which is roughly two recent servers. Beyond that, each additional kVA is billed, around €112 per month median across the 79 sites that publish that price. In other words: long before you fill the 10 U of a quarter rack, electricity drives your bill, not space. Our power guide explains why.
Stage 3: load, the balancer, and the first price cliff #
Traffic doubles. Two paths: a bigger machine (simple, but the price does not follow a straight line, and there is a physical ceiling), or several medium machines sharing the work. The second path almost always wins over time, and it introduces a new device: the load balancer, which spreads requests across servers. It does almost nothing per request, so one carries many servers. On the rack side, this stage pushes the fleet above 4 machines, and that is where the first cliff sits: moving from a quarter to a half rack costs hundreds of euros a month, in one step. It is not a trap when you see it coming: our Architect now announces how many machines you can still add before crossing it, and lays out the trade-off between following your need and aiming at your three-year target.
Stage 4: no more single point of failure, the physical version #
The traffic spike arrives, one device fails, and everything stops: you have just met the single point of failure, the element whose fall takes everything down with it. The software answer is well known: double the balancer. But the physical version matters just as much, and it is what a data centre sells: two power feeds (A and B), each able to carry the whole load, two network entries, and two distinct carriers, because a single carrier is a single point of failure like any other. This is also where the GTR appears (guaranteed time to repair): the contractual deadline to fix a link. A stage made entirely of things that never show on a software architecture diagram, yet decide real availability.
Stage 5: the database becomes the bottleneck, enter the cluster #
Application servers multiply painlessly: they are stateless, a request can land on any of them. The database has state: every write must end up everywhere, which is why you cannot multiply it the way you multiply web servers. At this stage the infrastructure becomes a cluster: several nodes, shared replicated storage (three copies of every piece of data), a dedicated network between nodes, and precise sizing rules, starting with the one everyone forgets: storage reserves memory and cores before the first virtual machine. Our Proxmox cluster sizing guide lays these rules out one by one, and the Architect computes them with the platform's reference manual as the source.
Stage 6: the whole site is the last single point of failure #
Everything in the rack is redundant; the rack itself remains. Fire, flood, regional outage: at this stage the question is no longer technical, it is business, and it fits in two sentences to put to your management. How long can the business stop? That is the RTO. How much data can it lose? That is the RPO. The answers decide everything else: a standby or active second site, synchronous replication (zero loss, but physics caps it around a hundred kilometres) or asynchronous, a dedicated link between the two racks. Our BCP / DR guide walks the method, the Architect proposes real data-centre pairs with their distance, and the optical budget checks that the link works.
Stage 7, as a branch: AI arrives with its kilowatts #
Not everyone reaches this stage, but when it comes it changes the nature of the problem: a modern AI server alone draws several kilowatts, and at that scale it is no longer space that decides the number of racks, it is the electrical density the site can cool. Beyond about 5 kW per rack, aisles must be contained; beyond 20, a cooled rear door; beyond that, liquid, which few sites sell. The “32 cards fit in one rack” reflex produces racks that exist nowhere. Our GPU and AI colocation guide treats this case separately, and the tool refuses to draw a rack the market does not sell.
The seven stages, on one page #
| Stage | The trigger | What you rent | The word to know |
|---|---|---|---|
| 0. The computer | the first real users | nothing yet | availability |
| 1. First server | it must stay on | quarter rack, ~0.7 kVA | U, kVA |
| 2. App + DB | the site slows down | quarter rack, ~1 kVA included | power envelope |
| 3. Load + balancer | traffic doubles | half rack: the cliff | load balancer |
| 4. A/B feeds | one failure stopped everything | half rack, 2 carriers | single point of failure, GTR |
| 5. The cluster | the database saturates | half to 1 rack | stateless / stateful |
| 6. Two sites | insurer or client demands it | 2 racks + a link | RTO, RPO |
| 7. AI, as a branch | an internal assistant, data on-site | the density to cool decides | kW per rack |
And where does the cloud fit? #
The public cloud is not an adversary: it is often another project's stage 0 or 1, and that is fine. The clearest decision rule we have read fits in one question: if what you need is elasticity, scaling up and down fast, absorbing unpredictable spikes, the cloud is built for that; if what you need is simply to stop running the infrastructure yourself, hosting or colocation answers better (M. Kavis, Architecting the Cloud, Wiley, 2014, p. 24). Many companies do both: the stable base in a rack, the spikes in the cloud. If you come from the cloud and the bill grows faster than usage, the Architect can now set your colocation quote against the cost of staying, wide range and assumptions shown.
What this guide does not cover #
The whole software side of the same story: configuring a balancer, spreading a database, choosing between read replicas and sharding. It is the same tale seen from inside the machines, it is abundantly told elsewhere, and none of it is specific to colocation. This guide deliberately stops at the half those tales almost never show: where those machines live, what they cost in a rack, and how the physical network follows. Also out of scope: moving an existing server room, which has its own path on this site, and picking one site over another, which is the comparator's job.
FAQ #
When at least two of these signals are present: the service must stay reachable outside office hours, a power or internet cut costs you customers, the backup lives in the same place as the original, or the cloud bill grows faster than usage. One signal can be worked around; two signals is stage 1 of this guide.
On the sites in our catalogue that publish their prices, a quarter rack reads between roughly €330 and €680 per month (read on 13 September 2026), with electricity generally included up to 1 kVA. The comparator gives site-by-site prices, and the Architect checks that the format holds your fleet.
Yes, and it is the best possible luggage: reverse proxy, certificates, access VPN, containerised services, everything is redone identically on a machine in a rack. What changes is not how you work, it is what surrounds the machine: backed power, two network feeds, staff on site.
To start, and to absorb spikes, often yes. The switch is worth computing the day the load becomes stable and predictable: that is when owning your machines in a rack becomes cheaper than renting them by the hour, and the decision rule fits in one question, elasticity (see the “And the cloud?” stage).
By space, about seven 1 U servers with patching. By included electricity, two: offers generally include 1 kVA, which is two recent servers at full load. Beyond that, the additional kVA is billed. That is the main limit of a small format, and it is rarely stated before the first invoice.
Written on 13 September 2026.
From reading to comparing: relevant data centers
Estimate my cost → Compare data centers