Why the second year of a cloud migration matters more than the first

Most cloud migrations are judged on the day the last workload moves. There is a launch note, a thank-you lunch and a slide that says 100%. Then the team that did the move rolls off, the budget line closes, and the organization settles into its new home with the habits it brought from the old one.

We reviewed 26 migrations we took part in between 2021 and 2026, at insurers, freight carriers, clinics, retailers and utilities. The pattern is consistent. Year one is about getting there. Year two decides whether it was worth going. In year two the bill finds its real level, the old data center either closes or lingers, and someone either owns the platform or nobody does.

The bill finds its level

In the first year, spend often comes in below plan. Workloads arrive in waves, new environments are lightly used, and discounts for committed use have just been bought. By months 13 to 24 the picture changes. Every team has learned how easy it is to start a server. Test environments built for the migration are still running. Data that sat on tape now sits in fast storage, because nobody chose otherwise.

23%Average amount by which cloud spend in months 13 to 24 exceeded the business case, across the 26 migrations we reviewed.

None of this is waste in the usual sense. Each decision made sense on the day it was made. The trouble is that nobody revisits them. The organizations that held to their business case did one simple thing: they put a named person in charge of the bill, gave that person a weekly report by team, and gave them the authority to switch things off.

Two estates cost more than one

The second trap is the old estate. A migration plan usually ends with a decommissioning step, and it is the step most often left undone. A reporting server one department still uses. A license that renews by itself. A disaster recovery site kept warm just in case. Each is small. Together they mean the organization pays for two estates long after it meant to pay for one.

In our review, one in three systems scheduled for retirement was still running 18 months after its replacement went live. The most common reason was not technical. Nobody had been given the job of turning it off, and nobody wanted to be the person who did, in case something broke.

“We moved in nine months and spent the next fourteen closing the doors behind us. Nobody budgets for the second part.”

Habits move with you

Teams carry their old ways of working into the new platform. If a release needed a change board and a weekend window before, it often still does, even when the platform can ship a small change safely in minutes. If capacity was bought for the peak in the old data center, it is still sized for the peak in the cloud. The platform has changed. The operating model has not.

Year two is the right time to change this, because by then the team knows the platform well enough to trust it. We look for three habits: releases small enough to roll back, capacity that follows demand, and costs each team can see for itself. Where all three are in place, the savings in the business case usually arrive. Where none are, they almost never do.

Ownership is the real deliverable

The question we ask at the end of every migration is simple: who owns this now? Not who has access, or who is on call, but who decides what the platform should become next year, and who pays for it. In the migrations that went well, the answer was a small internal platform team with its own budget and roadmap. In the ones that struggled, the answer was a shared mailbox.

That is why we plan the handover from the first week, not the last. The people who will run the platform sit in the migration team. They make some of the decisions, and some of the mistakes, while we are still there to help put them right.

What to do in year two

• Name one person accountable for cloud spend, with a weekly report by team and the authority to switch things off.
• Finish decommissioning: list every old system, give each a date and an owner, and publish the list.
• Check every commitment and reserved capacity purchase against what you now actually run.
• Move to small, reversible releases, and retire the change windows the platform no longer needs.
• Fund the platform team as a product, with a budget and a roadmap, not as a cost center that answers tickets.

None of this is glamorous, which is partly why it gets skipped. The first year of a migration buys an organization the chance to work differently. The second year is when it either takes that chance or pays the same costs in a new place.