SAP Modernisation
SAP BusinessObjects in the Cloud: Three Routes Before BI 4.3 Support Runs Out
SAP BusinessObjects cloud options compared: BI 2025 on-premise or private cloud, SAP Analytics Cloud, or Power BI. Size your Web Intelligence estate first.
SAP BusinessObjects BI 4.3 leaves mainstream maintenance at the end of 2026, so on-premise estates now face three routes: upgrade to BI 2025 on-premise or in SAP's Private Cloud Edition, rebuild on SAP Analytics Cloud, or rebuild on Power BI. Size the Web Intelligence estate first. Usage, universe complexity and licence lock-in decide the route.
SAP's support knowledge base now carries an article titled "SAP BI Platform 4.3 - End of Mainstream Maintenance 31 December 2026". SAP's own training material for the platform explains that it is extending BI 4.3 mainstream maintenance until the end of 2026 so that security fixes are guaranteed until the end of 2027. After that, BI 4.3 moves into Customer Specific Maintenance, in which SAP describes delivering fixes for high and very high security issues (CVSS 7 or above) during the first year.
The same material sets out what replaces it. SAP BusinessObjects BI Platform 2025 opens what SAP calls a revised delivery cycle: minor releases every two years, with BI Platform 2027 planned for the first quarter of 2027, and mainstream maintenance for the platform guaranteed until at least the end of 2031. 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. 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, universes and the existing report estate.
The third is SAP Analytics Cloud, SAP's cloud service for analytics and planning. SAP's training material lists it as one of the solutions combined in SAP Business Data Cloud, 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.
What this means for you: the first two options change where BusinessObjects runs; the last two change what your users work in, and they carry very different cost and risk.
The Three Routes at a Glance
What this means for you: read the last column first; it tells you which estate profile each route suits before you read the argument for it.
| Route | What stays | What you rebuild | Licence model | Lock-in you accept | Choose this when |
|---|---|---|---|---|---|
| Upgrade to BI 2025, on-premise or PCE | Web Intelligence documents, universes, schedules, user habits | Platform: operating system, application server, licence keys | On-premise licences under SAP maintenance, with new BI 2025 licence keys, or an SAP-operated private-cloud package | Continued dependence on the BusinessObjects platform and its two-year release cycle | Web Intelligence carries heavy operational reporting and the estate has already been rationalised |
| Rebuild on SAP Analytics Cloud | SAP data sources and, during transition, existing universes through a live connection | Every report and dashboard, plus security and scheduling design | Cloud subscription, also available as part of SAP Business Data Cloud | Deeper commitment to SAP's cloud data and analytics stack | Analytics is SAP-centric, planning sits in the same programme, and the estate is dashboard-heavy rather than list-heavy |
| Rebuild on Power BI | Underlying databases and warehouses | Every report, plus universe logic re-expressed as Power BI semantic models | Per-user licences such as Pro and Premium Per User | Commitment to the Microsoft platform for analytics; SAP data reached through connectors | The organisation already standardises on Microsoft, and SAP is one source among several |
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
What this means for you: the number of reports in the repository is the least useful figure you have; the number that are run, by whom, and on what schedule, is the one that prices every route.
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
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 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. The split between the two is the single best 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
What this means for you: this is the lowest-change route for users, but it is a platform project with its own prerequisites, not a patch.
SAP's upgrade guidance states that 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 Platform 2025. Others perform a fresh installation and migrate their content. The prerequisites are where estates are caught out.
According to SAP's training material, BI Platform 2025 is supported only on Windows and Linux, with Solaris and AIX support removed. It runs only on the Tomcat application server; SAP NetWeaver application server support has been removed, and the Web Application Server Container is no longer packaged. SAP also states that all BI 4.x licence keys are no longer supported, and that a new licence key is required. 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 describes it as providing maintenance and support through 2027 and beyond, operated by SAP 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
With mainstream maintenance on the platform guaranteed until at least the end of 2031, BI 2025 is a supported destination in its own right. 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
What this means for you: SAP Analytics Cloud suits an SAP-centric organisation that wants analytics and planning in one cloud service, provided it accepts that Web Intelligence reports are rebuilt, not converted.
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.
A live connection to a universe keeps the old platform alive in order to leave it.
Where the fit is weakest
The friction tends to concentrate 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. Our SAP BusinessObjects and Analytics Cloud modernisation work starts from exactly that usage evidence.
Power BI answers the same rebuild question from outside the SAP stack.
Route Three: Rebuild on Power BI
What this means for you: Power BI is a strong target when Microsoft is already the organisational standard, but the universe logic has to be rebuilt as semantic models, and that is where the effort sits.
Microsoft's migration guidance for moving from another BI tool to Power BI 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. That is sound advice 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 by Microsoft 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.
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. Per-user licensing changes the economics compared with a platform licence: the cost now scales with the number of authors and consumers, so a rationalised estate with fewer, wider reports is cheaper to run than a faithful copy.
In practice
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.
Our data visualisation and BI dashboard practice builds that certified metric layer first and the reports on top. 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, BI 2025 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.
Where the reporting decision is tied to a wider ERP programme, our S/4HANA transformation team sequences the two so that reports are rebuilt once.
Frequently Asked Questions
Is there a cloud version of SAP BusinessObjects?
Yes, in two senses. SAP offers SAP BusinessObjects Enterprise, Private Cloud Edition, a package operated by SAP on the main hyperscalers that keeps Web Intelligence and universes. SAP Analytics Cloud is a separate cloud analytics and planning service, part of SAP Business Data Cloud, and moving to it means rebuilding reports rather than lifting the existing BusinessObjects content across.
When does support for SAP BusinessObjects BI 4.3 end?
SAP has extended mainstream maintenance for BusinessObjects BI 4.3 until 31 December 2026, so that security fixes are guaranteed until the end of 2027. After mainstream maintenance, the release moves into Customer Specific Maintenance. Maintenance terms can vary by contract, so confirm the dates that apply to your licence with SAP before fixing a programme timeline around them.
Can SAP Analytics Cloud use existing BusinessObjects universes?
Yes. SAP documents a direct live data connection from SAP Analytics Cloud to SAP BusinessObjects universes, which lets new stories use existing semantic definitions during a transition. The connection depends on a supported BusinessObjects platform remaining in service, so it is best treated as a temporary bridge while reports are rebuilt, not as a permanent architecture.
Should we migrate Web Intelligence reports to Power BI or SAP Analytics Cloud?
It depends on where your data and standards sit. SAP Analytics Cloud suits SAP-centric organisations that also want planning in the same service. Power BI suits organisations already standardised on Microsoft, where SAP is one source among several. In both cases, rationalise first: retiring unused and duplicated reports usually reduces the rebuild more than any choice of target.
How do you size a BusinessObjects estate before migrating?
Use twelve months of audit data to see which documents are actually opened or refreshed and by whom. Group near-duplicate documents, rate each live universe by complexity and owner, and count scheduled and burst reports with their recipients. Those four measures, rather than the raw document count, determine the cost of each route.
Unolabs is a Data and AI first engineering consultancy, headquartered in the United Kingdom with engineering operations in Pune and active engagements across the UK, Australia, and Hong Kong. We help enterprises build the architectural foundation for autonomous AI execution — governed data platforms, semantic intelligence, and agentic systems that enterprises can stand behind.
If you are weighing where your BusinessObjects estate should go after BI 4.3, book a discovery call and we will work through it with you.
More Where
This Came From.
New architectural deep-dives land every two weeks. Pick your channels and we will send them as they publish.
Continue reading
- SAP ModernisationS/4HANA by 2027: Protecting the Analytics Estate During ConversionAn ECC to S/4HANA conversion changes the tables, extractors, and embedded analytics your reporting depends on. Here is the continuity playbook.11 min read
- SAP ModernisationSAP BW Bridge or Full Datasphere Migration? Choosing the Route by Reuse, Cost and Lock-inSAP BW migration has three routes: BW Bridge, a native Datasphere rebuild, or a staged hybrid. Compare reuse, cost and lock-in, then choose on evidence.16 min read
- SAP ModernisationSAP BW to Datasphere Migration: The 2027 Decision GuideSAP BW 7.5 mainstream maintenance ends 31 December 2027. An honest guide to the four realistic paths and how to decide between them.15 min read
Size your Web Intelligence estate before you pick a route
We will read your BusinessObjects usage, universe and schedule data and tell you how much of the estate is worth carrying, and which of the three routes it points to.
Book a BusinessObjects Sizing