SAP APO end-of-life and equivalent forced migrations create the conditions for either the best or the worst supply chain investment decisions organisations make. The difference is almost always in the preparation.
The end-of-life notice changes the conversation. What was previously a discretionary investment decision — something the business could defer, qualify, or challenge on grounds of ROI — becomes a constrained one. The system is going away. The question is no longer whether to invest but how, and by when.
That constraint is genuinely clarifying. Organisations that have struggled for years to build the internal case for a planning capability upgrade find that the forcing function does the political work they could not. Budget is released. Stakeholders who previously hedged become engaged. The urgency that was previously absent is suddenly available.
The risk is that the urgency substitutes for the thinking. Forced migrations have a well-documented failure mode: the organisation moves quickly, selects a replacement under time pressure, and discovers after commitment that the new system inherits the same data quality problems, operating model gaps, and process limitations that made the old one underperform. The deadline created momentum, but the momentum carried the same assumptions into the new environment.
The organisations that use end-of-life well treat the forced timeline as an external constraint on when to commit, not as a reason to compress the diagnostic work that should precede commitment. They separate the sequencing question — what needs to be done before any vendor is selected — from the urgency question, which is real but does not answer the sequencing question.
The most consistent failure mode is letting the vendor selection drive the operating model design rather than the other way around. The deadline is real, the vendor shortlist is formed quickly, and by the time operating model questions surface they are being answered in the context of a specific vendor's architecture rather than as design choices made independently. The result is a system that fits the vendor's reference model rather than the organisation's actual decision requirements.
A related pattern is the data migration assumption. Organisations moving from a legacy planning system tend to underestimate the degree to which their current data — item master records, historical demand signals, planning parameters, exception logic — reflects years of manual workarounds rather than clean underlying truth. Migrating it as-is imports those workarounds into the new environment. The data appears to transfer; the quality problems transfer with it.
The third pattern is scoping under pressure. When a deadline is driving the project, scope tends to be managed by cutting rather than by designing. Capabilities that would genuinely improve the operating model get deferred as non-essential. The resulting implementation is on time and within budget, and underdelivers from the point it goes live.
The assumption most organisations are operating on is that the end-of-life deadline is the constraint that matters most.
It is not.
The binding constraint is almost always the quality of the diagnostic work that precedes vendor selection... and that work is almost always done by the people most adapted to working around the current system's limitations, under pressure from the very deadline that should be creating space for it.
The organisations that come out of forced migrations well are not the ones that moved fastest. They are the ones that separated the urgency question from the readiness question: treating the retirement date as the deadline for commitment, not as a reason to compress the thinking that should precede it.
That means conducting an honest assessment of what the current system is actually doing versus what it nominally owns, resolving the operating model design before a vendor's architecture fills the gap, and being explicit about the data quality problems that a migration will inherit if they are not addressed first.
BPC's outside-in view on this pattern comes from practitioners who have been through comparable migrations in comparable organisations. Tell us about your context and we can find the most relevant comparisons.
