Cloud Storage Lock-In: The Walls Between Services Keep Going Up

Last week, Backblaze quietly stopped backing up OneDrive and Dropbox folders on user machines.

If you were using Backblaze as a safety net in case the other cloud services failed, you lost that safety net. Probably without noticing.

The story exploded on Hacker News with 600+ comments. Not because Backblaze did something egregious. Because it revealed something most people don’t think about until it happens to them.

Cloud services aren’t required to play well with other cloud services. Most of them don’t.

The walls are rarely announced

You signed up for cloud storage because it was convenient. You assumed the services you use could talk to each other, or that at minimum, you could back one up with another.

That assumption isn’t always true. And the walls aren’t announced. They show up when:

• Your backup service stops supporting a folder type you depended on
• Your new device can’t import photos from the old service
• Export from Service A arrives in a format Service B doesn’t recognize
• A sync tool you trusted gets blocked from reading shared folders
• The “universal” file manager loses access to a vendor’s API

Each of these is a business decision on someone’s part. Usually you find out about it when something you were counting on stops working.

Why the walls keep going up

Cloud services have incentives to make interoperability harder, not easier. Not always with malicious intent. The incentives just point that direction.

Retention. If your files only work smoothly inside their walls, you’re less likely to leave. Making things work outside their walls means losing retention margin.

Liability. Supporting third-party integrations means supporting complaints, edge cases, and responsibility for failures they didn’t cause. Dropping support simplifies their life.

Feature differentiation. Proprietary formats and APIs let services claim features competitors can’t match. The cost is paid by users who wanted to mix and match.

Cost pressure. Real-time API access to third parties is expensive. When cost-cutting pressure rises, the first thing to go is often the external compatibility that “only” power users use.

None of these incentives require anyone to be a villain. They just pull consistently in the direction of more walls, less interop.

How people discover the walls

The pattern is almost always the same. Someone set up a system that worked. They relied on it. Nothing in the UI told them the foundation was shifting.

Then one day:

• A scheduled backup didn’t run
• An export came out broken
• A share link stopped working
• A folder stopped syncing
• An email arrived announcing support is ending

At that point, the user has already been depending on something that isn’t there anymore. They just didn’t know until they checked.

The Backblaze story is a version of this. Users who’d been backing up their OneDrive folder for years may not discover the change until they need to restore from that backup. That’s the worst possible time to find out.

What to ask before you trust a service

You can’t make a cloud service do what it doesn’t want to do. But you can ask questions before depending on one:

• Does this service support standard file formats (JPEG, PNG, MP4) without modification?
• Will my files export with their original metadata intact?
• Can I verify my backups actually include what I think they include?
• How will the service tell me if compatibility changes?

Services that can answer these clearly are usually worth trusting more than services that can’t.

At Abrio, we’re building with portability as an architectural principle, not a marketing line. Your files export in their original formats, with their metadata intact, any time. No surprise walls. Join our waitlist to be notified when Abrio launches.