Your software still works. It runs fine, does everything you need, and you have zero complaints. Then one Tuesday morning, you get a notification: support ends in 90 days. Upgrade now. This is not an accident, a technical limitation, or the inevitable march of progress. It is a business decision made months or years in advance, and it is one of the most effective revenue tools in the tech industry’s playbook.
Deliberate obsolescence, sometimes called planned obsolescence in hardware circles, is the practice of engineering a product’s death into its design from the start. In software, this usually takes the form of platform migrations that feel forced, artificial end-of-life dates, and the slow withdrawal of features that make an older version viable. The goal is not to leave you stranded. The goal is to move you somewhere more profitable.
The Architecture of Engineered Death
The clearest example of deliberate obsolescence in action is Microsoft’s Windows upgrade cycle. Windows 7 was a genuinely excellent operating system. Businesses loved it. It was stable, familiar, and fast. Microsoft ended mainstream support in 2015 and extended support in 2020, forcing millions of enterprise customers into Windows 10 migrations that cost, on average, between $1,200 and $2,000 per workstation when you factor in IT labor, retraining, and compatibility testing. That was not an unavoidable technical transition. Windows 7 could have received security patches indefinitely. The decision to kill it was a revenue decision dressed up in the language of security and technical debt.
Apple does the same thing with iOS. Each major iOS release is designed to run optimally on hardware released within the last three or four years. Older devices technically receive the update, but performance degrades measurably. A 2018 study by Harvard Business School researchers found statistically significant spikes in Google searches for “iPhone slow” corresponding precisely with new iPhone announcements, suggesting software updates were throttling older hardware. Apple later confirmed it was reducing processor performance on older batteries, framing it as a consumer protection measure. The framing was clever. The underlying incentive was a phone upgrade cycle.
Why Companies Build Expiration Dates In From Day One
The product teams working on these systems are not cavalier about this. The decision to obsolete a platform is usually made with careful calculation, often before the replacement platform is even publicly announced. There is a concept in product strategy sometimes called the “controlled burn,” where you deliberately reduce the viability of a product to accelerate adoption of its successor.
This connects to a broader pattern of intentional product strategy that looks counterintuitive from the outside. Tech companies regularly build features they never plan to release as a way of managing competitive signaling and migration timing. Knowing what you will withhold is just as strategically important as knowing what you will ship.
The economics are straightforward. Migrations generate revenue that ongoing subscriptions to stable products do not. When a company forces 100 million users onto a new platform, every one of those users goes through a fresh evaluation, fresh onboarding, and often a fresh pricing conversation. Enterprise customers especially tend to reassess their entire relationship with a vendor during a forced migration, which gives the vendor an opportunity to upsell, restructure contracts, and lock in longer commitments.
The Cloud Migration Playbook
The most sophisticated modern version of deliberate obsolescence is the on-premise to cloud migration, and no one has executed it more aggressively than Salesforce, SAP, and Oracle. Each of these companies spent years building deeply embedded on-premise software that became mission-critical for large enterprises. Then, systematically, they began withdrawing support for on-premise versions while simultaneously making their cloud alternatives more capable.
Oracle’s database licensing is particularly instructive. The company has steadily made on-premise licensing more expensive and complex while offering seemingly simpler pricing on Oracle Cloud Infrastructure. The complexity is not accidental. It is designed to make the cloud option look cleaner, even when the total cost of ownership is higher over a five to ten year period. This is pricing strategy used as migration pressure, not just revenue optimization.
Google has used the same playbook with consumer products. Google Reader, Google+, and dozens of other Google products were killed not because they were unprofitable but because keeping them alive fragmented user attention and slowed migration to platforms Google considered more strategically valuable. Killing a product is sometimes less about that product and more about forcing users somewhere else.
What This Means for Businesses Stuck in the Cycle
For enterprise technology buyers, understanding deliberate obsolescence changes how you should evaluate vendor relationships from the start. The question is not just “does this product solve our problem today” but “what is this vendor’s historical pattern around end-of-life decisions, and where do they want us in five years.”
Some practical patterns worth tracking: vendors who offer “lifetime” licenses often have the highest rates of compatibility-breaking API changes, which achieve the same migration pressure without explicitly ending support. Vendors who aggressively acquire competitors frequently obsolete the acquired product within 18 to 24 months, using the migration as a forcing function into the acquirer’s ecosystem. And vendors who move to usage-based pricing in the cloud almost always structure tiers so that your current on-premise usage maps to a tier just below what you actually need, requiring an immediate upsell.
This is not purely cynical. Some forced migrations deliver genuine improvements. Moving from legacy on-premise infrastructure to modern cloud architecture often does reduce operational overhead. But the timing and mechanics of the migration are almost never driven by your needs. They are driven by the vendor’s revenue calendar.
The Honest Version of the Story
Deliberate obsolescence works because it is genuinely hard to fight. Switching costs are real. When your business runs on a platform, the cost of leaving often exceeds the cost of paying whatever the vendor asks to stay. This is why platform companies generate the majority of their revenue from users who feel trapped rather than loyal, and why vendors invest so heavily in making integration deep, migration painful, and alternatives hard to evaluate.
The companies that navigate this best treat vendor lock-in as a technical risk from day one, the same way they treat security or scalability. They maintain clean data portability, build abstraction layers between core business logic and vendor-specific tooling, and regularly audit which of their systems would be painful to replace. Not because they plan to replace them, but because the answer tells you exactly how much leverage your vendor has over you.
Engineered product death is a feature of the tech business model, not a bug. Understanding it does not make you cynical. It makes you a better buyer.
