On the Seam: Working Drafts · August 2026
They're Burning the Ships. Your Cargo Is Still Aboard.
The software company you depend on may be rebuilding itself from scratch right now. That is the buyer's problem in the story everyone is telling from the vendor's side — and the part of it your fifteen years of configuration is sitting inside.
There is a line in the Wall Street Journal's account of the "SaaSpocalypse" that I cannot stop turning over. A founder, describing what generative AI did to his company, says the only way forward was to "burn the ships and start from the ground up." He is not being dramatic. He laid off most of his staff, stopped selling the product his customers had bought, and rebuilt around AI agents from the keel up. He is one of many. The reporting is full of software companies doing the same thing — relaunching, restructuring, or quietly shutting down and starting over, because a tool that helps a person do work is worth less every month in a world where an agent does the work instead.
It is a vivid story, and it is told, understandably, from the deck of the ship. The founders, the investors, the valuations cut by ninety percent, the plane towing a "SaaS is dead" banner over a conference. What almost no one is asking — because the people being interviewed are not the ones holding the question — is simpler and, if you run an enterprise, considerably more urgent. When your vendor burns the ships, what happens to the cargo you loaded onto them?
Because you loaded a great deal.
What you actually own
Here is the thing the whole conversation keeps missing. Fifteen years of SaaS spending bought you a subscription to someone else's code. But that code was never the thing you built. The thing you built was the configuration you poured into it, and that is a different asset entirely.
Think about what actually lives inside your instance of a major platform. The approval chains that encode who can authorize what, and at which dollar thresholds. The field mappings that took three integration projects and a consultant to get right. The workflow logic that captures a decade of "no, in our business it works this way." The exception handling that exists because of a specific audit finding in 2019 that nobody wants to repeat. The connective tissue between that system and eleven others. None of that came in the box. You built it, one hard-won decision at a time, and it encodes something genuinely valuable: how your organization actually runs.
In a bank, that configuration is the difference between a generic loan-origination tool and the specific sequence of checks your regulator expects to see. In an insurer, it is the claims logic that took years of disputes to settle into its current shape. In a health system, it is the scheduling and authorization rules that keep you compliant. The software was a container; what you poured into it is what mattered. And that accumulated knowledge sits in the vendor's data model, in a shape you do not control, on the ship.
Which is a fine arrangement, right up until the ship is being rebuilt around something that does not inherit it.
Getting it off the ship is harder than an export
When the vendor rebuilds around agents, the natural assumption is that your configuration comes along for the ride. Mostly it does not. An AI-native product re-architects so the agent sits at the center, and the founders in that article are blunt that bolting AI onto the old design is exactly what failed. A configuration built for humans clicking through screens maps poorly onto an architecture built for an agent taking actions. Fifteen years of your setup rests on assumptions the new thing is deliberately throwing out.
So you face an extraction problem, and calling it a data export badly understates it. Your rows and records will come out easily enough. What resists extraction is the logic, the why behind the configuration. Nobody ever wrote it down in a portable form, because for fifteen years nobody had to. It lived in the settings of a system you assumed would always be there. Getting it out means reverse-engineering years of accumulated intent from the residue it left in someone else's schema. Some of it is recoverable. I’d argue most of it walked out the door with the people who configured it.
And here is the paradox at the center of this whole moment:
Sit with that, because it is also the way out. The agents that threaten to make your SaaS tool obsolete are precisely the instrument you will use to salvage what you built inside it. You point them at the legacy system before it goes dark — at the custom fields, the schema, the validation rules, the API configurations, the years of accreted settings — and you have them do what no human team has the time or the memory to do: read the whole thing and infer the logic it encodes. Why does this field gate that approval? Which exceptions fire under which conditions. What the integration actually does, as opposed to what the documentation claims. An agent can traverse a decade of configuration and produce the written account of your own process that you never had — the documentation that should have existed all along and never did.
That is the work almost no one is scheduling, and the window for it is closing. You can only interrogate the system while it is still running. The moment the vendor sunsets the old product — and they are telling you, in the trade press, that they intend to — the richest source of your own institutional logic goes read-only, and then goes away. The enterprises that come through this will be the ones who turned the agents loose on their legacy systems as archaeologists before they ever deployed them as workers. Document first, while there is still something to read. Rebuild second.
Suppose you get it out. Now it has to change form. Your process logic was static: rules a human set, for a human to follow. To be worth anything in an agentic architecture, it has to become something an agent can reason over and act on — not a configuration but a capability. That is the reimagining problem I have written about before, arriving one layer down than usual: not "should this workflow exist," but "can this workflow's accumulated intelligence survive being translated from settings into something autonomous." And the moment an agent is acting on your extracted, refactored process — paying the claim, advancing the loan, booking the procedure — you have inherited the governance problem too. The process that used to be executed by a person following your rules is now executed by a system, and someone has to be accountable for what it does. The cargo does not just need moving. It needs rebuilding into a form that can act, and governing once it does.
And some of it, you will decide, is not worth carrying at all. Not every process you encoded fifteen years ago deserves to be refactored; some of it exists only because the old business model required it, and that model is being reimagined out from under you as you read this. Part of the discipline of this transition is knowing which cargo to haul ashore and which to let burn with the ship — which encoded logic is institutional knowledge worth preserving, and which is simply technical debt wearing the costume of process. That is its own hard question, and I will take it up on its own another time. For now it is enough to say that salvage and retirement are both deliberate acts, and confusing one for the other is how enterprises either throw away what mattered or faithfully rebuild what they should have abandoned.
Which raises the question nobody in the vendor's story has to answer, because it is yours: who pays for this?
The uncomfortable economics
The vendor will not pay for it. They are burning their own ships to survive, and salvaging your cargo sits nowhere on that agenda; their new pricing, increasingly metered to agent output rather than seats, follows their economics and ignores your transition entirely. Your systems integrator, meanwhile, will happily bill for the work, which tells you how expensive it is.
And it is the worst kind of expensive: a cost with nothing shiny to show for it. Extracting and refactoring the intelligence already embedded in systems you already own produces no launch, no demo, no press release. It is the least fundable work in the enterprise because, on the surface, it looks like paying again for something you already bought. That framing is the trap. Read the spend correctly, and you are not buying the software twice. You are paying, for the first time, to own an asset you have only ever rented shelf space for: your own institutional knowledge, in a form that outlives whatever vendor happened to be holding it. Priced against a line item, it never survives the budget meeting. Priced against the alternative — being stranded when the ship goes down, and rebuilding fifteen years of process logic from memory under time pressure — it is cheap.
Which is why the last question is the one that actually matters. If you are going to move the cargo, where do you move it to?
The foundation question, honestly
I will not name a product here, because the honest destination is an architecture, not a purchase. But architecture does not have to mean vague, and enterprise architects deserve something they can draw on a whiteboard. So let me name it plainly: what you are building toward is an owned semantic and orchestration layer.
By semantic, I mean the place where your business logic lives as your own — the rules, the authority limits, the approval thresholds, the audit requirements, expressed as policy and code that you control, in language that describes your business rather than some vendor's data model. The claims logic, the origination checks, the exception handling you just spent an agentic archaeology project recovering: it lands here, as an asset you hold, not a configuration you rent. By orchestration, I mean the layer that sits above execution and decides which agents and which models act on those rules — under what authority, with what oversight, handing the actual work down to whatever underlying tool or model happens to be best this quarter, and swapping it out when that changes without disturbing the logic above it.
That inversion is the whole point. In the SaaS era, the vendor's tool sat at the center, and your logic lived inside it, at its mercy. In the architecture that survives this transition, your logic sits at the center, and the tools become interchangeable execution underneath it. The models will keep changing. The specialized agents will keep changing. The vendors will keep burning their ships. A semantic and orchestration layer you own is what makes all of that someone else's churn instead of yours — because the part that matters, the encoded knowledge of how your business runs, no longer lives on anyone's ship but your own.
I have argued before that in the agentic enterprise this orchestration layer is the capability that decides whether any of it holds together. The SaaS transition is where that argument stops being abstract. The right foundation is not measured by which tool does the most. Measure it by what it leaves in your hands: the thing you spent fifteen years building, held in a form you never have to excavate from someone else's schema again.
The winners are the ones who unload first
The vendors are burning the ships to save themselves, and I do not blame them; the water really is rising. But they are solving for their survival, not yours, and the story in the press right now is entirely theirs to tell. Your cargo is still aboard, and no one is rowing back for it.
So the enterprises that come through this well will not be the ones who pick the smartest new vendor, or who move the fastest to buy whatever is labeled agentic. They will be the ones who understood, earlier than their competitors, where the asset worth saving actually lived: never on the vendor's balance sheet, always in their own configuration, and got it off the ship while there was still a deck to stand on.
The ships are burning either way; that much is settled. The only question still on your schedule is whether the fifteen years you invested go down with them, or come ashore with you.
Dr. Trey Harper writes on trust, legitimacy, and the architecture of the agentic enterprise at treyharper.com and in the LinkedIn newsletter On the Seam: Working Drafts. The views expressed here are entirely my own and do not represent the policy or position of my employer or any customer.