Cloud Vendor Lock-In: Building an Exit Plan Before You Need One

Cloud vendor lock-in happens when leaving a provider costs more than staying, even after the service stops fitting your needs. It rarely comes from one bad decision. It builds up through dozens of small ones: a managed database in a proprietary format, serverless functions written against a single provider's API, message queues with no equivalent outside that platform, and then an egress bill that reaches about $0.09 per GB at some large global providers. The answer is not avoiding the cloud. The answer is building an exit plan on day one, resting on four pillars: standard, portable technology such as Docker, PostgreSQL and the S3 API, backups in open formats that you hold outside the provider's account, a real annual migration test rather than a paper exercise, and contract clauses that guarantee your right to your data along with enough time to collect it. A company following these pillars can move a mid-size ERP in two to five days, while a locked-in company may need three to six months of rewriting. This article covers where lock-in hides, how to write an exit plan you can execute with real commands, and how exit costs compare between a global provider and a local one in Saudi riyals.

Where Lock-In Actually Happens

Lock-in creeps in through three main doors, and the most dangerous ones never show up on the first invoice.

Provider-specific managed services

Any service carrying a brand name unique to one provider is a potential lock-in point, whether it is a proprietary NoSQL database, a search engine with its own API, or an authentication system baked into the platform. Code calling these services is written with the provider's own libraries, so leaving means rewriting a whole layer of the application, not just moving data. In a typical ERP, code tied to a single provider's APIs can reach 20% to 30% of the codebase when the team does not watch for it early.

Egress fees

Putting data into the cloud is usually free while taking it out is billed. A company with 10TB of files and backups would pay roughly $900, about 3,375 SAR, just to pull its data once from a provider charging $0.09 per GB, and that is before team hours and downtime. The figure is not huge on its own, but it repeats with every migration test, so it becomes a psychological barrier that stops the team from trying at all.

Closed export formats

Some services export data in a format only the provider can read, or export records without their relations, permissions and logs. You technically own a copy, yet you cannot restore it anywhere else. Ask this before adopting any service: can I restore this export on a plain Linux server with open-source tools within an hour?

Choose Standard, Portable Technology

The working rule is simple. Use a managed service when an open equivalent speaks the same protocol, and avoid it when its API is exclusive. This table summarizes the safe alternatives.

Layer	Locks you in	Portable option
Application	Serverless functions on a proprietary API	Docker containers with docker compose
Database	Provider-owned NoSQL engine	Standard PostgreSQL or MySQL
File storage	Proprietary storage API	Any S3 API compatible store, such as MinIO
Queues	Exclusive messaging service	Redis or RabbitMQ
Infrastructure	Single-provider templates	Terraform or Ansible with documented scripts

Containers are the single most important step, since one docker-compose.yml file describes the whole application and starting it on a new server takes two commands:

git clone git@your-git:company/erp.git && cd erp
docker compose pull && docker compose up -d

For storage, the S3 API has become a de facto standard supported by dozens of systems, and moving an entire bucket between providers takes one rclone command:

rclone sync oldcloud:erp-files newcloud:erp-files --transfers 16 --checksum

The --checksum flag verifies every file, which gives you evidence that the transfer completed instead of a hunch.

Backups: Open Format, Independent Location

A real exit plan starts with backups. A disk snapshot inside the provider's account is useful for quick restores, but it does nothing for an exit because it only works there. Always add a logical backup in an open format stored outside the provider:

# PostgreSQL dump restorable anywhere
pg_dump -Fc -d erp_prod -f /backup/erp_$(date +%F).dump

# MySQL dump including stored routines
mysqldump --single-transaction --routines --triggers erp_prod | gzip > /backup/erp_$(date +%F).sql.gz

Keep at least two copies in two places, with one of them outside your primary provider. On a CLOUD cloud server, for example, you can add daily backups with 7-day retention for 800 SAR a year or 30-day retention for 2,000 SAR, while the logical export you produce yourself stays fully yours in a format that restores on any Linux server.

Test the Migration Every Year

An exit plan that has never been exercised is worth nothing. Once a year, take one day and move a full copy of the system to an independent server at another provider, then measure three numbers: how many hours the move took, how many manual steps you needed that were not documented, and whether the application ran without code changes. A test server the size of the Growth plan (2 vCPU and 4GB RAM) is usually enough to run a trial copy of a mid-size application, and it costs a small fraction of one unplanned outage.

Keep the test checklist in a single file inside the code repository and update it after every run:

1. Export and restore the database, then verify row counts in the 10 most important tables.
2. Sync files with rclone using checksum verification.
3. Start the containers with one docker compose command.
4. Lower the DNS TTL to 300 seconds 48 hours before the move.
5. Run acceptance tests and record the total time.

If the total goes beyond 8 hours, you have lock-in that needs fixing before you are forced to leave under pressure.

Contract Clauses That Protect Your Data

Technology alone is not enough when the contract lets the provider delete your data the moment your subscription ends. Before signing, confirm these clauses:

• Data ownership: an explicit statement that the data belongs to the customer alone, with no usage rights retained by the provider.
• Post-termination access: at least 30 days of continued access after the contract ends or is terminated.
• Delivery format: a commitment to hand over data in open, standard formats.
• Data location: data stays inside Saudi Arabia for the full term and during handover, which matters for National Cybersecurity Authority requirements.
• Documented deletion: a written deletion certificate once you have received and confirmed your data.

Exit Cost: Global Provider vs Local Provider

Take a company running a custom system with a 500GB database and 5TB of files that wants to move to another provider.

Item	Global provider with proprietary services	Local provider with standard technology
Egress for 5.5TB	About 1,850 SAR	Usually within the plan's included transfer
Code rewrite	4 to 12 work weeks	None, the same containers run
Actual migration time	Weeks	2 to 5 days
Data location in transit	May leave the Kingdom	Stays in the Kingdom

A local provider does not protect you from lock-in automatically, but when it offers standard Linux servers with full root access, leaving becomes a business decision rather than an engineering project. At CLOUD, the Business plan (4 vCPU and 8GB RAM) includes 1TB of transfer for 11,500 SAR a year, and each extra terabyte costs 1,150 SAR, so you know your data movement cost in riyals ahead of time. The details are on the pricing page.

Your Exit Plan on One Page

You do not need a 50-page document. Write one page that answers these questions and keep it next to the code:

1. Which provider-specific services do we use, and what is the open alternative for each?
2. Where is the latest logical backup, in what format, and who can access it?
3. How many terabytes would we move, and what would egress cost in riyals?
4. When was the last migration test, and how many hours did it take?
5. Which contract clauses guarantee the collection window and delivery format?

Start this week with one step. List every service your system depends on and mark each one S for standard or P for provider-specific. If you count more than three P marks, your exit plan has become a priority rather than a nice-to-have.