Part of the Replacing a consolidation or planning system: the complete guide series.
SAP BPC replacement is one of those decisions that arrives slowly and then all at once. A maintenance date lands in the calendar, a consolidation run takes longer than it should, or an auditor asks a question the system cannot answer cleanly. This guide sets out what your options actually are - without a shortlist and without a preferred destination.
Is SAP BPC going away?
SAP has not announced a like-for-like successor to BPC, but it has published maintenance end dates that make the timeline concrete. BPC 10.1 for Microsoft reached the end of mainstream maintenance in June 2026. BPC 10.1 for SAP NetWeaver has mainstream maintenance to 31 December 2027, with optional extended maintenance available to 31 December 2030. A maintenance date is a prompt for a decision and rarely more - it does not mean the system stops working on the day. What it does mean is that regulatory patches, security updates and support quality all change character once you are past it. For the fuller picture of what SAP has and has not committed to, see what SAP has actually published about BPC end of life.
Which BPC you are running, and why the replacement path differs
The starting point of a BPC migration shapes the project more than any destination platform does. The two lineages - BPC for Microsoft and BPC for NetWeaver (which includes the Standard and Embedded variants) - differ in where the data model lives, how much logic is held in script and in the EPM add-in, and how tightly the install is coupled to the ERP.
BPC for Microsoft runs on SQL Server and Analysis Services. The data model is largely self-contained, which means a migration is closer to a greenfield project: there is less ERP entanglement, but also less native ERP data flow to preserve. BPC for NetWeaver, and particularly the Embedded variant, sits inside the S/4HANA or BW landscape. That coupling makes the data flow more reliable in normal operation but makes the replacement conversation inseparable from the ERP roadmap. If you are on NetWeaver Embedded, you are not just replacing a planning and consolidation tool - you are making a decision about how the office of the CFO sits relative to the ERP for the next decade. Groups running BPC for Microsoft and groups running Embedded are not facing the same project, and a process that treats them identically will produce a flawed brief.
SAP BPC migration: what carries over, and what does not
Being clear about what survives a migration - and what should not - is the most useful preparation a finance function can do before any vendor conversation.
What carries over: master data structures and entity hierarchies; account mappings and chart-of-accounts logic; ownership percentages and consolidation scope; intercompany elimination definitions; and two years or so of closing history, enough to satisfy audit and to run prior-period comparatives on day one.
What does not carry over - and is better rebuilt: script logic and calculation rules written for BPC's own scripting language; business process flows built around the EPM add-in; EPM add-in report templates themselves; most manual journal workflows; and, critically, the workarounds that accumulated around all of them over years of live running. This last category is the one that matters most. Every organisation that has run BPC for more than five years has a layer of compensating controls and manual steps that exist because the system could not do something cleanly. Carrying those workarounds into a new platform carries the reasons you are leaving. The migration is the opportunity to decide which of them were process and which were patches.
The stay option
Running past mainstream maintenance is a legitimate decision, provided it is taken deliberately rather than by default. What changes when you do: the cadence and scope of security and regulatory patches narrows; extended maintenance carries an additional cost that varies by contract; the pool of consultants and internal staff who know the platform shrinks each year, which raises both recruitment cost and key-person risk; and the gap between BPC's data model and whatever the ERP is doing widens with each ERP release.
None of those are reasons to move immediately. They are costs that compound. If a group decides to stay - whether to use the NetWeaver extended maintenance window to 2030 or simply to run past Microsoft mainstream - it should write down four things: the decision and the rationale; the security and patch regime it will accept; the skills it needs to retain; and the trigger event that will reopen the conversation. A documented stay decision is a finance governance artefact. An undocumented one is a drift.
What is replacing SAP BPC in practice
Groups replacing BPC tend to take one of four broad routes, each with a different risk and cost profile. This section describes the shape of each category only - no product is named, no ranking is implied.
Stay on the same vendor's newer portfolio. SAP has a broader planning and consolidation portfolio, and some groups migrate within it. The commercial relationship is simpler; the technical migration is not necessarily simpler, because the data models differ. The ERP coupling question does not go away.
Move to a specialist consolidation and planning platform. Several mature platforms exist that were built specifically for group consolidation and planning rather than adapted from ERP. They tend to offer faster statutory close cycles and more auditable consolidation journals, at the cost of a longer initial configuration project and a new vendor relationship to manage.
Split consolidation from planning. Some groups conclude that one platform doing both is the wrong architecture - that statutory consolidation and management planning have different governance, different users and different data quality requirements. Splitting them allows each to be right-sized, but it adds an integration layer and a data reconciliation discipline that must be owned by someone in the finance function.
Simplify to the ledger plus a reporting layer. For groups with fewer entities and lower consolidation complexity, the answer is sometimes to push more of the work into the ERP ledger and sit a reporting and disclosure layer on top. This is the lowest total cost of ownership for the right group; it is the wrong answer for a group with material intercompany eliminations, currency complexity or CSRD consolidation obligations.
Before you let any vendor present against these categories, it is worth benchmarking where your finance function actually stands today. Benchmark your current state first with the 2-Minute Snapshot - it gives you a Finance Value Score across the whole office of the CFO, including your consolidation maturity, before any commercial conversation starts.
The questions to settle before any demo
The most expensive thing a group can do in a system replacement is let vendors set the terms of the conversation. These are the decisions that should be made - or at least framed - before any demo takes place.
Consolidation and planning together or apart? This is the architecture question. Answer it before you write an RFP.
How many legal entities and ledgers? The entity count drives configuration effort more than almost any other variable. Know it precisely.
Statutory versus management consolidation - or both? A platform optimised for statutory close under IFRS is a different thing from one optimised for management reporting. Many groups need both; few platforms do both equally well.
Who owns the model? After go-live, who configures new entities, changes hierarchies, updates ownership percentages? Finance or IT? The answer should drive the vendor conversation about tooling; the tooling should never drive the answer.
What history is needed on day one? Two years of closing balances is a common minimum for audit. More than that adds project cost and time without proportionate benefit in most cases.
What must the close look like on day one? A group that takes twelve days to close today and expects to close in five days on a new platform from month one is planning a change management programme as well as a system migration. The close target should be realistic about the process work that sits alongside the technology.
For guidance on how to size the project - durations, sequencing and the governance model - see the replacing-a-finance-system guide, which draws on implementations AIS has run. Duration and cost figures depend too heavily on entity count, data quality and scope to quote here without misleading you.
Common questions
When does SAP BPC go end of life?
SAP BPC 10.1 for Microsoft reached the end of mainstream maintenance in June 2026. SAP BPC 10.1 for SAP NetWeaver has mainstream maintenance to 31 December 2027, with optional extended maintenance to 31 December 2030. SAP has published no like-for-like successor product. These are maintenance dates, not switch-off dates - the software continues to run past them, but patch coverage and support quality change.
Can a group simply stay on SAP BPC past the maintenance end date?
Yes - running past mainstream maintenance is a legitimate decision if it is taken deliberately. Groups on the NetWeaver lineage have an extended maintenance option to 2030, which carries an additional cost. The risks that accumulate are narrowing patch coverage, rising skills scarcity and a widening gap between BPC's data model and the ERP roadmap. A documented stay decision with a defined review trigger is a governance artefact; drifting past the date without a decision is not.
What data actually migrates from SAP BPC to a replacement platform?
Master data structures, entity hierarchies, account mappings, ownership and consolidation scope, and approximately two years of closing history typically migrate. Script logic, EPM add-in report templates, business process flows and the workarounds accumulated over years of live running do not migrate well and are better rebuilt from first principles. Carrying the workarounds carries the reasons for leaving the old platform.