The purchase order went out at 2:14 on a Tuesday morning, created by the nightly MRP run, for an item the assortment team killed eight months earlier. The buyer had set the status to discontinued in the ERP. The sell-down was going fine. But the reorder point in the warehouse system still said 40, stock fell through it as the last orders shipped, and the planning engine saw a shortfall where everyone else saw a sell-down. It ordered 200 more from a supplier who was surprised anyone still wanted them. The pallets arrived three weeks later, next to the clearance stock of the same product.
Discontinuing a product looks like the easy half of the lifecycle. Creating an item takes five departments and three weeks, so surely ending one is a checkbox. It is not, and the reason is the same in reverse. A new item earns capabilities one slice at a time: receivable, then sellable, then invoiceable. A dying item has to shed them one at a time, over months, and a single active flag cannot hold a sequence.
Discontinued is a sequence, not a status
The decision to kill a product is one meeting. The execution is five separate changes spread across a year. First you stop replenishing, while sales continue, because there is stock to sell and writing it off costs real money. Then you stop promising: quotes and long-term contracts should no longer include the item even while the webshop still sells the remainder. When the stock is gone, or the end date arrives, you stop selling. Warranty and spare-part obligations keep the record alive long after that; in some industries you are required to support the product for ten more years. Only then does the item become an archive entry, readable but inert.
Each of those stages blocks a different transaction type. Between stop-buy and stop-sell, the item must reject purchase orders and accept sales orders, which no single active flag can express. Force the sequence through one flag and you get the two familiar failure modes: the item blocked too early, leaving sellable stock that can never be sold, or blocked too late, which is how the 2 a.m. purchase order happens. The item needs statuses per capability, checked at transaction time, exactly as it did on the way up through the lifecycle.
Where phase-out breaks
The sequence is manageable inside one system. The trouble is that the item does not live in one system. It has copies in planning, e-commerce, the supplier portal, and every spreadsheet that ever exported it, and the item is only as dead as its least-informed copy.
The reorder point that resurrected the item
The buyer sets the ERP status to discontinued and considers it done. The reorder point in the warehouse system still says 40, the forecast still predicts demand, and the min-max levels were never touched. Stock dips below 40 during the sell-down and the nightly MRP run orders 200 more. The item did not come back to life. It was never fully dead.
The webshop that never got the memo
The ERP knows the item is gone. The e-commerce platform holds its own copy and keeps the listing live, so customers keep buying a product the last warehouse shipped out in March. Every order lands as an eternal backorder, and customer service spends the summer explaining a discontinuation the website denies.
The supersession chain nobody validated
Item A was replaced by item B two years ago. Now B is discontinued and points to C. Half the systems resolve one hop, so orders for A land on B, which is also dead. One resolves nothing and just rejects the order. Nobody has ever checked whether a replaced-by link points at a living item.
The component still sitting in fourteen BOMs
Purchasing kills the part because the supplier stopped making it. It still appears in fourteen bills of material. The next production order explodes a BOM and demands a component nobody can buy, and the planner discovers the discontinuation at the exact moment it stops a production line.
The record someone finally deleted
Three years after the sell-down, someone tidying the item list deletes the archived record. Seven years of purchase orders, invoices, and stock movements now point at nothing, and the warranty claim that arrives the following month references an item number the system has never heard of.
Notice what these have in common. None of them is a data entry mistake. Every person involved did their step correctly. The failures live in the references: the planning parameters, the downstream copies, the BOM lines, the replaced-by links, the transaction history. Discontinuation is not an edit to a record. It is an edit to everything that points at the record.
Rules that keep dead items dead
Start with the reference check, and run it before flipping anything. Open purchase orders, open sales orders, stock in every warehouse, BOM usage, active price list entries, live webshop listings, replenishment parameters. This is a query, not a meeting: every one of those is a table you can join against the item number, and the result is the actual to-do list for this discontinuation. Most teams run the check informally, in the sense that they discover the list one incident at a time over the following year.
Give the stages effective dates on the record itself. A stop-buy date, an end-of-sale date, an end-of-support date, entered once, visible to everyone, and enforced by the systems that check them at transaction time. Dates beat statuses here because they let downstream systems prepare: purchasing sees the stop-buy date coming and runs down the final order, the webshop schedules the delisting, planning zeroes the reorder point on the right day instead of eight months late.
Treat supersession as governed master data, because that is what it is. A replaced-by link should only accept an active item, a chain should resolve to its final successor when a system follows it, and a cycle should be impossible to save. These are the same validation rules you would put on any reference attribute; the only unusual thing about supersession is that nobody thinks to govern it until an order bounces off a dead successor.
And never let the archive stage mean delete. The urge to clean up the item list is healthy; pointing it at the delete button is not, for reasons the hard delete versus soft delete question covers in full. An archived item that is blocked for every transaction and hidden from every dropdown is exactly as clean as a deleted one, except the history still works.
If you are coming off MDS
Microsoft MDS had no concept of a lifecycle, so every MDS shop invented one: an IsActive attribute, or a homegrown Status domain with values someone defined in 2014 and nobody dares to change. The subscription views did not care either way. They published every member to every consumer, discontinued or not, unless someone remembered to add a WHERE clause to each view individually. In every MDS estate I have seen, at least one view was missing the filter, and that view fed the one system still ordering dead items.
If you are migrating off MDS, the migration is the moment to build the sequence properly: real lifecycle statuses instead of a folk taxonomy, effective dates on the record, and a reference check that runs before a status change instead of a year after it. It is also the moment to find out how many items in your estate are discontinued in one system and alive in three others. The answer is rarely zero, and you would rather find it during a migration than during a production stop.
Common questions
What does it mean to discontinue a product in master data?
It is a sequence, not a status: stop replenishing, sell the remaining stock, stop selling, keep servicing warranty and spare-part obligations, then archive. Each stage blocks different transactions, so a single active flag cannot represent it. The record needs statuses per capability, the mirror image of how a new item earns capabilities during setup.
Why do discontinued items keep getting ordered?
The status changed in one system and the planning parameters did not. Reorder points, min-max levels, and forecasts live in systems that hold their own copy of the item. When stock dips below a reorder point nobody zeroed, MRP treats it as demand and orders more, whatever the ERP status field says.
What is part supersession and why does it break?
The replaced-by link from a discontinued item to its successor. It breaks when the successor is later discontinued too, forming a chain that some systems resolve one hop at a time and others not at all. The links need validation: the successor must be active, chains must resolve to a final successor, and cycles must be forbidden.
Should discontinued items be deleted?
No. Years of transactions reference the item, and deleting the record orphans all of them. Archive instead: block every transaction type, hide the item from searches and dropdowns, and keep the record readable for history, audits, and the warranty claim that arrives four years later.
Make a status change something you can trust
Primentra runs changeset-based approvals on status changes, checks what still references a record before you retire it, and keeps the full audit trail of who discontinued what and when. It runs on your own SQL Server, deploys in a day, and costs €7,500 per year flat. The 60-day trial is long enough to phase out a real product family through it.