New Business Herald

Category: Technology

How technology shifts change costs, productivity and competition.

  • Cloud Repatriation: Why Some Companies Are Moving Workloads Back

    For roughly fifteen years, moving infrastructure to public cloud was treated as self-evidently correct. A growing number of companies at significant scale have since moved substantial workloads back to owned or colocated hardware — a practice generally called cloud repatriation.

    This is not a reversal of the cloud thesis. It is what happens when a technology matures enough for its economics to be evaluated on specifics rather than on principle.

    What cloud actually sells

    The core cloud proposition is not cheap computing. It is elasticity — the ability to acquire and release capacity on demand, paying only for what is consumed.

    That has real and substantial value. It converts capital expenditure into operating expenditure, eliminating large upfront outlays. It removes the need to forecast demand years ahead and provision for a peak that may never arrive. It compresses the time to launch new services from months to minutes. And it transfers the operational burden of hardware procurement, replacement and datacentre management to a specialist.

    Elasticity is priced, however, and it is priced into every hour of consumption — including the hours where it delivers nothing.

    Where the economics turn

    Cloud pricing is most advantageous for workloads that are variable, unpredictable, or short-lived. It is least advantageous for workloads that are large, steady and predictable — because for those, the flexibility premium buys nothing.

    A service running at consistent utilisation twenty-four hours a day, with demand that grows smoothly and predictably, has no use for the ability to scale to zero. It pays the elasticity premium continuously and never exercises the option.

    Reserved instances and committed-use discounts exist precisely to address this, and they materially narrow the gap. But they do so by requiring exactly the multi-year commitment and demand forecasting that cloud was meant to eliminate — which concedes the underlying point.

    The specific cost drivers

    Data egress. Moving data into a cloud provider is typically free. Moving it out is charged, often substantially. For data-intensive businesses — media, analytics, backup and content delivery — egress can become a leading line item. It also functions as a switching cost, since the expense of leaving scales with the volume of data accumulated.

    Competitive and regulatory pressure has pushed providers toward waiving egress fees for customers migrating away entirely, which reduces the lock-in effect at exit — though ongoing operational egress remains a live cost.

    Managed service margin. Managed databases, queues, search and analytics services carry a considerable premium over the raw compute and storage beneath them. That premium buys real operational value — patching, backup, failover, expertise not hired. Whether it is worth paying depends on whether the organisation has that expertise already.

    Idle and orphaned capacity. Because provisioning is trivial, over-provisioning is endemic. Oversized instances, forgotten test environments, unattached storage volumes and duplicated environments accumulate quietly. A meaningful proportion of the savings attributed to repatriation is, in reality, savings from finally auditing what was running.

    Hardware improvement outpacing price cuts. Server performance per unit cost has continued to improve substantially. Where a workload’s requirements are stable, the hardware needed to serve it gets cheaper each refresh cycle — a benefit that accrues directly to an owner and only indirectly, through provider pricing decisions, to a renter.

    What repatriation genuinely costs

    Comparisons that stop at the infrastructure invoice are incomplete and usually wrong. Running your own infrastructure means:

    • Staff. Infrastructure, network and security engineers, with on-call coverage. For a small team this cost alone can exceed any hardware saving.
    • Capital and its timing. Hardware is bought before it is used, on a refresh cycle, and financed.
    • Provisioning for peak. Capacity must cover maximum demand, so average utilisation is necessarily well below 100%.
    • Redundancy. Multi-site resilience, backup power and network diversity must be built and paid for, not assumed.
    • Compliance. Certifications inherited free from a cloud provider become the organisation’s own responsibility to obtain and maintain.
    • Migration. A one-off project cost, frequently large, and always larger than initially estimated.
    • Lost optionality. The ability to launch something new next week without a procurement cycle has value that is real and rarely quantified.

    Where repatriation tends to make sense

    A recognisable profile emerges from the cases that have worked:

    • Large absolute spend, sufficient that percentage savings justify a dedicated team.
    • Stable, predictable workloads with well-understood growth.
    • Data-intensive operations where egress or storage dominates the bill.
    • Existing infrastructure expertise in-house.
    • A mature product where the engineering constraint is cost rather than speed of iteration.

    The inverse profile — early-stage, unpredictable demand, small team, rapid iteration, no infrastructure specialists — is where cloud economics remain clearly favourable, and where repatriation would be a serious error.

    The hybrid outcome

    Most organisations that examine this seriously do not move everything. They move the specific workloads whose economics are unfavourable — steady-state compute, bulk storage, predictable batch processing — while retaining cloud for variable demand, disaster recovery, geographic expansion and services where managed tooling genuinely earns its premium.

    This is less rhetorically satisfying than either “cloud-first” or “cloud exit,” and it is what the arithmetic usually supports.

    How to evaluate it honestly

    • Measure per-workload cost, not aggregate spend. The decision differs by workload.
    • Establish the utilisation profile. Steady or spiky? The answer largely determines the outcome.
    • Complete a cost optimisation pass first. Many organisations discover the problem was waste, not the pricing model.
    • Cost the fully loaded alternative, including salaries, redundancy, compliance and migration.
    • Model over a full hardware refresh cycle, not a single year.
    • Assign an explicit value to lost flexibility rather than treating it as zero.

    The right answer is workload-specific and changes as a business matures. Treating it as an identity question — the kind of company we are — is the most expensive way to decide it.

    Related reading

    For the discipline of measuring technology returns, see how AI adoption is changing productivity measurement.

    This article is general information and journalism. See our Editorial Policy.

  • AI Is Changing White-Collar Work. Measuring It Is the Hard Part

    Organisations deploying AI tools across knowledge work are discovering an awkward problem: they cannot reliably tell whether it is working. This is not primarily a failure of the technology. It is a failure of measurement infrastructure that predates the technology by decades, and which AI adoption has merely exposed.

    Productivity has a definition, and it is not “speed”

    Productivity is output per unit of input. For manufacturing this is tractable: count units produced, count hours worked, divide. The output is physical, countable and homogeneous.

    Knowledge work breaks every one of those conditions. What is the output of a lawyer, an analyst, a designer, a manager? Documents produced is a measure of activity, not value — a lawyer producing twice the contracts of similar quality has doubled output; one producing twice the pages has not.

    Because genuine output is hard to measure, organisations substitute proxies: hours logged, tickets closed, lines of code, documents drafted, meetings held. These proxies were weak measures before AI. They are actively misleading now, because AI tools improve exactly the proxies while leaving the underlying question untouched. A team can double its document output and produce no additional value whatsoever.

    The task-to-firm gap

    The most consistent finding in research on AI and work is that measured gains shrink as the unit of analysis widens.

    At the level of a discrete, well-specified task — draft this summary, write this function, translate this document — controlled studies have generally found substantial time savings, frequently with the largest relative gains among less experienced workers, for whom the tool substitutes partially for expertise.

    At the level of the firm, these gains have been considerably harder to detect in financial results. The gap has several sources, and none of them are mysterious.

    Saved time must be redeployed to be worth anything. If a task that took two hours now takes one, the organisation captures value only if that hour is used for something productive. Often it is absorbed into slack, longer meetings, or additional revisions of work that was already adequate.

    Bottlenecks move. Accelerating drafting does not accelerate a process gated by legal review, client response or a monthly approvals meeting. The constraint relocates rather than disappearing, and total throughput barely shifts.

    Verification costs are real and frequently uncounted. Output that must be checked for accuracy carries a review burden. Where checking is nearly as expensive as producing — as it often is for factual, legal or numerical content — net savings can approach zero even when drafting time falls sharply. Studies measuring generation time without measuring verification time systematically overstate gains.

    Quality changes are not captured. If output quality improves, productivity gains are understated. If quality degrades in ways that surface later — errors caught downstream, rework, reputational cost — gains are overstated. Most measurement systems capture neither.

    An old pattern

    This is a recognisable historical shape. Robert Solow’s 1987 observation that the computer age was visible everywhere except the productivity statistics described the same phenomenon for information technology, and it took years before measured productivity growth clearly reflected computing investment.

    The explanation developed since — most associated with Erik Brynjolfsson and co-authors, and often called the productivity J-curve — is that general-purpose technologies require large complementary investments in intangibles: reorganised processes, retrained staff, restructured workflows, new management practice. Those investments are costly and are typically expensed rather than capitalised. During the transition, measured productivity can appear worse, because the costs are recorded immediately while the benefits accrue later and are partly invisible to national accounts.

    If that pattern holds, the current difficulty in measuring AI’s effect is expected rather than evidence of failure — and equally, it is not evidence of success. It is what an ambiguous transition legitimately looks like.

    What organisations are actually measuring

    In practice, most AI measurement programmes track adoption rather than outcomes: licences issued, weekly active users, queries submitted, self-reported time saved.

    These are usage metrics. They establish that a tool is being used, not that it is creating value. Self-reported time savings are particularly unreliable — respondents estimate against a counterfactual they never observed, and are subject to well-documented optimism when reporting on tools they have chosen to adopt.

    Approaches that produce usable evidence

    Several methods yield defensible answers, and all of them require more discipline than a dashboard.

    • Staggered rollout with a control group. Grant access to part of the organisation first and compare outcomes against a comparable group without access. This is the closest most firms can get to a controlled experiment, and it is administratively straightforward if planned before deployment rather than after.
    • Measure end-to-end cycle time, not task time. Track the interval from work initiation to completed, accepted delivery. This captures bottleneck relocation and verification burden, both of which task-level timing misses.
    • Instrument quality explicitly. Error rates, rework frequency, downstream complaints and revision counts. Without a quality measure, any throughput gain is uninterpretable.
    • Track where saved time goes. If capacity is freed, establish what it was redeployed to. Unredeployed capacity is not a productivity gain.
    • Separate experience levels. Effects have consistently differed between novice and expert workers. Blended averages conceal both.

    The measurement trap to avoid

    The strongest temptation is to adopt whichever metric moves most, since it produces the most persuasive internal narrative. This is Goodhart’s law waiting to operate: once a proxy becomes a target, it stops measuring what it was chosen to represent.

    An organisation that rewards teams for AI-attributed output volume will reliably get more output volume. Whether it gets more value is a separate question that the metric has been structurally designed not to answer.

    The reasonable position

    Both confident narratives — that AI is transforming white-collar productivity, and that it is delivering nothing — currently outrun the available evidence. Task-level gains are well documented. Firm-level gains are harder to detect, for reasons that are understood and that have precedent.

    The organisations that will know the answer first are those that built measurement into deployment rather than attempting to reconstruct it afterwards from usage logs.

    Related reading

    For a comparable case of cost assumptions outrunning evidence, see why some companies are moving workloads out of the cloud.

    This article is general information and journalism. See our Editorial Policy.