Kefiw

Archived noindex page. Kefiw's public focus is Property decision help.

Archived page

This older Kefiw page is kept for reference, marked noindex, and removed from the primary sitemap. The current Kefiw experience is focused on property decisions: cost, quotes, damage, buying, selling, owning, and packets.

Go to Property

Six Cloud Exit Mistakes

The errors that make self-hosting look cheaper than it turns out to be — and one that makes cloud look cheaper than it is.

Self-host math is right in theory and wrong in the first three months. Here's what gets missed.

Cloud Exit math looks compelling at first glance — and then someone underestimates maintenance hours by 4× and the whole project is in the red by month 6. The six errors below consistently distort the comparison.

Quick answer

Self-host math is right in theory and wrong in the first three months. Here's what gets missed.

What you are trying to do
The errors that make self-hosting look cheaper than it turns out to be — and one that makes cloud look cheaper than it is.
Best next step
The Cloud Exit
Limit to remember
Treat this as a practical aid for the task, not a replacement for professional judgment.

Key points

  • ▸ Underestimating maintenance hours. Self-host requires patching, monitoring, backups, incident response. Realistic minimum is 8-15 hrs/mo for a small production stack, not 2-4.
  • ▸ Forgetting network gear. Switches, routers, cabling, and a backup uplink are not in the "rack" price. Budget $1-3k extra.
  • ▸ Missing backup costs. Off-site backup and retention storage cost real money — either another cloud bucket or more self-host hardware. Add it to the self-host side.
  • ▸ Ignoring downtime impact. If the business loses $X per hour of downtime, add (expected hours × $X) to the self-host side. Cloud five-nines is already priced in.
  • ▸ Skipping the migration cost. Moving off cloud is an engineering project: data transfer (paid egress), application changes, cutover planning. 80-300 hours at loaded rate is typical.
  • ▸ Overpricing cloud by ignoring optimizations. Before comparing, right-size instances, reserved instances, and spot usage. Cloud often loses a straw-man version of itself — fix cloud first, then compare.

Examples

  • The maintenance-hours miss
    Planned 4 hrs/mo. Actual 14 hrs/mo after patch Tuesdays, failed drives, and one incident. At $120/hr loaded, that is $1,200/mo more than modeled.
  • The migration-cost miss
    200-hour migration at $100/hr = $20,000 upfront. Amortized over 24-month hardware life = $833/mo. Crossover slides from month 5 to month 10.
  • The un-optimized cloud
    Cloud bill modeled at $2k/mo. After right-sizing and RIs: $1,200/mo. Self-host comparison changes entirely — and may no longer pencil out.

When to use which tool

Related

Frequently asked questions

› Can we do a partial exit? Trust & accuracy

Yes — most sensible real-world outcomes are hybrid. Move predictable steady workloads off cloud and keep elastic or managed services (databases, queues) on cloud.

› What's a realistic all-in per-server-month cost for self-host?

Including amortized hardware, electricity, cooling, network gear, and maintenance labor: $80-200/server/month for modest stacks. Use this as a sanity check against the calculator output.

› How should I use a decision framework in real life? How-to

Use a decision framework to expose the tradeoff, not to outsource the decision. Write down the inputs, compare the output with your constraints, then ask what would change the answer. The strongest use is scenario testing: base case, conservative case, and failure case.

› Is this financial, legal, or tax advice? Trust & accuracy

No, this is not legal, financial, tax, medical, or professional advice unless the page explicitly says that use case is supported. It organizes assumptions so you can inspect them. Verify high-stakes choices with qualified people who can review facts, contracts, regulations, and downside risk.

› What assumption matters most in a decision model? Edge case

The most important assumption is usually the one you are least certain about and most emotionally attached to. Change that input first. If the recommendation flips after a small change, the decision is fragile and needs more evidence before you treat the model as useful.