The default approach to cloud migration is lift and shift. Move what's running on premise to the equivalent cloud service. Sign the contract. Adjust the configurations later. It is the path of least resistance, and it is almost always the wrong starting point.

The reason is structural. The hardware estate sitting in a typical enterprise data centre was provisioned over years, with each individual decision made against the constraints of its moment. By the time it is being migrated, large parts of it are over-provisioned, under-utilised, or doing work that does not need to be done at all. Lift and shift carries every one of those legacy decisions over to the cloud bill.

The cloud bill is built differently from the on-premise model. The cloud bill rewards consumption, line by line, by the hour. Inefficiency that was hidden in a capital expenditure is now visible as a recurring operational cost.

The right question to ask before migration is not how do we move this. It is how much of this do we actually need to move.

What measurement before migration looks like

Three pieces of information change the economics of every migration plan:

  • What you are actually running, per workload. Utilisation profiles, peak load patterns, the headroom that gets consumed once a year versus the headroom that sits idle.
  • How efficiently the current hardware is doing it. Operations per Watt per server, the share of the estate sitting in the bottom efficiency quartile, the consolidation opportunities that show up against measured performance rather than vendor spec sheets.
  • What the workload would look like if the inefficiencies were removed first. A pre-migration consolidation plan typically shrinks the migration footprint significantly, sometimes by more than half.

That last point is the one that changes the cloud bill the most. A migration that ports an over-provisioned estate spends years renegotiating what should have been measured once before the contract was signed.

The standard nobody references enough

The framework for this measurement already exists. The ISO 30134 series of data centre KPIs covers the metrics that matter:

  • PUE: Power Usage Effectiveness (the building's overhead)
  • WUE: Water Usage Effectiveness
  • ERF: Energy Reuse Factor (what is recovered from waste heat)
  • ITEEsv: IT Equipment Energy Efficiency for servers
  • ITEUsv: IT Equipment Utilisation for servers
  • REF: Renewable Energy Factor
  • CUE: Carbon Usage Effectiveness

The first three describe the building. The middle two describe the IT load itself. The last two describe the energy and carbon mix. Most data centre reporting today covers PUE, sometimes WUE, and stops. Migrating a data centre to cloud without reading ITEEsv and ITEUsv is the same mistake on a different stage.

What this means for the hyperscaler case

Hyperscale cloud providers have an obvious commercial interest in customers measuring before they migrate. The cleaner the migration footprint, the cleaner the cloud relationship that follows. The largest of those providers will tell their customers as much, and the more sophisticated of them are now actively recommending pre-migration measurement as a precondition for sensible cloud sizing.

For the buyer, the implication is the same whether they are migrating to AWS, Azure, GCP or a private cloud. Measure first. Migrate the workload that exists, not the inefficiency wrapped around it.

What we contribute

The pre-migration measurement layer is what Interact's dataset provides. Per-configuration grading of the existing estate, identification of the consolidation opportunities, and an evidenced view of what would actually need to land on the other side of the migration. The migration that follows is smaller, faster and cheaper. The cloud bill that follows that is correspondingly smaller.

The cloud is not the answer to data centre efficiency. Measurement before the cloud decision is.