Cloud repatriation: price the operating model you will inherit

37signals’ cloud exit is interesting partly because of what the company already owned. In an October 2024 account, co-owner and CTO David Heinemeier Hansson reported that its annual cloud bill had fallen from a $3.2 million run rate to $1.3 million after moving seven applications out of AWS. The new Dell hardware cost about $700,000, he wrote, and fitted within existing data-centre racks and power limits. Long-term commitments also delayed the clean year of savings.

These are the company’s reported figures, with its own starting conditions. For an infrastructure director considering repatriation, the most useful question is whether those conditions resemble yours. Available rack capacity, an established operations team and predictable demand can change the economics as much as the server quotation.

Repatriation can mean bringing a workload onto owned hardware in a colocation facility, an internal data centre or another hosted arrangement. Define the destination precisely. Each assigns different work and commercial exposure to your organisation.

Compare the service you intend to run

Choose one workload and a common planning horizon. State its demand profile, data growth, support hours, recovery requirements and dependencies. Compare staying, improving the current cloud deployment and moving. An unoptimised cloud bill is a weak baseline for a carefully engineered destination.

The destination needs enough capacity for the service commitment. Average utilisation cannot determine how much equipment is needed during a host failure, maintenance window or seasonal peak. Include the spare capacity that makes those events manageable, and identify whether it can serve other work when unused.

Then follow the responsibilities. Who patches the database, tests backups, monitors capacity, replaces failed components and answers the overnight call? A managed cloud service may bundle work that a hardware quote omits. Conversely, your team may already perform much of the application and database administration in either model. Price the actual difference rather than assuming all cloud operation disappears or all destination staffing is new.

Obtain current quotations for the chosen capacity and service level, including networking, facilities, licences, support and refresh requirements. An existing shared team or rack is not automatically free: using its spare capacity can displace another project or bring forward an expansion. Show the incremental cash requirement and the resource consumed so finance can understand both.

A cheaper steady state can still be a poor move

Consider this hypothetical three-year cash comparison. Demand and service requirements are held constant. The figures include the relevant operating costs for the defined workload; they are not supplier prices. The simplified model excludes tax, financing, discounting and residual value.

Cash cost	Improve and stay in cloud	Move to owned hardware
Three years of recurring operation	£180,000 × 3 = £540,000	£100,000 × 3 = £300,000
Hardware and initial setup	£0	£120,000
Migration, validation and overlap	£0	£60,000
Total over three years	£540,000	£480,000

The move saves £60,000 across the horizon, although its recurring cost is £80,000 lower each year. The £180,000 initial outlay absorbs most of that operating advantage. If an additional £25,000 a year is needed for support and facilities, the destination total rises to £555,000, making it £15,000 more expensive than staying.

That sensitivity is the decision. The hardware can be competitively priced while the full proposal remains fragile. Resolve the support and facilities assumptions before presenting the recurring saving as a dependable budget reduction.

Keep cash flow separate from the accounting view. Paying for hardware and recognising its cost over its useful life answer different questions. Include whichever view the investment process requires, but do not add both the full purchase payment and depreciation to the same cash total. Likewise, a migration already included in the transition allowance must not appear again as a separate saving penalty.

Find the date when the old cost actually ends

The migration date and the savings date may differ. An unused cloud commitment can continue after the application moves, while the destination starts generating bills before cutover. Include dual operation, data transfer, testing, decommissioning and any contractual amounts that remain payable. Retiring the last workload may be necessary before a shared service can be removed.

Hansson’s account is a useful reminder that moving applications did not immediately end every cloud commitment. Treat the timing in your own contracts as part of the migration sequence. Do not count a bill as eliminated merely because the new platform no longer needs the resource.

Test demand in both directions. Growth may require another capacity purchase sooner than expected; contraction may leave equipment underused. Cloud elasticity also has limits and costs, but the ability to stop consuming a service can have value when demand is genuinely uncertain. Compare those options against the same scenarios.

Before committing to the wider move, operate a representative slice on the proposed destination. Include a maintenance event and a recovery exercise, with the people who will support it after the project ends. The result should show whether the assumed operating effort is credible and which remaining dependencies keep the cloud service necessary.

Proceed when the service can be run at the required standard and the economics survive the uncertainties that matter. Build the next comparison using a consistent cost boundary for hybrid infrastructure, so the choice reflects the whole service rather than the most attractive line on either bill.