Everyone keeps asking which enterprise software companies AI will kill. Here is something nobody's analytic framework accounts for: the sheer, grinding organizational exhaustion of replacing enterprise software that already works.

Not “works well.” Just “works”. Processes payroll without incident. Generates audit logs that satisfy the compliance team. Pushes notifications to the right places in the right order because someone spent three weeks in 2021 configuring it that way and documented almost none of it. The software running quietly in the background of a large organization isn’t running quietly because it’s excellent. It’s running quietly because every person who might have replaced it did some loose math, felt the weight of what that project would actually cost in human time and political capital and calendar space and emotional bandwidth, and decided to do something else instead.

Rational calculation by people who understand that the demo is never the migration.

Some writers describe an agent-heavy future where design and coordination become the bottlenecks rather than code itself, which is a useful lens, but it still doesn't explain what happens inside organizations once those capabilities exist and someone has to decide what to do with them¹.

Dan Hockenmaier's recent essay "The Software Shakeout" is in my opinion the best version of the "who's going to die?" genre. His framework is clean: switching costs on one axis, compounding value on the other, companies sorted into durable, eroding slowly, and eroding quickly. His examples are concrete. His point about CrowdStrike processing 100 billion security events daily is the kind of detail that makes you nod your head. I nodded mine. He is correct that some moats are more defensible than others, and also correct that the competitive pressure coming from every direction is structural rather than cyclical.

But switching costs, as these essays use the term, are almost always understood as technical or contractual. They’re rarely understood as metabolic.

The missing variable isn’t data portability or ecosystem lock-in or per-seat pricing pressure. The missing variable is maintenance. The accumulated, distributed, poorly documented, politically embedded maintenance burden that any software system older than three years has deposited across an organization like sediment. You don’t just replace the software. You replace the permission models and the audit trails and the internal documentation and the tribal knowledge about why certain fields exist and the integrations that two contractors built in 2017 and the reporting logic the CFO specifically requested and the onboarding flows HR rebuilt twice and the bots that depend on some API and the single engineer who actually understands how all of it connects.²

Security reviews don’t scaffold themselves. Access controls don’t scaffold themselves. Data residency clauses, compliance artifacts, change management plans, and the forty-seven browser-based approvals required to spin up a new vendor in a regulated industry do not scaffold themselves.

Increasingly, the code is the easy part.

How Castles Fall (Rarely Through the Front Gate) #

Before discussing what incumbents can do, it’s worth being honest about how they fail, because the failure modes are not the ones the frameworks model.

The frontal assault, where a well funded AI native startup builds a demonstrably superior product and enterprises switch en masse, is the least likely failure mode and the one that receives the most analytical attention. Real castles rarely fall this way.

Betrayal from within is one mechanism. The engineers who understand the data schema, who know which integrations are load bearing and which are vestigial, who carry fifteen years of institutional knowledge about why certain architectural decisions exist, are being recruited aggressively right now. Code can be restricted. Knowledge inside people cannot.

Slow siege is another. Existing customers stay because migration is painful and because the people who would manage it have other priorities. New customers, facing a real choice between an incumbent built for 2012 and an AI native alternative built for now, make different decisions. Net revenue retention drifts down. Logo growth softens. The walls are intact and the base isn’t visibly leaving wholesale. By the time the compounding becomes unmistakable in the financials, the window for dramatic response has likely closed.

Then there’s fatigue miscalculation, which this genre largely misses or actively downplays.

Some incumbents overestimate how tired customers are of switching and raise the drawbridge so aggressively they trigger departures. Others underestimate how tired customers are of them, of bureaucracy and rough edges and ignored requests, and assume inertia will persist indefinitely.

Energy inside organizations is finite. Replacing a system consumes political capital, management bandwidth, and emotional resources required to manage change in large groups of people who didn’t ask for it. It also consumes goodwill. The audible groan in an all hands when someone announces another new tool is not trivial. It’s a signal that adoption bandwidth is already overdrawn.

But tolerating a system that no longer fits also consumes energy, slowly and invisibly, in the form of workarounds and low grade drag. When dissatisfaction crosses a threshold, the calculus inverts faster than most disruption frameworks can model.

Finally, the relief force that was supposed to arrive just doesn’t. Every siege assumes something is coming. For incumbents, the relief force is the AI roadmap, the bet that the enterprise product team can move fast enough to compete with AI native startups building from zero. The companies that execute are probably those that already had unusually strong product culture, unusually low technical debt, and leadership that recognized the threat early rather than bolting features onto existing architecture and issuing a press release.⁴

Castles rarely fall because attackers breached the front gate. They fall because defenders misjudged supply lines, morale, and time.

What the Siege Looks Like From Inside the Castle #

The openness of the SaaS era was never philosophy. It was strategy. When code was expensive, platforms made themselves permeable because permeability aggregated developer energy. APIs were not generosity. They were distribution.

When AI collapses the cost of building new software, the logic of openness collapses with it. The rational move for an incumbent facing pressure is selective closure: repriced APIs, narrower export capabilities, contract language that redistributes liability, integrations that make adjacent systems less substitutable, sales teams renegotiating multi year agreements while leverage still exists.

That’s what raising the drawbridge looks like.

Epic has been doing exactly this in healthcare for years, excoriated for it by everyone from independent physicians to the ONC³ to technology journalists who find it villainous. Epic's market position hasn't been meaningfully affected, because the switching cost in hospital EHR systems is so catastrophic that customers can absorb a considerable amount of bad behavior before departure becomes rational. The interesting question is whether this works the same way for companies whose customers have more options.

The drawbridge doesn’t only block attackers. It blocks the organizational energy required to attempt departure. It buys time by making the act of leaving feel like exactly the kind of project nobody wants to run this quarter.

The strategy requires two conditions. Customers must perceive no alternative worth the labor cost of switching. And the incumbent must read its own leverage honestly rather than aspirationally.

The Offensive Data Argument, Examined Honestly #

The optimistic version of the incumbent story is that years of proprietary data create offensive leverage.

Workday holds years of compensation and workforce planning data. ADP holds payroll data covering a massive portion of the workforce. If that data can power genuinely better models, the position becomes expansionary.

The question isn’t whether a small, AI-native startup can build a cleaner interface that solves the same problems. It’s whether an incumbent can build something on top of its data that a startup cannot replicate.

The honest answer is variable. At best, structured and usable. At worst, a sedimentary record of configuration drift and schema entropy. “Has a lot of data” is different from “has clean, model ready data.”

CrowdStrike's security event data is probably genuinely usable: high volume, consistently structured, labeled by outcomes. Workday's compensation data is probably murkier. Whether it’s usable at the required level of sophistication isn’t answerable from the outside.

The decisive question is whether incumbents can use their data without collapsing under complexity accumulated over years.

The Microsoft Template, Briefly #

Microsoft is the standard precedent for survival. Its path was not linear. It survived the internet through strategies that produced antitrust proceedings. It didn’t survive mobile. It survived cloud through Azure, acquisitions that appeared overpriced and weren’t, and an early OpenAI bet that looked eccentric and turned out to be prescient.

Survival required capital, timing, and a willingness to absorb cultural irrelevance during a decade of stagnation.

Surviving and thriving are different outcomes. Platform shifts unfold over operational time, not narrative time.

What the Shakeout Actually Looks Like #

If this holds, the shakeout won’t resemble a graveyard. It will look like compression: fewer closed platforms, a long tail of AI native tools, and depressed multiples that persist longer than markets expect.

The fatigue moat holds until AI native vendors can absorb functionality and compliance overhead and institutional trust and organizational embedding.

The trebuchet against the drawbridge is not better UX. It may be an LLM assisted migration. The moment AI can reliably read legacy documentation, infer integration maps, reconstruct undocumented permission models, and auto generate the scaffolding that currently takes months of human coordination, the metabolic cost of switching drops sharply. When that happens, fatigue stops protecting incumbents and starts entrenching whoever successfully absorbs the migration burden⁵.

Knowing which outcome dominates requires granular knowledge frameworks are designed to avoid.

My honest view is that historically, the hardest thing in software wasn’t writing code. It was building the compliance frameworks and organizational embedding and distributed trust that real buyers depend on.

Whether those structures are sufficient to win a prolonged siege is uncertain.

The companies that don’t navigate this well won’t disappear cleanly. They’ll become quieter, smaller versions of themselves, persisting on inertia while their castle gradually empties from within and someone storms the postern gate⁶.

Like this? Subscribe via email here.