The Data Hostage
Data wrangling is the job
In June I wrote about the memory problem -- personal, concrete, the kind you feel every time a session forgets what you told it yesterday. I built Hopper to handle it, then told you not to use it -- build your own instead. (You're welcome to use it, of course.)
That post ended on a question I didn't answer: what other tools have you been renting that you could own?
The answer is data wrangling.
For fifty years, moving data from one format to another required both a subject matter expert and an engineer. Today the SME can describe the destination, and an agent writes the transformation -- almost certainly better than what an average coder would produce, and certainly better than what the average SME could write alone. The bottleneck shifts from implementation to supervision.
Data Wrangling
At $dayjob, my team wanted better control of our own data sitting in Confluence -- not a corporate migration, just a team tired of not fully owning what it had written, looking at something more AI-native: an LLMWiki-class datastore instead of a wiki that predates the concept of an agent reading it.
Confluence gives you four ways to get your content out, and no two of them agree. Space Export. The REST API. HTML export. A full XML site backup. I tried the first three. Each one dropped something the others kept -- attachments here, page hierarchy there, macros rendered as nothing at all. The only export complete enough to actually work from was the full XML backup, which is also, conveniently (suspiciously?), scheduled for deprecation.
This task could have been a contractor engagement two years ago: parsing that XML into something the new system could ingest wasn't a matter of finding the right library and hand-rolling a converter over a couple of sprints. I described the target shape to Claude, and it wrote the parser. Not "the model looked at our wiki and did its best" -- an actual script, deterministic, that takes the XML in and produces clean output on the other end, the same way, every time you run it.
I'm an SME on this migration, not a data engineer -- I know what the wiki needs to look like on the other side, not how to hand-roll an XML parser. That gap, needing an engineer to sit between what an SME knows and what a machine can read, used to be its own toll booth. It's gone, but the SME isn't -- when the agent goes sideways on the actual shape of the problem, the way agents do, steering it back on course is exactly the job description.
In this case the LLM doesn't move the data: it wrote the program that moves the data. The intelligence gets spent once, at authoring time; the execution is boring, deterministic code you can read, test, and re-run -- not a fresh roll of the dice against your own wiki every time.
We treated the generated code the same way we'd treat a junior engineer's first migration script: review the implementation, verify the output, and measure what humans would miss. We spot-checked pages by hand, ran vector-similarity comparisons to catch semantic drift, and used a second model to audit the deterministic output against the original XML.
Data wrangling -- the discipline that justified armies of integration engineers -- just joined implementation on the list of things that used to be the bottleneck and aren't.
The Collapsing Funnel
Watch what SaaS companies actually do lately, not what they sell.
Cloudflare is the clearest example. It started by routing traffic -- CDN, DDoS protection, nothing more. Now it sells storage, GPUs, vector databases, and AI gateways. That's not feature creep. It's a CDN walking down the stack toward the scarce resource: compute.
Fly.io tried the same move -- container hosting, then GPU instances in late 2023 -- and then retrenched, winding the GPUs down entirely by mid-2026. I think that's more useful as evidence than the failure it looks like. Even a vendor that couldn't hold the position still felt the pull toward compute. The gravity is real even where the execution wasn't.
Value is collapsing toward the layer that runs actual compute. PaaS and IaaS aren't dying -- they're more load-bearing than they've ever been. Paying someone for uptime, power, and hardware you genuinely don't want to run yourself is an honest transaction. What's dying is the layer above it that charged you rent on your own data and called it a platform.
Service vs. Hostage
What does your money buy you? If you stop paying, do you simply lose capability, or do you lose access to your own data altogether?
Lose capability -- the managed database, the inference endpoint, someone else's uptime -- and that's a service. Keep paying, gladly.
Lose access -- to content you created, trapped in a format only they read, and that's a hostage situation dressed up as a subscription. If this is you, start finding your way out of vendor lock-in now.
The whole game for thirty years was making the second one look like the first. The wrangling cost was the ransom -- not written down anywhere, just baked into how expensive "we'll migrate you off" always turned out to be. Now the ransom is a few cents of tokens and an afternoon, so the hostage model stops working, at exactly the moment the genuine-service model gets stronger.
LLM-written migration code is not as reliable as the pitch -- independent audits of coding-agent benchmarks have found a meaningful chunk of "resolved" issues are false positives once someone actually checks, and our own validation step exists because of that, not despite it. A lot of lock-in also has nothing to do with data at all -- custom workflows, ecosystem integrations, compliance certifications like a signed BAA or a SOC 2 report don't move just because the export finally works. And if your AI copilot has been trained on a year of your usage inside one platform, that's a switching cost going up, not down. Wrangling solves one layer. It was never the only layer.
The Window
The infrastructure enclosure -- the one where the datacenter, not the code, is the actual moat -- depended on data transformation staying hard. One layer of that just got easy. Whether the window stays open, or something new closes around coordination or compute itself, is the question the Knowledge Enclosures series already raised, back in February and March. I'm not resolving it here.
But here's what's true today, for the export that saved our own migration: Atlassian announced in August 2026 that XML Site and Space Export in Confluence Cloud reach end of life on December 1st 2026. Not removed -- deprecated. Still works, but no bug fixes, no support, no SLA. The exact export path that got us out is the one that's now on a three-month clock.
We can all build our own tools now -- not because the tools got easier, but because the leaving got easier too. The vendors who used to count on that not happening are already adjusting. Atlassian's own answer, rolled out to general availability in February, is an official MCP server -- Jira and Confluence, the company says, are "the connectors they get asked for again and again." Let's call that what it is: not an easier way to leave, but an easier way to stay plugged in without ever exporting anything at all.
Now, who wants to talk about the AWS, Azure, and GCP lock-in syndromes...
James is a security engineer who, this month, also finds himself playing his own data engineer and SME -- turns out that's a package deal now. He publishes at waypoint.henrynet.ca.
Discussion