End of Life

A feature you have decided to remove still sits on the screen for a while. That is deliberate — people need time to move off it. The awkward part is what happens when it breaks during those weeks. Do you fix it? It is getting deleted in two months anyway.

Without a date on the calendar, that question gets a different answer every time it comes up. A single incoming request is called a support ticket, and every ticket about a doomed feature turns into a judgment call by whoever picks it up. On a quiet week it gets fixed. On a busy week it gets a polite reply. And once one ticket has been fixed, the feature is effectively supported again, so customers keep filing.

Pagedeck lived through exactly this. Sofia brought over a bug in the old comments feature, Theo answered that the feature had already been announced for removal, and Sofia asked the obvious follow-up: so are we fixing it right now, or not? The announcement had said the feature would go away someday. It had never said when anyone would stop working on it. End of life (EOL) is the name given to that missing date. Naming it turns a recurring argument into a line on a schedule, which is the only form in which a customer can plan around it.

Once this date passes, the feature keeps running and nobody maintains it. It does not disappear from the screen. The buttons still work. What changes is that there is no longer anyone behind them.

Three things stop at once.

1. Bug fixes. Newly reported defects are not repaired. Any fix already scheduled gets cancelled when it crosses this date, and the person who reported it is told that it was cancelled. Closing it quietly leaves someone waiting for a repair that will never ship.
2. Security patches. Vulnerabilities reported from outside are not closed either. This is the item that goes wrong most quietly. Users report bugs, but nobody reports a vulnerability, so it sits for months — and enterprise customers arrive at renewal with a security checklist that asks first whether any feature has lost its patches.
3. Support responses. When a ticket arrives, the reply is a link to the migration guide rather than a fix. That guide is the document explaining what to move to and in what order.

This date does not have to be the day the feature is deleted. Pagedeck leaves 30 days between them. If the removal notice goes out on day 1, end of life lands on day 61 and the code comes out on day 91. Support stops a full month before the feature does. Customers who have not moved yet can still pull their data out during that month, and if something turns out to be wrong there is still room to reverse course.

Communication goes out again at this point. The help article and the release note record that support has ended, and the banner in settings changes from "ending soon" to "ended." An identical banner in the same place tells users nothing about what changed overnight.

The next stage is the day the code and the data are actually deleted, and three checks stand between the two.

1. Remaining users. Count the accounts that touched the feature at least once in the last 30 days. A 45-person company does not delete a feature with 200 accounts still on it. The number has to be near zero, or every remaining account has to be reachable and booked for a move.
2. Contractual promises. A service level agreement (SLA) is the level of service promised to a customer in writing, and when it names repair times, end of life cannot fall before that contract expires. If the contract runs to March, deletion waits until after March.
3. A way out for the data. Export has to work, and somebody has to have downloaded a file and opened it. A working export button and a readable file are two different claims. Theo verifies this one himself by exporting a single account: if all 100 old comments are there with their timestamps intact, it passes.

If any of the three fails, the deletion date moves. The end of life date does not. They are separate dates, and dragging the earlier one along punishes the customers who already migrated — you would be changing a promise to the people who cooperated in order to wait for the people who did not.

"This feature goes end of life on November 30, so after that we answer questions but we don't fix anything."

No repair work gets scheduled from that day forward.

"Let's set the EOL date first and work the announcement schedule backwards from it."

Pin the last date, subtract 60 days, and that gives you the announcement day.

"Their enterprise contract runs to March, so EOL can't land before that."

The contract sets the date, not our roadmap.

At Pagedeck, Mia decides on a sunset by weighing usage against maintenance cost, and the end of life date is set in that same meeting. Theo then pulls the list of remaining users, and a week before the announcement Sofia contacts enterprise customers individually — hearing it from your account manager and receiving the same paragraph in a mass email are not the same event. Grace signs off on the date when a contract is involved. Reverse that order and Sofia's call becomes damage control, and the customer feels notified rather than consulted.

The most common misreading is that the end of life date is the day the feature disappears. The word sounds final, so people expect the button to be gone. But this date cuts off the people, not the software. Collapse the two into one day and a customer stuck mid-migration loses the help desk and the export at the same moment. The wave of refund requests the day after a shutdown almost always traces back to this.

The other frequent mistake is treating the announcement as the work. A notice is only a notice when it gets read. Count the remaining users right after the announcement, again at the midpoint, and again two weeks before the date, and the rate of decline becomes visible. If it is slower than expected, find out why while there is still time. Skip that and a few hundred people hit a wall on the day itself, and their tickets arrive at exactly the desk that has stopped fixing things. Sofia has nothing to tell them, Theo has moved on to other work, and the team ends up reopening code it had planned to delete — at speed, under pressure, in a codebase nobody has touched in months.