Read the Exit Before You Sign the Entrance: A Field Test for Cloud Lock-In

Somewhere in America tonight, an on-call engineer is awake at 2 a.m. running a migration nobody budgeted for. The database dump is taking longer than the documentation promised. The config files don't map to anything standard. The support docs for exporting data read like they were written by someone who hopes you never succeed.

That engineer is doing the work your organization deferred the day the contract was signed. And the lesson they're learning is one every founder and engineering lead should internalize before the next renewal: the true cost of a hosting platform is revealed at the exit, not the entrance.

Lock-In Rarely Announces Itself

No vendor markets lock-in as a feature. Instead, it accumulates quietly, one convenience at a time. A managed service here, a proprietary CLI there, a configuration format that's almost YAML but not quite. Each decision is defensible in isolation. Together, they form a moat — with your workloads on the inside.

The warning signs are consistent across providers:

• Proprietary APIs as the primary interface. If every automation script depends on vendor-specific endpoints rather than open standards, every integration becomes a rewrite on the way out.
• Nonstandard configuration files. Custom formats force your team to learn a dialect nobody else speaks — and to translate everything when you leave.
• Egress pricing that punishes departure. When moving your own data out costs multiples of what moving it in cost, the exit door has a toll booth.
• Migration documentation as an afterthought. If the docs for leaving are thin, vague, or buried, that thinness is a business strategy, not an oversight.

None of these are disqualifying on their own. Managed services deliver real value, and paying a premium for convenience is a legitimate choice. The failure mode is choosing lock-in unknowingly — signing a multi-year commitment without pricing the exit.

The 2 A.M. Test

Here's a thought exercise worth running before any renewal: imagine your platform vendor doubles prices next quarter, or gets acquired, or simply stops innovating on the features you depend on. How long does it take your team to move?

If the honest answer is "weeks," you have portability. If it's "quarters, and we'd need a consultant," you've rented your infrastructure rather than owned it. The distinction matters enormously for negotiating leverage, resilience to vendor surprises, and — not least — for the wellbeing of whoever draws the on-call rotation during the eventual move.

At GlobalWeb Cloud, we think the healthiest customer-vendor relationships are the ones where staying is a choice renewed daily, not a trap sprung annually. Portability isn't hostility toward your provider; it's insurance for both sides.

A Portable-Architecture Checklist

Hand this to your engineering team before the next annual contract gets anywhere near a signature:

1. Data egress, priced and rehearsed. Know the exact cost and time to export a full copy of production data. If you've never done a dry-run export, schedule one. A backup you've never tested is a rumor; so is an exit plan.

2. Standards-first interfaces. Prefer platforms that expose PostgreSQL-compatible endpoints, standard Kubernetes manifests, OpenTelemetry instrumentation, and Terraform modules over proprietary equivalents. Where proprietary services are used, document the abstraction layer that would replace them.

3. Configuration as portable code. Infrastructure definitions should live in version control in formats other vendors can consume. If your deployment process only works through one vendor's dashboard or CLI, that's a dependency, not a workflow.

4. Containerized workloads. Applications packaged in standard containers with declared dependencies move. Applications welded to a vendor's runtime image don't.

5. DNS and edge independence. Keep domain registration and DNS with a neutral provider. It's the cheapest portability win available and the one teams most often overlook.

6. An exit runbook, written while calm. One page. What moves first, what moves last, who owns each step, and what the rollback plan is. Writing it takes an afternoon; not having it costs a quarter.

Staying Should Be a Decision

The best hosting relationships in the US market — from startup-friendly providers to the hyperscalers — share one trait: they earn retention through performance and service rather than engineering friction. When evaluating your next platform, ignore the dashboard screenshots and the pricing tables for an hour. Ask instead what your on-call engineer would say if the migration started tonight.

If the answer is a shrug and a checklist, sign with confidence. If it's a groan, price the groan into the contract — or keep shopping.