Why Organizations That Migrate to the Cloud End Up Saving Less Than Projected

When a cloud migration budget goes up for board approval, the question most executives ask is how much the first year will save compared to the existing on-premises setup. The question almost nobody asks in that room is how much higher the month-13 bill will be than what was projected — and who will notice before that gap becomes a real problem. This article is written from the perspective of the team that has to own the cloud bill for years after the migration is done, not the perspective of the people who close out the migration project and walk out of the room.

The savings projected at approval time, versus the real bill after month 12

Most organizations decide to migrate to the cloud based on a cost comparison built in advance — server lease costs against on-demand instance pricing — and conclude it will clearly be cheaper. The problem is that comparison is usually calculated from the usage pattern designed during planning, not the actual usage after individual teams start spinning up resources on their own to meet immediate needs.

The Flexera 2026 State of the Cloud Report, which surveyed 753 cloud decision-makers worldwide and was published on March 18, 2026, found that 29% of cloud spend on average is wasted — spend that generates no value. This figure rose for the first time in five years, and Flexera attributes the increase to surging cloud-based AI workloads (source: Flexera 2026 State of the Cloud Report). This is a global figure — it is not specific to Thai organizations or to Superdev. What it does show clearly is that the gap between the planned number and the actual number is a problem affecting a large number of organizations, not a mistake made by any one team.

What this aggregate number does not tell you is the cause inside your own organization — and that is where many organizations get it wrong. Many teams conclude that the runaway cost comes from genuine user growth, treat it as an unavoidable cost, and let it go unexamined. In many cases, though, the real driver is resources that were provisioned and never actually used from the start.

Costs that appear quietly after the migration is finished

During the migration project itself, everyone is focused on finishing the move and getting the system working. Tuning for cost efficiency usually gets pushed to "later." The problem is that later rarely arrives, because the team that finished the migration moves on to the next project, leaving behind cost settings that were sized generously "just in case."

A pattern that keeps recurring: instances sized large during testing that nobody ever scales down after go-live; old disks or snapshots left over from multiple rounds of migration testing; and add-on services switched on during the data move and simply forgotten. Individually, none of these look like much. Accumulated across months, they become a cost block that stays invisible until someone actually goes line by line through the bill.

An equally common pattern is a standby database replica set up for a zero-downtime cutover that nobody ever downsizes or shuts down afterward, because the team is afraid they might need it again if something goes wrong later. That fear is reasonable in the short term — but without a clear decision date for when to shut it down, the standby resource quietly becomes a permanent cost that nobody intended.

Another common driver, in organizations that buy a Reserved Instance or Savings Plan up front to lock in a discount: the size purchased is usually based on the numbers estimated during migration planning, not the size actually used after cutover. When the team later finds real usage is smaller than what was reserved, the difference becomes money already spent without being fully used — and a one-to-three-year commitment makes that far harder to correct than an ordinary on-demand cost. The caution here: don't lock in a long-term commitment before the system has run in real production conditions for at least one to two months, so you can see the true size before committing to a price.

Resources nobody owns

The problem underneath the numbers is a structural one: accountability. In organizations where multiple teams share the same cloud account, resources created during migration often go untagged — no record of who owns them, which project they serve, or when they should be shut down. When it comes time to review the bill, nobody dares to shut down a resource they can't confirm is unused, for fear of accidentally taking down something important. The result is that ownerless resources tend to get left alone indefinitely rather than reviewed.

This traces back to the TOR or contract drawn up at the start of the project. If the architecture documentation and cloud account access were assigned clear owners from the outset — as we've written about in TOR conditions that keep a system maintainable — tracking down resource owners after migration becomes far easier, because who is responsible for what was already recorded from the start. Organizations that skip this step during migration planning usually end up chasing down each team individually afterward, which takes far longer than defining it up front ever would.

The annual maintenance contract signed after migration is another point where cost accountability should be tied in, because the scope defining who manages resource sizing and who has authority to approve additional spend should be written into the contract negotiation itself — not left as a verbal understanding between the internal IT team and the external system administrator. We've written in detail about what to check in a maintenance contract before signing in Before signing an annual maintenance contract, here's what to check so you don't get left stranded.

Legacy systems with connections everywhere: costs that never appear on the quote

Mid-size to large organizations with long-running legacy systems usually have more integrations with other systems than the migration planning team realizes at the start of the project — an accounting system pulling data from a sales system, a reporting system querying the old database directly, or an overnight batch job pulling files from another machine. These connection points are typically never counted into the migration plan from the beginning, because no one on the team has full visibility into the legacy system as a whole.

The consequence is that during cutover, a temporary connection channel between the old and new systems has to stay open, usually relying on a VPN or a dedicated connection with a monthly cost — and often that "temporary" channel becomes permanent because nobody planned a shutdown date for it from the start. For organizations that need to keep working with government systems or external partners who aren't ready to migrate on the same timeline, this kind of connection point may need to stay in place far longer than originally estimated, and should be counted as a permanent cost of the new system, not a temporary cost of the transition.

The cost of running in parallel during the transition

Risk-conscious organizations often choose to run the old and new systems in parallel for a period before fully cutting over the legacy system — a sound approach from a safety standpoint, but one with a cost that usually isn't budgeted for in the migration plan from the start. Running in parallel means paying for the old server lease, the new cloud spend, and the labor cost of a team watching both systems simultaneously, every day.

A question that should be answered clearly from the start: how long should this parallel-run period last, and what are the actual conditions for cutting the legacy system loose for good? Without clear conditions, a parallel-run period meant to last only a few weeks can stretch into months with nobody making the call, because nobody wants to be the one who orders the old system shut down without a criteria to point to. Organizations experienced with this usually set error-rate or data-discrepancy thresholds in advance, so the decision to cut over is backed by evidence — not a feeling that things are "probably ready."

Data egress: still a real risk, or a problem that's already been resolved

The cost of transferring data out of the cloud (egress) used to be the main reason organizations worried about getting locked into a single provider. That situation has changed considerably since 2024. AWS and Azure now both make the first 100 GB of internet egress free every month (source: Azure Bandwidth Pricing and the AWS announcement below, checked September 29, 2026), and there are additional egress-waiver programs for organizations migrating out entirely — AWS announced this policy on March 5, 2024, processed through an AWS Support request (source: AWS News Blog), and Google Cloud has an Exit Notice process with a minimum 30-day migration window, per the page last updated September 11, 2025 (source: Google Cloud Exit).

The caveat: these terms are tied to a full exit and require filing a request in advance — they are not an automatic discount that applies to every case. Organizations that need to move data partially during normal operations — periodically sending data to another data center, for example — still pay the standard rate, which scales with volume and origin region. What's worth doing at the migration-planning stage is assessing what pattern of outbound data transfer your system actually has: is it a one-time move on the way out of the cloud, or a recurring monthly transfer out? Because these two patterns fall under entirely different terms.

This is a discipline problem, not a technical one.

What needs to be in place before you migrate — not after the second big bill

Organizations that genuinely keep cloud costs under control long-term usually aren't using any special tooling. What they have is basic discipline that starts on day one of the migration. A policy of tagging every resource with the owning team's name and its intended expiration date is the place to start, because it's the one piece of information that tells you who has the authority to decide when to shut that resource down.

Next is a monthly bill review with a clearly assigned owner — not just an automated alert system that sends an email nobody opens. A review cycle that actually works needs one person specifically assigned to go through the list of abnormally high-spend resources every month, with the authority to question resource owners directly. Last is role-based access to cloud accounts, so you know who created what resource and when, instead of having to chase that down after a problem has already occurred.

None of these three disciplines can be added faster than writing them into the migration plan from the start. Bolting them on later, into a system that already has resources scattered across hundreds of items, takes far more effort than setting the rules from the very first resource — because you end up having to trace back and ask, item by item, instead of already knowing the answer from day one.

The metrics worth watching every month, not just the total at the bottom of the bill

The total cloud spend at the bottom of the bill only tells you how much you paid — not what you paid for, or whether it was worth it. A more useful metric is unattributed spend as a share of total spend. If that share stays high across several consecutive months, it means the tagging policy you put in place isn't actually working in practice — not just a documentation gap.

Another useful metric is the month-over-month delta by team or by system, rather than the organization-wide total, because a flat overall number can hide one team whose spend is spiking while another team's spend happens to drop by a matching amount, making the combined total look normal. Reviewing it team by team surfaces the anomaly the aggregate number was hiding, and lets the person actually responsible answer the question precisely instead of having to trace it item by item afterward.

Neither metric requires special tooling — both can be pulled straight from the provider's own existing dashboard. What most organizations are missing isn't the data itself, but a defined cadence for who is responsible for looking at it, and when.

Some organizations go a step further and set a budget cap per team or per project from the start, rather than allowing unlimited spend and reviewing it after the fact. This cap doesn't need to be so strict that it gets in the way of day-to-day work — it should be set at a level where the owning team gets an advance warning as they approach it, before they go over. This shifts finance's role from reviewing the damage after the bill lands, to being aware of the situation alongside the technical team from the start of the month.

The trade-off to say plainly: not every organization needs full cost governance

The trade-off worth saying plainly: setting a tagging policy across every resource, a monthly bill review cycle, and fine-grained access control all take more upfront time than migrating with no rules in place at all. If your system is a small internal setup with a few dozen resources, run by a single team, and monthly cloud spend is low enough to check by eye, building out the full process may not be worth the time it costs. In that case, the recommendation is to start with one piece — the monthly bill review — and add the other disciplines later, as the number of resources and teams involved actually grows.

The objection we hear often: providers already have cost-management tools built in

A common objection: AWS, Azure, and Google Cloud all already have their own cost dashboards — so why does an organization need to build an additional process? It's a reasonable question. The answer isn't that these tools don't work — provider tooling shows billing data in accurate, granular detail. What the tooling can't do for you is decide which resource is still actually needed, and who has the authority to shut it down. A dashboard can tell you how much you spent in each category, but it doesn't know which team owns that resource. Without a tagging policy and a review cycle backed by an actual accountable person, the numbers on the dashboard are just a report that nobody acts on.

Organizations that have already been through a system outage and had to make a failover call tend to grasp this principle quickly, because it's the same principle we wrote about in The DR Plan That Survives the Day: no tooling or alerting system, however good, helps without someone at the other end who has the clear authority to make the call. Cloud cost is exactly the same — an accurate number doesn't help if nobody has the authority to act on it.

Summary

In short: the gap between the savings projected at approval time and the actual bill after go-live usually doesn't come from provider pricing. It comes from resources with no owner and no review cycle. If there's one thing to take away from this article, it's this: put a resource-ownership tagging policy and a monthly bill review cycle in place as part of the migration plan from day one — not as work pushed to later. If your organization is planning a cloud migration and would like a second set of eyes on the cost structure before the project starts, we're happy to talk. There's no deadline attached, and there's no need to rush the decision.

To discuss the details of your project, reach us at 088-983-9386 or by email at [email protected]. Our office is in Bang Kapi, Bangkok. If you're still in the process of evaluating whether a migration is worth it, we're glad to set up a call to understand the problem first — you don't need complete documentation to start that conversation. And if, after talking, we find it isn't yet the right time for you to migrate, we'll say so directly — starting a project at the wrong moment costs more than waiting one more quarter.