The Cart Before the Cable: Why Cloud Plans Need a Connectivity Audit First

Few phrases are accepted as readily in UK boardrooms as cloud first. It signals modernity, flexibility and a welcome reduction in server-room maintenance. What it rarely signals is a considered position on the connection that everything now depends upon.

In practice, the sequence is familiar. A cloud or managed service contract is procured, migration is scheduled, and somewhere in the final weeks someone asks whether the line will cope. The answer is usually yes, because the line works today. Whether it will work on a Tuesday morning when thirty staff are on a video call while the finance team uploads a month-end file is a different question, and one that was never asked.

Where the order goes wrong

Cloud services move computation and storage off-site. They do not move the dependency. Every application, every file, every call and every backup now travels across a circuit that was often specified for a smaller business doing a different kind of work.

Consider a professional services firm of forty people. A single hour of lost connectivity during a billing week is not an inconvenience; it is deferred revenue, missed deadlines and a queue of clients waiting for answers. Multiply that by the frequency of incidents, add the staff time spent reconnecting, and the cost of a modest resilience upgrade usually looks small against the exposure it removes.

Upload is the number nobody checks

The metrics quoted in most broadband advertisements are download speeds. Cloud services are frequently constrained in the other direction. Large file uploads, video conferencing, voice over IP, remote backup and virtual desktop sessions all consume upstream capacity.

A connection that delivers several hundred megabits downstream may offer only a fraction of that upstream. For a business whose staff mostly consume content, that asymmetry is harmless. For a business sending design files, running hosted telephony or backing up to a data centre overnight, it becomes the limiting factor. Ask for the upload figure in writing, and ask what it looks like at nine in the morning.

Contention, or why the line is slower than the contract says

Many business broadband products are contended, meaning capacity is shared with other premises on the same infrastructure. A contended service is entirely reasonable for general office use, but the headline speed is a best-case figure rather than a guarantee. Where a provider offers a committed data rate with a service level agreement, the price rises accordingly.

The question for a buyer is not which product is faster on paper, but which product matches the way the business now works. If the honest answer is that a shared line is sufficient, that is a legitimate conclusion. It should, however, be a conclusion rather than an assumption.

The failover that exists only on paper

Resilience is frequently procured as a tick-box. A secondary connection is arranged, sometimes on the same physical infrastructure as the primary, and everyone assumes the risk is covered. Two circuits sharing a duct fail together.

Genuine resilience means diversity, whether through a separate carrier, a different physical route, or a mobile service with sufficient allowance to carry the business for a working day. It also means testing. A failover configuration that has never been exercised is a comfort rather than a control, and the moment to discover it does not work is not during an outage.

Support is part of the product

Managed service contracts vary enormously in what happens when something breaks. The distinction between a service desk that logs a fault and one that owns it until resolution is not a matter of tone; it is a matter of contractual obligation.

Before signing, establish who answers the phone at eight in the morning, what the response targets are, whether those targets carry service credits, and how escalation works when the first-line response does not resolve the issue. Also establish what the supplier needs from the customer: a named contact, out-of-hours access, remote monitoring permissions. Support that depends on information nobody supplied tends to disappoint.

Questions worth asking before the ink dries

• What upstream and downstream capacity does the service contractually deliver, and is there a committed rate?
• How is the connection shared with other users, and what does the agreement say about performance at peak times?
• What resilience is included, is it physically diverse, and when was it last tested?
• What are the response and resolution targets, and what remedy applies if they are missed?
• What happens to data, telephony numbers and configuration if the relationship ends?
• Which parts of the service depend on third parties, and who manages those relationships?
• What monitoring is in place, and who receives the alerts?

A sequence that holds up

Cloud first is a sensible ambition, but it is not a strategy on its own. The more durable approach is to understand the connection, the resilience and the support model first, then choose a cloud estate that fits them, and finally procure the whole arrangement as one dependency rather than three separate line items.

Businesses that get this right tend not to describe themselves as cloud first. They describe themselves as able to work, which is the outcome the phrase was supposed to describe in the first place.