A cloud exit readiness checklist should prove that a stable workload can run on owned or leased capacity with acceptable cost, resilience, and operating effort. Compare full ownership, not just server prices, and do not move until the team can build, monitor, recover, and expand the target environment.
The source gives a sharp example: cloud spend of $20,000 per month compared with $4,500 to $5,000 per month for equivalent compute and storage on dedicated gear, producing stated annual savings of $180,000 to $192,000. That result belongs to the source scenario, not every company. A useful external comparison is the 37signals cloud exit update, where the operator reports actual savings after moving steady workloads. The 37signals cloud exit FAQ adds the less glamorous details: team capability, redundancy, security, and workload fit still matter.
Start with the bill and the workload
Pull 90 days of bills and group spend by service. Separate compute, storage, snapshots, managed databases, load balancing, network address translation, inter-zone traffic, cross-region replication, and egress. Then map those services to the resources the application actually uses.
The first comparison should answer a simple question: is the spend driven by variable demand that benefits from cloud elasticity, or by capacity that runs all day? Stable SaaS workloads, nightly data processing, predictable portals, and internal systems often deserve a second look. A young product with uncertain demand may still be buying valuable flexibility.
Use the existing cloud versus dedicated hardware cost model for the first pass. If the delta is greater than $100,000, the source argues that there is a real decision to investigate. It is not automatic approval to migrate.
Price the system around the servers
The target environment needs more than a hardware list. The source calls for 2 or more solid hosts, NVMe storage, 10G networking, virtualization, backups, monitoring, clear runbooks, and a team able to keep the service running. Spares, racks, power, bandwidth, warranties, remote hands, and replacement lead times belong in the same model.
Physical capacity also has constraints. Our guide to the AI infrastructure bottleneck explains why watts, heat removal, placement, and maintenance shape the economics of owned compute. A low purchase price can hide an expensive facility or an unavailable repair path.
- Capacity: size normal demand, peaks, and expected growth.
- Resilience: define which failures the platform must survive.
- Recovery: prove backups can restore service and data.
- Operations: price build work and steady care.
- Exit risk: identify proprietary dependencies before migration.
Move only after the operating proof
A spreadsheet can show potential margin. It cannot prove that the target system is supportable. Build a representative slice, migrate a bounded workload, observe it under real traffic, and rehearse failure. The acceptance test should cover performance, monitoring, backup restoration, deployment, rollback, and capacity expansion.
The source recommends comparing full 12 month ownership with cloud burn. Keep the same service requirements on both sides. If the cloud design includes geographic redundancy and managed recovery, the target design cannot quietly remove them to win the spreadsheet.
The economics of running AI locally follow the same rule. Avoided rental fees are meaningful only when utilization, maintenance, security, and replacement responsibility are included.
Cloud is a tool, not a moral position. Keep workloads where elasticity, managed services, or speed justify the premium. Move steady capacity when the full operating model supports the margin. A hybrid result can be more rational than a total exit. Workload placement should always follow evidence.
Frequently Asked Questions
Consider it when spend is material, workloads are steady, demand is predictable, and the team can operate a resilient target platform at a lower total cost.
Include hardware or leases, spares, racks, power, bandwidth, warranties, operations, monitoring, backups, migration work, recovery, and future capacity.
No. The target must also meet service, security, performance, deployment, backup, recovery, and growth requirements under realistic operating conditions.
Yes. Stable capacity can move to dedicated infrastructure while bursty demand or managed dependencies remain in the cloud when their flexibility is worth the premium.
If your infrastructure spend needs a fact-based second opinion, use our free website and AI readiness audit to identify the first cost and resilience checks.