A finance director opens the cloud bill a year after the migration and finds it higher than the data center it replaced. The cloud simply does what it was asked to do.
That is the most common enterprise cloud story, and it is avoidable. The cloud pays off when a company treats it as a way of running IT, with costs, security and an exit planned from the first day.
What is enterprise cloud?
An enterprise cloud is the way a large organization runs its applications and data on cloud infrastructure: one or more public clouds, often a private cloud or its own data centers, and a common set of rules for security, cost and compliance across all of them. In short:
- Public cloud: rented infrastructure and services from providers such as AWS, Microsoft Azure and Google Cloud, paid for as used.
- Private cloud: cloud-style infrastructure run for one organization, in its own data center or hosted, usually for data that must stay under tighter control.
- Hybrid cloud: public and private together, with workloads placed where they fit best.
- Multi-cloud: services from more than one public provider, chosen on purpose or inherited through acquisitions and team choices.
- The enterprise part: central identity and access control, cost ownership, security policies and compliance that apply whichever cloud a workload runs on.
The last point is what separates an enterprise cloud from a collection of cloud accounts. Without it, every team builds its own small data center in someone else's building. The applications that run there, from ERP to CRM, are covered in our guide to enterprise software.
Enterprise cloud benefits
The benefits are real, with a condition attached to each of them:
- Pay for what you use. Capacity becomes an operating cost instead of a hardware purchase, as long as someone switches off what is no longer used.
- Scale on demand. Capacity for a peak can be added in minutes and removed afterwards, if the application is designed to scale out.
- Faster delivery. Teams get environments, databases and managed services without waiting for hardware. Capital One cut the time to build an average development environment from three months to minutes.
- Resilience and disaster recovery. Several data centers and regions are a configuration choice rather than a construction project.
- Security tooling. Encryption, identity management and monitoring come built in, but configuring them correctly stays the customer's job.
- Access to managed services. AI, analytics and data platforms are available on demand, without building and running them yourself.
Enterprise cloud in 2026: the numbers
The market is growing faster than at any point in the past eight years. In the second quarter of 2026, spending on cloud infrastructure services reached $143 billion, up 43% from a year earlier, according to Synergy Research Group. Synergy credits generative AI as the main driver.
Three other numbers matter more for an enterprise planning its own cloud:
- 73% of organizations run hybrid environments, and multi-cloud keeps growing, often through mergers, SaaS sprawl and team decisions rather than design (Flexera 2026 State of the Cloud, a survey by a vendor of cost management tools).
- In the same survey, respondents estimate that 29% of their IaaS and PaaS spend is wasted, the first increase in five years, driven by AI workloads.
- From 12 January 2027, the EU Data Act removes switching charges, including data egress fees, for customers who move between cloud providers (European Commission). Leaving a provider is about to get cheaper in Europe.
Enterprise cloud examples: four companies, four lessons
Definitions only go so far. These four stories show what an enterprise cloud looks like in practice, including one company that decided the cloud was not for it.
Capital One: a bank that closed its data centers
Capital One became the first US bank to announce it had gone all in on the cloud, exiting eight on-premises data centers and moving to AWS (AWS case study).
What did the bank get for it? Speed, above all. The average time to build a development environment fell from three months to minutes. For a regulated bank, the lesson is that the cloud can meet strict security and compliance demands, but only with the engineering and governance work done first.
Netflix: rebuild, don't forklift
Netflix started its move in August 2008, after a database corruption stopped it from shipping DVDs for three days. It finished in January 2016, after seven years of work (Netflix).
The interesting part is what Netflix chose not to do. Its engineers wrote that the easiest way to move is to "forklift all of the systems, unchanged", but that "you end up moving all the problems and limitations of the data center along with it". Netflix rebuilt its technology as hundreds of microservices instead. Cost was not the goal, yet its cloud cost per streaming start ended up a fraction of the data center's, and availability improved.
37signals: when leaving the cloud is the right call
Not every story runs in one direction. 37signals, the company behind Basecamp and HEY, moved its applications off AWS onto its own hardware in 2023, without hiring new staff, and expects to save about $10 million over five years, cutting its infrastructure costs by between half and two-thirds (37signals).
The lesson is not that the cloud is a mistake. 37signals runs a few stable, predictable applications with a team that knows how to operate hardware, which is close to the worst case for pay-as-you-go pricing. A business whose load swings, or which needs a dozen managed services, does the math very differently. Do the math for your own workloads.
FastPost: a high-volume finance platform built for the cloud
FastPost, the accounting platform we developed for Legerity, was designed for the cloud from the start: an in-memory engine and open-source components, deployed in a modular way. It processes a billion financial transactions in under an hour in the cloud (case study).
Running in the cloud shortened implementations for new customers, kept running costs down and let the platform scale with the telcos and insurers using it. The design came first; the cloud then made the most of it.
Enterprise cloud best practices
The practices below come from projects that went well and from the ones we were called in to rescue. They follow the order in which the decisions depend on each other.
1. Decide per workload, not for the whole company
A company does not move to the cloud; its applications do, one at a time, and each deserves its own answer. AWS describes seven strategies, the 7 Rs, ranging from switching an application off to rebuilding it for the cloud.
Retiring is the cheapest strategy and the most overlooked. Almost every portfolio has applications nobody needs, and moving them costs money twice: once to migrate, then every month to run.
2. Build the cost model before the move
Compare the costs over three years, not one month: compute and storage, data transfer, support plans, licenses, the team that runs it, and the savings you expect from the data center. Measure how much the workload actually uses before choosing instance sizes. A cost model written down before the migration is also the yardstick for checking whether it paid off.
3. Run FinOps from the first day
If 29% of spend is wasted on average, the fix is organizational more than technical. Tag every resource with an owner and a cost center, give each team a budget and a dashboard, and review the bill monthly with the people who can change it. Reserved capacity and savings plans pay off for steady load, while idle environments should switch off at night.
4. Know where your security responsibility starts
AWS describes the split as security "of" the cloud, which is the provider's job, and security "in" the cloud, which is the customer's (shared responsibility model). Identity and access management, data encryption settings, network rules and patching of what you run all stay with you.
5. Plan the exit on day one
An exit plan is not pessimism. It strengthens your hand in every negotiation with the provider. Keep data in formats you can move, prefer open standards and portable runtimes where they cost little, and write down how you would leave each provider. In Europe this is becoming easier and, for some, mandatory: the Data Act removes switching charges from January 2027, and financial entities under DORA have to manage their ICT third-party risk, cloud providers included, since January 2025.
6. Fix the bottleneck before you scale it
The cloud scales what you give it, including a slow design. An application that waits on one overloaded database will wait on it in the cloud too, only on a more expensive machine.
When we rebuilt a UK hotel metasearch engine around an in-memory data grid, the architecture change, not the hosting, cut infrastructure cost by 80% while traffic grew 50% (case study). Our article on legacy software systems covers how to decide what to fix before a move, and how Java enables high performance what a current runtime adds.
7. Migrate in phases, with a rollback plan
Move one scoped part at a time, rehearse the data migration, agree acceptance criteria in advance and keep the old environment ready until the new one has proved itself under real traffic. A cutover that cannot be reversed is a bet, and enterprises have better uses for their luck.
Enterprise cloud readiness checklist
Before signing a cloud contract or approving a migration budget, check that you can answer yes to these:
- We have an inventory of applications, with an owner and a 7 Rs decision for each.
- We have a three-year cost model per workload, based on measured usage.
- Every cloud resource will carry an owner and a cost center from day one.
- We know which security controls are ours under the shared responsibility model, and who runs them.
- Data residency and regulatory requirements (GDPR, DORA, sector rules) are mapped per workload.
- There is a written exit plan for each provider.
- Known performance bottlenecks are fixed, or scheduled, before the move.
- Each migration phase has acceptance criteria and a rollback plan.
If your core systems run on Java and the plan is to move them, our cloud migration team starts by measuring the workload and modeling three years of operating costs, so you see the numbers and the cutover plan before the move begins.