You upgrade your project management tool, and three months later the old version stops receiving security patches. Your favorite app gets a forced redesign that breaks your workflow. A platform you built integrations around quietly deprecates its API. This keeps happening to you, and it is not bad luck. Tech companies are deliberately engineering software to have a lifespan, and once you understand why, you will start making much smarter decisions about the tools you adopt and the ones you avoid.

This is part of a broader pattern of intentional product strategy that looks chaotic from the outside but is coldly rational when you examine the business logic underneath it.

The 18-Month Clock Is a Business Decision, Not a Technical One

Software does not wear out. A line of code written in 2010 works the same way in 2025 as it did when it was first deployed. So when companies tell you that a product has reached “end of life,” they are not describing a technical reality. They are describing a financial one.

The 18-month cycle maps almost perfectly onto two things: enterprise budget cycles and the average time it takes a competitor to catch up with a feature. Companies build planned obsolescence into their roadmaps because a customer who needs to migrate is a customer who can be upsold. An upgrade is not just a product improvement. It is a sales event.

Think about how Adobe handled the transition from Creative Suite to Creative Cloud. The software did not stop working because it was broken. It stopped being supported because subscriptions generate more predictable revenue than one-time purchases. The engineering lifecycle was redesigned to match the revenue model, not the other way around.

How Forced Obsolescence Creates Lock-In

Here is where it gets genuinely interesting. Planned obsolescence is not just about getting you to pay again. It is about making sure you pay them again specifically.

When software breaks on a schedule, it creates switching costs that compound over time. Your team learns proprietary workflows. Your data lives in formats that are difficult to export. Your integrations depend on APIs that only work within that vendor’s ecosystem. By the time the “sunset” notice arrives, migrating feels more expensive than upgrading, even when upgrading means paying significantly more.

This is the same logic behind why software licenses frequently cost more than the hardware they run on. The hardware is a commodity. The switching cost is the product.

Salesforce is a masterclass in this approach. The platform is notoriously difficult to migrate away from, not because the software is uniquely powerful, but because years of customization, data, and workflow dependencies make leaving genuinely painful. The complexity is, at least partially, a feature.

What the Engineering Teams Actually Know

Here is something most users never consider: the engineers building your software often know exactly how long it is designed to last. Architectural decisions made early in a product’s life, things like database choices, API versioning strategies, and how tightly features are coupled to each other, determine the practical lifespan of the software long before any executive makes a “sunset” announcement.

Senior engineers sometimes push back on these decisions. But product roadmaps are driven by revenue targets, and a modular, long-lived architecture that is easy for customers to maintain indefinitely is not always the architecture that maximizes renewal revenue.

This tension shows up in an interesting way with deliberate feature choices, too. Companies regularly build features they never release on purpose, holding them back as leverage for future upgrade cycles or competitive positioning. The engineering work happens. The release does not. The gap between what is technically possible and what is commercially available is managed as carefully as any product spec.

What You Can Actually Do About This

Understanding the pattern is useful, but here is how you use it practically.

Ask about roadmaps before you commit. Before adopting any critical tool, ask the vendor directly: what is the end-of-life policy for this version? How much notice will we get before a forced migration? The answers will tell you a lot about how they think about customers versus revenue.

Prioritize open standards and export flexibility. Tools built on open formats (plain text, CSV, open APIs, standard SQL) give you options when the inevitable sunset happens. Proprietary formats are a trap. Evaluate every tool you adopt through the lens of: how painful would it be to leave?

Plan for migration costs in your budget. If you are relying on any software for critical workflows, budget for a migration every two to three years. Treat it as an infrastructure cost, not a surprise. Companies that do this consistently avoid the expensive, scrambled migrations that happen when a sunset catches them unprepared.

Watch for the warning signs. Acquisition by a larger company, a shift from one-time pricing to subscriptions, a new CEO with a “growth focus,” a sudden emphasis on “enterprise” customers when you are not one. These are reliable predictors that a product lifecycle is about to be deliberately shortened.

Bet on platforms, not just products. Products get sunsetted. Platforms that other products depend on are harder to kill quickly because the ecosystem creates pressure to maintain compatibility. This is not a perfect rule, but it is a useful filter.

The Bigger Picture

Planned obsolescence in software is not a conspiracy. It is an entirely rational response to the incentives that companies face. When you understand those incentives, the 18-month cycle stops feeling like betrayal and starts feeling like a predictable pattern you can plan around.

The companies doing this are not necessarily acting in bad faith. They are optimizing for the metrics their investors care about. Your job, as someone who depends on these tools, is to optimize for your own continuity, which sometimes means making different choices than the ones the vendor is nudging you toward.

Start with your most critical tools today. Ask yourself: when this one gets sunsetted, what does migration look like? If the answer makes you uncomfortable, that is exactly the information you needed.