SAP Modernisation
SAP BusinessObjects After 2026: Stay, Move to SAC or Power BI?
SAP ends BI 4.3 mainstream maintenance on 31 December 2026, and what your Web Intelligence estate holds decides between BI 2025, SAP Analytics Cloud (SAC) and Power BI.
AI tools helped draft and edit this story. It is adapted from my article first published on the Unolabs blog on 9 October 2026, and each figure names its source.
SAP BusinessObjects BI 4.3 leaves mainstream maintenance on 31 December 2026, per SAP’s BI Statement of Direction (October 2026). Estates can upgrade to BI 2025, then BI 2027, on-premise or in Private Cloud Edition, or rebuild on SAP Analytics Cloud or Power BI. At Unolabs, we recommend sizing the Web Intelligence estate first: usage, universe complexity and licence lock-in decide the route.
The full article follows. For more depth, the original on the Unolabs blog adds its FAQ and the related guides it links. This link takes you off Medium: unolabs.com/blog/sap-businessobjects-cloud-options
SAP Knowledge Base Article 3763590 is titled “SAP BI Platform 4.3 — End of Mainstream Maintenance 31 December 2026”. The Statement of Direction explains what follows: once mainstream maintenance ends, BI 4.3 moves into Customer Specific Maintenance, in which SAP delivers fixes for high and very high security issues (CVSS 7.0 or above) during the first year. That makes the end of 2027 the last guaranteed security fix under SAP’s BI Statement of Direction (October 2026).
The same document sets out what replaces it. SAP BusinessObjects BI 2025 opens what SAP’s BI Statement of Direction (October 2026) calls a revised delivery model: minor releases every two years, with BI 2027 planned as the next, and mainstream maintenance for the platform guaranteed until at least the end of 2031, with each minor release receiving three years of mainstream maintenance. The product is not being retired. The 4.3 release is.
Failure mode: The date that matters is not the one on the slide. End of 2026 removes mainstream maintenance from BI 4.3; end of 2027 is the last guaranteed security fix (SAP BI Statement of Direction, October 2026). An estate that has not chosen a route by early 2027 is choosing under a security deadline, not a planning one. Confirm the current dates for your own contract with SAP.
That makes this a decision about the reporting estate, not about a server. SAP Analytics Cloud is often presented as the default answer. It may be the right one, but only an inventory of what the estate holds and how it is used can show that. What follows defines the options, sets out how to size a Web Intelligence estate, and compares the three routes on report volume, universe complexity, Web Intelligence dependence, licence model and lock-in.
What “SAP BusinessObjects in the Cloud” Actually Means
The phrase covers four different things, and vendors and advisers move between them freely. Two keep BusinessObjects; two replace it.
The first is BusinessObjects installed on cloud infrastructure that you run yourself. Nothing about the product changes; only the data centre does. The second is SAP BusinessObjects Enterprise, Private Cloud Edition (PCE), which SAP describes as a predefined package operated by SAP on the main hyperscalers, covering the software, support, managed services and infrastructure. Both keep Web Intelligence (the BusinessObjects query and reporting tool), universes (its semantic layer) and the existing report estate.
The third is SAP Analytics Cloud, SAP’s cloud service for analytics and planning. SAP’s launch announcement for SAP Business Data Cloud (February 2025) lists it as one of the solutions the offering combines, alongside SAP Datasphere, SAP BW and SAP Databricks. It is a different product with a different authoring model, so moving to it means rebuilding reports rather than lifting them. The fourth, Power BI, is Microsoft’s equivalent and implies the same rebuild in a non-SAP toolset.
The Three Routes at a Glance
The routes are not mutually exclusive. SAP documents a direct live data connection from SAP Analytics Cloud to BusinessObjects universes, which lets new stories sit on existing semantic definitions while the platform underneath is still running. That staged option exists only for the SAP route, and only while a supported BusinessObjects platform is there to connect to.
A hosting decision and a rebuild are being sold under the same name.
None of those columns can be filled in for your estate without knowing what it actually contains.
How to Size a Web Intelligence Estate Before You Choose
Report counts in BusinessObjects estates are inflated by design. Users save personal copies, teams clone documents to change one filter, and schedules keep running after the person who set them up has left. A count taken from the repository describes years of accumulation, not current demand.
The inventory has four dimensions, and each changes the cost of a different route.
- Usage. Which documents were opened or refreshed in the last twelve months, by how many distinct users, and from which departments. Unused content is retired, not migrated.
- Duplicates. Documents that share a universe, a query and most of a layout. Clusters of near-copies collapse into one parameterised report on any target platform.
- Universes. How many universes are live, how many tables and joins each holds, and how much business logic sits in derived objects, contexts and filters rather than in the database.
- Schedules and distribution. Which documents are scheduled, burst to many recipients or delivered as files. This is the operational load that a dashboard tool has to absorb.
Usage evidence comes first
The first thing I check is whether auditing is switched on, and how much usage history it holds. BusinessObjects records platform activity in its auditing data, and that history is the most valuable artefact in the whole exercise. Twelve months of it shows which documents are opened, which are only refreshed by schedules, and which have not been touched at all. Without it, every stakeholder will describe their reports as critical, and none of them will be lying on purpose.
Universes decide the rebuild cost
A semantic layer is the shared business definition of measures and dimensions that sits between the database and the report. In BusinessObjects that layer is the universe, and it often holds more logic than anyone remembers: derived measures, contexts that resolve join loops, and row restrictions that enforce security. Moving to BI 2025 carries it across. Moving to SAP Analytics Cloud or Power BI means re-expressing it, which, in our engagements, is usually the largest single cost in the rebuild.
Readiness signal: Your inventory is complete when: Every document is tagged as used, duplicated or unused; every live universe has a named owner and a complexity rating; and every schedule has a recipient list someone has confirmed is still needed. If any of the three is missing, the route decision is a guess.
Schedules reveal Web Intelligence dependence
An estate where most activity is interactive analysis maps well to a dashboard tool. An estate where most activity is scheduled, multi-page tabular output sent to hundreds of recipients behaves like an operational reporting system, and it needs a target that does that job well. In our experience, the split between the two is the best single predictor of which route will cost less to run afterwards.
With the inventory in hand, each route can be priced honestly, starting with the one that changes least.
Route One: Upgrade to BI 2025, On-Premise or in Private Cloud
Under SAP’s BI 2025 release documentation, customers on BI 4.2.x or BI 4.3.x can perform an in-place update, provided their operating system is still supported by BI 2025. Others perform a fresh installation and migrate their content. The prerequisites are where estates are caught out.
Get Akshay Raz’s stories in your inbox
Join Medium for free to get updates from this writer.
The same documentation confirms that BI 2025 is supported only on Windows and Linux, with Solaris and AIX support removed, and that SAP NetWeaver application server support and the Web Application Container Server have been removed. BI 2025 runs on its bundled Tomcat, with IBM WebSphere Liberty 25 the only supported external Java application server; from BI 2027, the Statement of Direction says, SAP will rely on embedded Tomcat alone. SAP Knowledge Base Article 2282189 states that a new licence key is required when updating to BI 2025 from an earlier version. SAP publishes a list of products and features removed in BI 2025; check every component your estate uses against it, legacy universe formats and add-ons included.
When Private Cloud Edition fits
PCE moves the operational burden, not the product. SAP operates it on the main hyperscalers. For an organisation whose BusinessObjects team is small and whose infrastructure is due for refresh anyway, that can be the most defensible route. It does nothing to reduce report sprawl, so the inventory still matters: an unrationalised estate in PCE is the same estate, hosted somewhere else.
Key idea: Staying is a legitimate choice, not a deferral. SAP’s BI Statement of Direction (October 2026) guarantees mainstream maintenance for the platform until at least the end of 2031, but each minor release gets three years of it, so staying means BI 2025 now and BI 2027 after it. Choosing it deliberately, after rationalising the estate, is a different decision from drifting onto it because nobody chose.
The second route trades that continuity for a different set of commitments.
Route Two: Rebuild on SAP Analytics Cloud
The case for it is strongest where the data already lives in SAP. Stories built on SAP data sources keep business semantics close to the systems that create them, and SAP’s positioning of SAP Analytics Cloud within SAP Business Data Cloud means the warehouse, modelling and reporting layers are bought and governed together. For an organisation already moving warehouse content to SAP Datasphere, it is the natural reporting tier; the warehouse side of that decision is covered in our guide to moving from SAP BW to Datasphere.
The live-universe bridge, and its limit
The direct live connection to universes is the most useful transition tool on this route. It lets teams build new stories against definitions users already trust while the rebuild proceeds domain by domain. It is a bridge, not a destination: it depends on a supported BusinessObjects platform staying up, so it extends the life of the platform you are trying to leave. The step-by-step execution of this route, from inventory to decommission, is set out in our guide to migrating BusinessObjects to SAP Analytics Cloud.
A live connection to a universe keeps the old platform alive in order to leave it.
Where the fit is weakest
In our experience, the friction concentrates on large, list-style operational reports: wide tables, many pages, burst to many recipients on a schedule. Dashboard-oriented tools are built for interactive analysis first. Before committing, prototype the three heaviest scheduled Web Intelligence documents from the inventory on the target and test them with the people who receive them.
Power BI answers the same rebuild question from outside the SAP stack.
Route Three: Rebuild on Power BI
Microsoft’s Power BI migration overview (Microsoft Learn, 2024) is explicit on the point that matters most. It advises against strictly attempting to migrate reports precisely as they appear in the legacy platform, and recommends focusing on the business question each report answers. In our view, that advice holds for any route, and it is a direct argument for rationalising before rebuilding.
Two Power BI capabilities map to the two halves of a Web Intelligence estate. Interactive reports run on Power BI semantic models, which take over the role of the universe. Paginated reports, authored in Power BI Report Builder, are described in Microsoft’s paginated reports overview (2025) as designed for printing or sharing, displaying all the data in a table even when it spans multiple pages, with exact control of page layout. They support email subscriptions with a PDF of the whole report, which covers much of what scheduled Web Intelligence documents do today.
If the destination itself is still open, our comparison of Power BI, Tableau and SAP Analytics Cloud as enterprise BI platforms weighs the three against data-source fit, governance and licence shape.
What the licence model implies
Microsoft states that licence requirements for paginated reports are the same as for Power BI reports, and that a Pro or Premium Per User licence is needed to publish paginated reports to workspaces other than My Workspace. In our view, per-user licensing changes the economics: the licence bill follows the number of authors and consumers, so rationalisation pays back mainly in rebuild and maintenance effort.
In practice: Keep SAP semantics in one place. Power BI reaches SAP data through connectors such as Microsoft’s SAP BW connector, but the business definitions still have to live somewhere. We place them in governed semantic models built once, rather than in each report, so finance and operations do not rebuild the same measure twice.
Whichever rebuild route wins, though, there are estates for which neither should be chosen yet.
When to Stay On-Premise
Staying on BusinessObjects, upgraded to BI 2025, is the better answer in four situations.
The first is an estate dominated by scheduled operational output. If most usage is burst, multi-page reporting that runs the business each morning, rebuilding it on a dashboard-first tool spends money to recreate what already works. Upgrade, rationalise, and revisit at the next minor release.
The second is an ERP conversion in flight. If the organisation is moving to SAP S/4HANA, the source structures beneath the universes are already changing, and rebuilding reports on top of a moving foundation doubles the testing. Our account of keeping reporting intact through an S/4HANA conversion sets out why the analytics layer should follow the conversion, not race it.
Rebuild reports on a moving source and you test them twice.
The third is data residency or contractual constraints that rule out a public cloud analytics service for some content. PCE or self-managed infrastructure keeps that content on terms you control. The fourth is a rationalised estate with stable universes and no appetite for a rebuild. If the inventory shows a few hundred well-used documents on clean universes, staying on the platform, BI 2025 then BI 2027, may simply be the cheapest supported answer for the next several years.
Where to Start on Monday
The route decision should take weeks, not a year, if the evidence exists. Gathering the evidence is the part that cannot be skipped.
- Export twelve months of usage. Pull audit history for every document and universe. If auditing has been switched off, switch it on now; a quarter of data is better than none.
- Classify the estate. Tag each document as used, duplicated or unused, and each universe by complexity and owner. A scoped data strategy assessment can set the decision rights for who signs off retirement.
- Measure the schedule load. Count scheduled and burst documents and their recipients. This is the figure that separates the routes.
- Prototype the hardest three. Rebuild the three heaviest operational reports on each candidate target and test them with their actual recipients.
- Decide, then move in waves. Retire unused content first, then migrate by domain with reconciliation against the old output. A migration factory approach runs those waves with scripted comparison and rollback, rather than analysts checking totals by eye.
If you have sized a BusinessObjects estate, what share of the repository had actually been opened in the previous twelve months?
The original also carries a five-question FAQ: whether there is a cloud version of SAP BusinessObjects, when BI 4.3 support ends, what changes in BI 2025, whether to move Web Intelligence reports to Power BI or SAP Analytics Cloud, and how to size an estate before migrating. It links the related guides on BW to Datasphere, BusinessObjects to SAP Analytics Cloud, and a comparison of Power BI, Tableau and SAP Analytics Cloud.
The original, first published on 9 October 2026, is on the Unolabs blog. This link takes you off Medium: unolabs.com/blog/sap-businessobjects-cloud-options
