Own Your Data Before the Platform Changes Its Mind

Three times in six years, a platform I depended on changed the rules with little warning. Each time it cost me somewhere between a weekend and a month. Each time I promised myself I'd fix the underlying exposure, and twice I didn't.

Here's what actually happened, what I moved in-house afterwards, and the single test I now apply before depending on anything.

The three surprises

The analytics platform that changed its data model. Historical data didn't migrate cleanly. Four years of comparable numbers became two years of comparable numbers plus an asterisk. Nothing was deleted — it just stopped being usable for the thing I used it for.

The email provider that repriced by a factor of three. Entirely their right. My list was portable, which is the only reason this was a bad week rather than a bad quarter — but the automations, templates and sequences were not portable, and rebuilding those took eleven days.

The host that deprecated the runtime. Eighteen months' notice, which sounds generous until you're doing the migration in month seventeen alongside everything else. This one was my fault for waiting.

What I moved in-house

• The email list itself. Exported weekly, automatically, to storage I control. The provider is now a sending tool rather than the owner of my audience — a distinction that costs nothing until the day it's everything.
• The website. Static files in a git repo. Any host will serve them; switching is an afternoon. This is the single largest reduction in exposure I've made.
• Content sources. Every article exists as a plain text file on my disk before it exists anywhere else. The CMS renders my content; it doesn't hold it.
• Customer records. Exported on a schedule. Payment processing stays with the processor, obviously, but the record of who bought what is mine.

What I deliberately left on platforms

This is the part that gets left out of "own your data" arguments, and it matters: some dependencies are worth it.

• Payment processing. I am not going to do this better than a specialist, and the regulatory surface is enormous. Full dependency, accepted knowingly.
• Video hosting. Bandwidth and transcoding at scale is a real problem I have no interest in solving. The masters are on my disk, which is enough.
• Social platforms. I don't own the audience there and I've stopped pretending otherwise. They're a channel that points at things I do own.
• Transactional email sending. Deliverability is a full-time discipline. Renting it is correct.

The distinction isn't self-hosting versus not. It's whether losing the platform tomorrow costs you a migration or costs you the asset.

A dependency is fine. A dependency you can't leave is a business risk wearing a subscription's clothes.

The exit test

Before depending on any platform, I answer four questions:

1. Can I export everything that matters, in a format something else can read? Not "is there an export button" — I actually run it once during the trial and look at the file.
2. How long would migrating take, honestly? If the answer is more than two weeks, the dependency needs a deliberate decision rather than a default.
3. What's locked in that isn't data? Automations, templates, integrations, URLs. This is where the real cost lives and it's the part exports never cover.
4. If they tripled the price tomorrow, what would I do? If the honest answer is "pay it", I'm not a customer, I'm captured.

Most platforms pass. A few fail badly enough that I've walked away during the trial, which has never once turned out to be the wrong call.

The goal isn't independence — it's optionality. I want every dependency to be one I could leave in a bad week rather than a bad quarter. That's a much lower bar than self-hosting everything, and it's the bar that actually protects you.

The migration drill

Answering the exit-test questions in theory is easy. I now run an actual drill once a year on the two dependencies that would hurt most, because the gap between "there's an export button" and "I can be running elsewhere by Friday" is where the unpleasant surprises live.

The drill is deliberately small:

1. Run the export. Not read about it — run it, download the file, open it.
2. Check what's missing. Every export I've tested has omitted something. Email exports typically give you subscribers and omit automations, templates and segment logic. That omission is the lock-in.
3. Time a partial rebuild. Take one automation or template and rebuild it somewhere else. Multiply by how many you have. That's your real migration cost, and it's usually three to five times the estimate.
4. Write the number down with the date, and compare it next year.

My last drill produced an uncomfortable number for the email provider — about nine days of rebuild work, mostly sequences. That didn't make me switch. It made me simplify the sequences, which took an afternoon and cut the estimate roughly in half. That's the drill working: it converts an invisible risk into a specific piece of work.

Three degrees of dependency

"Own your data" is too blunt to be useful as a rule. What I actually assess is which of three categories a dependency falls into.

Degree one: rented capability. They do something specialised on your behalf and hold nothing you couldn't reconstruct. Payment processing, transcoding, deliverability. Losing them costs you a switching project. This is a healthy dependency and most of mine are here.

Degree two: they hold a copy. They store something of yours, and you also have it. Email lists exported weekly, content that exists as files on your disk first. Losing them costs you a migration, not an asset. Getting things from degree three to degree two is where nearly all the value of this exercise is.

Degree three: they hold the only copy. Followers on a social platform, reviews on a marketplace, anything where the asset only exists inside their system. You cannot fix this by exporting, because the asset isn't the data — it's the relationship their system mediates. The only real mitigation is to treat degree three as a channel that points at something you own, and never as the thing itself.

Most people's anxiety about platform risk is really about degree three, and most of the advice they get is about degree two. That mismatch is why the advice rarely helps.

Questions I get about this

Found an error in this piece? Tell me — corrections get made in the open with a dated note, never a silent edit. The log is public.