Data Gravity Is the Real Lock-In, Not Your Contract

The thing that actually traps you on a platform is not the contract. It is data gravity: the accumulated mass of your data, and everything wired into it, that makes moving slow and scary. You can cancel a contract in a day. You cannot move ten million rows, forty integrations, and every workflow your team has built around a platform in a day. That gap is the lock-in. Vendors know it. They give you an export button and let physics do the rest.

What data gravity actually is

Every day you use a platform, you add mass. Records pile up. Your app writes against its API. Your team learns its quirks. Reports get built on its schema. Other tools authenticate through it. None of this is malicious. It is just accumulation. And the more mass, the harder it is to move, the same way a bigger planet holds more in orbit.

The dangerous part is that gravity grows silently. On day one you could leave a platform in an afternoon. Two years in, leaving is a quarter-long project nobody wants to sponsor. The platform never raised a barrier. You built one, one record and one integration at a time.

Why the export button is not portability

Vendors love pointing at the export button as proof you are not locked in. It is not proof. A CSV dump of your rows is not your system. It has no relationships, no foreign keys, no logic, no attachments, no history. Reconstructing a working system from a flat export is most of the migration cost right there. I go deep on this in why real data export is more than a CSV, because the difference between a dump and a portable export is the difference between a weekend and a quarter.

The other half of gravity is integration. Every tool that talks to your platform through a proprietary API has to be rewired when you leave. That work does not show up in any export. It shows up as weeks of engineering nobody scoped. The contract was never the problem. The wiring was.

How to keep your data light

You fight gravity by keeping mass out of the platform's exclusive orbit. Three habits do most of the work.

Own the data layer. When your database is yours instead of the vendor's managed store, your records have no gravity toward anyone. The app on top can change without moving the data underneath. This is the single biggest lever.

Export continuously, not at the exit. Do not wait until you are leaving to find out the export is broken. Pull a full export on a schedule and confirm you could rebuild from it. A vendor exit fire drill, which I walk through in running a vendor exit fire drill, turns a theoretical escape hatch into a proven one.

Integrate through interfaces you control. Put a thin layer of your own code between your systems and any vendor API, so swapping the vendor means changing one adapter, not forty call sites. This is the same reason multi-cloud is not the same as no lock-in: the trap is the coupling, not the number of providers.

When gravity is fine to accept

Not all data gravity is worth fighting. If a system is cheap, stable, off your critical path, and small, the mass will never get heavy enough to matter. Fighting gravity there is wasted effort. The rule I use: the more central the data and the faster it grows, the more you want to own the layer under it. Peripheral, slow-growing data can live wherever is convenient.

The systems that hold your core records, your customers, your money, your operational history, are the ones where gravity compounds fastest and hurts most on exit. Those are the ones to own from day one. I run my whole portfolio this way, with the heavy data on infrastructure I control through HostSSH, so no single platform ever accumulates enough gravity to hold me. The contract was never going to trap me. I just made sure the mass never did either.