In short: Mainstream maintenance for SAP APO ends on 31 December 2027, after which extended support costs a premium on the maintenance fee and carries a commitment to move to S/4HANA. Four paths are open: move to IBP and S/4HANA together, move to IBP first and the ERP later, run a specialist planning platform beside the existing ERP, or buy time with extended support. IBP is not a lift and shift, and detailed production scheduling goes to S/4HANA rather than into the planning suite, so an APO estate leaning on PP/DS splits across two products. Every effort estimate depends on how much custom logic sits in the current estate, and counting it takes about a week.
Mainstream maintenance for SAP's Advanced Planning and Optimization suite ends on 31 December 2027. After that, extended support is available at a premium on the maintenance fee and comes with a commitment to move to S/4HANA.
That is a hard date on a system that sits at the centre of planning for a very large number of manufacturers, and it forces a decision that most of them would rather not be making right now.
Worth knowing what sits beyond it, because the shape of the runway changes the calculation. SAP's published maintenance strategy runs extended maintenance for this generation of the Business Suite to the end of 2030, and what follows is customer-specific maintenance, under which you keep support for what exists and stop receiving new corrections, legal change updates and platform certifications. So the practical horizon is three years of premium-priced continuity and then a system that gradually stops matching the tax rules, the operating systems and the databases around it. The decision is about how much runway you buy and at what price, rather than about a cliff on a single day.
The obvious answer is the successor product from the same vendor. It is worth understanding what that path actually involves before treating it as the default, because it is a larger project than the phrase migration suggests.
What the successor path really requires
Three things complicate the move from APO to Integrated Business Planning, and none of them is a criticism of the target product.
It is fully realised alongside S/4HANA. IBP is designed to work with the newer ERP, and the older ECC platform is not the same architecture. Organisations still on ECC are looking at a platform migration first, which means the planning replacement has become the second half of an ERP programme rather than a project of its own.
Detailed production scheduling does not go to IBP. The PP/DS functionality moves into S/4HANA rather than into the planning suite. If your APO estate leans on detailed scheduling, that part of your planning capability is migrating into the ERP while the rest migrates into a separate cloud product, and the two have to be integrated afterwards.
That split has an operating model consequence worth thinking through before it is a surprise. A scheduler today can move an order in the detailed schedule and see what it does to the supply picture inside the same system, on the same data, in one sitting. Afterwards the sequencing change happens in the ERP and the supply plan lives in a cloud product on its own integration cadence. The question to put to anyone proposing the path is a specific one: what is the round-trip latency between a sequencing change and its appearance in the supply plan, and can the scheduler see the consequence of a change before committing it, or only after the next integration run. If the answer is the second, a task that was one decision becomes two decisions with a wait in the middle, and schedulers respond to that by keeping a local model, which is where the shadow spreadsheets come from.
It is not a lift and shift. The data model, the planning areas and the configuration approach differ. Existing macros, custom logic and heuristics built up over a decade of APO usage do not carry across, and the amount of embedded custom logic in a mature APO installation is usually larger than anyone remembers.
None of that makes it the wrong choice. It makes the effort estimate different from what a maintenance deadline conversation usually implies, and it means the timeline needs to start from the ERP position rather than from the planning one.
The four real options
Move to IBP and S/4HANA together. The most coherent end state if you were going to move the ERP anyway. Largest programme, longest timeline, and it consolidates two decisions into one. The risk is that planning capability becomes a workstream inside an ERP programme and gets whatever attention is left over, which is how planning requirements end up compromised.
Move to IBP on the current ERP where possible, ERP later. Reduces the immediate scope and accepts that some capability will be limited until the platform catches up. Sequencing the two rather than combining them, with the integration cost paid twice.
Replace planning with a specialist platform, keep the ERP decision separate. Planning runs alongside whatever ERP you have and publishes back through standard interfaces. Decouples the two decisions, which is the main attraction, and it means running a heterogeneous estate deliberately rather than by accident. The question to press hard on with any vendor here is what the integration back into the ERP actually looks like in practice, since that is where these arrangements succeed or become a maintenance burden.
Extend support and defer. Pay the premium, buy time. Legitimate as a deliberate choice with a plan attached, and dangerous as a way of avoiding the decision, because the option set narrows as the date approaches and implementation capacity in the market gets scarce.
Questions that decide it
Rather than a comparison table, here are the questions whose answers actually determine which path fits.
Where is the ERP decision? If S/4HANA is already committed with a date, the planning decision should probably follow it and the sequencing is largely settled. If the ERP move is undecided or years away, coupling planning to it means the planning deadline is now governed by a decision nobody has made.
How much custom logic is in the current planning estate? Count the macros, the custom heuristics, the exits. This number is the best available predictor of migration effort on any path, and organisations consistently underestimate it. It also tells you something more useful: a large amount of custom logic usually means the standard product did not fit the business, and that mismatch will recur unless it is understood.
Then count it a second way, because the two counts differ enormously and the gap is the cheapest money in the whole programme. The first count is how many custom objects exist. The second is how many of them actually execute. Switch on execution logging for one full planning cycle, ideally a month end, and record the distinct objects invoked. In an estate built up over a decade, a substantial share of macros were written for a process that changed, a product line that was sold, or a report nobody runs, and they sit in the system because deleting things is nobody's job.
The arithmetic follows directly from those two numbers. If a partner is scoping at something like two days per object for analysis, rebuild and test, then an estate of 414 objects is 828 days before any integration, data migration or testing at the programme level. Establish that 120 of those objects have not fired in twelve months and you have removed 240 days from the estimate, for the cost of running a log for a month. Do that before the statements of work are written rather than after, because scope removed during a programme is renegotiated and scope removed before it is simply absent.
Is detailed scheduling material to you? If PP/DS is doing real work, its move into the ERP is a structural change to how planning and execution are separated, and it deserves explicit attention rather than being treated as a module mapping exercise.
What is the planning capability gap you actually want to close? A forced migration is an opportunity to fix things that have been wrong for years, and it is also an opportunity to spend a large budget arriving where you already were. Being clear about which capabilities are genuinely missing, rather than migrating like for like, is what separates the programmes that return something from the ones that only avoid a support cliff.
What reads from the planning estate downstream? This is the dependency that gets found late on every one of these programmes. Reporting extractors, management packs and finance models frequently pull from planning data structures rather than from the ERP, and those consumers are invisible in a functional scope that lists planning modules. Ask for the list of extractors and interfaces reading from the planning system, with an owner against each, and expect the list to be longer than the planning team's own view of what they publish.
How much implementation capacity can you secure? There is a fixed pool of people who know both the old and new systems, and it is being drawn on by everyone facing the same date. Availability in 2027 will be considerably worse than availability now. The test that separates a firm with the people from a firm intending to hire them is a direct one: ask each candidate partner to name the individuals who would staff your programme, give their availability windows, and accept a key-person clause in the contract. Firms who have the staff agree to this without much discussion. Firms who are planning to recruit against your signature will explain why naming individuals is impractical at this stage, and that explanation is the answer.
A note on how this decision gets made
The deadline creates urgency, and urgency tends to compress evaluation. The pattern to watch for is a decision made on continuity grounds alone, where the successor is chosen because it is the successor, without anyone testing whether the planning capability it delivers is the one the business needs.
The counter to that is a narrower evaluation rather than a longer one. Pick the two or three planning capabilities where you are currently weakest, and test each option specifically against those on your own data rather than through a general functional comparison. A bake-off on your own history is a couple of weeks of work and it produces more decision-relevant information than a functional scoring matrix does.
There is a second pattern in the same family, and it costs more because it survives the whole programme. Requirements get written by describing what the current system does, so the document says the new system must produce the ZPP03 report and must allow the override field on the planning book to be populated during the weekly run. Nobody in the room can any longer say what business decision either of those supports, and both get built, and the workaround from 2014 is now a requirement in the 2028 system.
There is a straightforward filter. For every custom object and every stated requirement, ask the owner to state the business rule in one sentence without naming a transaction, a screen or a field. Anything that can be described that way is a real requirement and should be carried forward on its merits. Anything that cannot is a description of a workaround, and the person who could have explained it has usually left. The count of items in the second category is a decent proxy for how much of your migration budget is being spent reproducing history.
What I would say against my own interest
If your APO estate is stable, your customisation is modest, you are already committed to S/4HANA, and your planning pain is low, the successor path is likely the right answer and a specialist platform is an unnecessary complication. Heterogeneous estates carry a real integration cost and the cost recurs.
The case for looking outside the incumbent stack is strongest in a specific situation: your ERP move is not imminent, you have planning capability gaps that have persisted for years, and the deadline is going to force a large spend regardless. In that situation the decision is really about whether to spend the money reproducing what you have or improving it.
The one path I would argue against is deferral without a plan. Extended support buys time and does not buy options, and the constraint that will bite in 2027 is people rather than licensing.
Whichever way it goes, start with the count of custom logic in the current estate. It takes a week, it is the number every option's effort estimate depends on, and it is the one thing you will need regardless of which path you choose.