Placement Economics: The Right Answer, Applied Everywhere

Contents11 sections

The most expensive infrastructure decisions I have reviewed were right about the technology. What went wrong was the scope: a conclusion drawn from one workload got applied to the whole portfolio, and it stayed applied for years after it stopped being true of anything but the workload it came from.

"Cloud-first" was a policy. "Repatriate everything" is becoming one. The workload is the unit of decision, and a company running fifty workloads owes itself fifty answers; most of those answers agree with each other, and the few that disagree are where the money is.

The three placements

Owned facilities sit outside this piece. The live question for most technology leaders is cloud against colocation, per workload, with a hybrid answer at the end.

The repatriation evidence, and what it rests on

The best-documented case is 37signals. They were spending roughly $3.2 million a year on cloud. They bought about $700,000 of Dell hardware into colocation racks they already had and reported close to $2 million a year in compute savings, which is about two-thirds of the original bill. They then spent around $1.5 million on 18 petabytes of Pure Storage to replace S3; that storage costs under $200,000 a year to run. Their projection is cumulative savings above $10 million over five years, on faster machines with more capacity, which is the sort of number that settles an argument in a board meeting and starts a different one in the room where somebody has to keep the hardware alive.

Dropbox did the same thing earlier and larger, moving roughly 90 percent of storage off AWS into three colocation facilities, investing over $53 million and estimating about $75 million saved across two years. Pointing the other way, GEICO's platform engineering leadership described a decade-long cloud journey in which they still had not moved everything, the bills had risen around 2.5 times, and reliability had got worse rather than better.

An Andreessen Horowitz survey found that among companies spending over $2 million a year on cloud, a large majority had repatriated at least one workload, and cost was the dominant reason given. Read the sentence again. A majority moved at least one workload, which is a very different finding from a majority leaving, and it is the finding that matches what the rubric below produces: a split rather than a direction.

Now the conditions, because the numbers above travel without them. 37signals is a mature and profitable company with steady traffic, an exceptionally capable operations team, and colocation relationships already in place. Growth uncertainty, which is what usually kills an owning case, is close to zero there. That combination is rare. They were also running expensive managed services, Aurora and OpenSearch among them, and a disproportionate share of the savings came from leaving those behind (their CTO has said so publicly). The published figures also do not carry the full cost of future hardware refreshes or the operations roles needed to sustain the estate.

None of that makes the case invalid. It makes the case conditional, and the conditions are the whole point.

A scoring rubric

The rubric below scores one workload at a time. Higher totals point toward owning and lower totals point toward cloud. It structures the conversation rather than settling it, and the first question it forces is the useful one: which of the fifty workloads is this decision actually about?

A total of 0 to 6 is a cloud workload and there is not much to argue about. A total of 7 to 13 is hybrid territory, where the answer sits in the specific line items rather than in the score. A total of 14 to 20 is a colocation case worth building properly.

Here is the pattern that shows up most often. A company scores 3 on its customer-facing tier and 16 on its storage and analytics tier — one instrument, two answers — and then makes a single decision covering both. The savings live almost entirely in the second group, and so does the operational burden. Splitting the two is usually right and is almost never what gets proposed first, because a split is more work than a policy.

Five-year cost, including the parts people leave out

The omissions, in rough order of how often they turn up missing:

1. Exit cost hides in four places: egress charges, data gravity, dual running, and rewriting whatever was built against a proprietary service. No migration case I have reviewed has ever overstated it.
2. Hardware refresh belongs in any five-year model that sits on a four-year refresh policy, because that model needs a second purchase in it. Part 4 is about why those two numbers have to agree.
3. The headcount delta is real, since colocation has people in it. Hardware lifecycle and capacity planning are roles with salaries attached.
4. Support plan percentages scale with the thing they support. Cloud enterprise support is often priced as a share of spend, so it grows exactly when the bill does.
5. Commitment mismatch cuts both ways. Reserved capacity you never use is waste; usage above the commitment is priced at a premium. A model has to carry both tails.
6. The cost of being wrong is the line nobody writes down. If demand triples, what does each option cost, and what does it cost if demand halves instead?

Commitments are liabilities in a costume

Reserved Instances, Savings Plans and enterprise agreements all land on the profit and loss statement as operating expense. In substance they are multi-year contractual obligations, often with take-or-pay terms, which means you pay the committed amount whether or not you consume it.

A three-year commit signed against an optimistic forecast is a debt-shaped obligation that nobody on the technology side is thinking about as debt. When growth comes in under plan, the organization pays for capacity it never used, and the FinOps dashboard reports that as waste rather than as a commercial decision somebody made in a planning cycle two years earlier.

Flexera's 2026 report put self-estimated wasted infrastructure and platform spend at 29 percent, the first increase in five years, and attributed it largely to AI workloads making forecasting and rightsizing harder. That figure comes from a population where 63 percent run formal FinOps teams and 71 percent run a cloud centre of excellence. The discipline matured and the waste still went up. The workloads got harder to predict faster than the practice got better at predicting them.

Hybrid is the destination

Most organizations that run this analysis honestly land in the same shape: cloud for the variable and globally distributed workloads, colocation for the steady and data-heavy ones, and a deliberate policy about what is allowed to depend on a proprietary managed service. The shape is stable across industries because it follows the shape of the workloads rather than the shape of anybody's strategy deck.

That last clause is the one to settle early. Portability is a design decision, and it gets made long before anyone needs it. A managed database is a good trade in year one and a lock-in cost in year five; taking that trade is fine, and taking it without pricing it is the mistake.

What I actually do

1. Refuse to make one decision for the whole portfolio. The deliverable is a scored list of workloads and a proposed split rather than a direction.
2. Build the five-year model with exit cost in it, in both directions, and present the break-even year rather than the total. A total invites a debate about assumptions; a break-even year invites a decision.
3. Put a portability policy into the architecture standards, naming which managed services are approved and what the escape plan is for each one (an escape plan nobody has costed is a wish).
4. Treat every multi-year commitment as debt inside the planning process. Who signed it, against what forecast, and what the downside costs.
5. Tag everything from the first day. None of this analysis is possible without knowing what runs where and for whom, and the same tags are what make the cost-of-revenue split in Part 2 possible.
6. Ask a provider for migration funding before committing to a direction, then ignore that money when choosing the architecture. Part 7 covers why those two have to stay separate.
7. Put the whole question back on the table once a year. The right call in 2023 is not automatically the right call now, in either direction.

Glossary

References

• DataCenterDynamics, coverage of the 37signals cloud repatriation, 2023 to 2025
• The New Stack, "Why Companies Are Ditching the Cloud: The Rise of Cloud Repatriation", carrying the GEICO commentary
• Andreessen Horowitz, cloud cost research and repatriation survey data
• Flexera, 2026 State of the Cloud Report
• Dropbox infrastructure migration disclosures and engineering blog

Best next read

Part 6, Lift-and-Shift against Re-Architect. You have decided where a workload should live. Part 6 is about how it moves, and why the cheap migration is so often the expensive one.

The full series

This series is an introduction for technology leaders. It is accounting and tax context rather than accounting or tax advice. Treatment is fact-specific. Model it with your CFO and auditor before you commit.