Question 1

Is cloud repatriation worth it - or should we optimize first?

Accepted Answer

Optimize first, in most cases: rightsizing, commitments, and killing the named villains (egress, idle capacity) often recover meaningful spend without migration risk. Repatriation earns consideration for stable, well-understood workloads at material spend, run by teams with real infrastructure capability - and the honest model prices the ops staffing you take on.

Question 2

Which workloads make good repatriation candidates?

Accepted Answer

Stable, predictable, well-understood ones - steady compute and large, slow-changing storage. Volatile or fast-evolving workloads keep the cloud's elasticity premium worth paying.

Question 3

What does the repatriation math need to include?

Accepted Answer

Hardware plus its refresh cycle, colocation or facilities, the operations staffing you now own, egress to get data out, and a parallel-run period. If the case only works with those lines at zero, it is not a case.

Is cloud repatriation worth it - or should we optimize first?

The short answer, with operator context.

Outcomes that inform this answer.

What to ask next.

Which workloads make good repatriation candidates?

What does the repatriation math need to include?

Where to go next.

Turn the answer into an operating plan

Which workloads make good repatriation candidates?

What does the repatriation math need to include?

How much did 37signals actually save by leaving the cloud - and does that math apply to mid-market companies?

Is it cheaper to build your own software than to keep paying for SaaS?

How do CFOs reduce SaaS spend without cutting tools teams rely on?

Turn the answer into an operating plan