Short answer: it’s a project, not a patch. SAP supports an in-place upgrade from BI 4.3 to BI 2025 (SAP KBAs 3739732 and 3654924 cover the reference paths), and BI 2025 has been shipping since March 2025. But BI 2025 also removes UNV universes, multi-source universes, Live Office, Analysis for OLAP, and Crystal Reports for Enterprise, and it needs a new license key. So the real SOP is: inventory first, remediate what dies, then upgrade with a parallel run. With BI 4.3 mainstream maintenance ending December 31, 2026, you have time to do this properly, but not time to start late. The full sequence is below.

Why the SOP question keeps going unanswered

Ask a BusinessObjects forum for the upgrade steps and you’ll usually get silence, or a link to release notes. The official documentation tells you how to run the installer. It doesn’t tell you what to check first, what breaks, how long it takes, or how to keep reporting alive while you cut over. That gap is exactly what an SOP should cover, so that’s what this one does.

Step zero

The pre-upgrade inventory

Every failed BusinessObjects upgrade we’ve been called into skipped this stage. Before anyone touches an installer, you need six lists. Together they tell you whether your upgrade is a six-week job or a six-month one.

1. Universes

   Count UNV separately from UNX. UNV universes do not exist in BI 2025, so every UNV must be converted to UNX before you upgrade, and conversions need testing because report behavior can shift. Flag multi-source universes too: they’re also removed.

2. Reports

   Full Web Intelligence document list with last-run dates. Most estates find 30 to 60 percent of documents haven’t run in a year. Retire them before the upgrade, not after. Inventory Crystal Reports separately: Crystal Reports for Enterprise is gone in BI 2025, so those reports need a remediation plan.

3. Schedules

   Every recurring schedule, its owner, its destination (email, file share, SFTP), and its expiry date. Schedules are the thing users notice first when an upgrade goes wrong.

4. Security model

   Groups, folder rights, row-level restrictions, and any custom access levels. Export it, document it, and decide who re-validates it after cutover.

5. Integrations

   Live Office and Analysis for OLAP are removed in BI 2025. Find every workbook and workflow that depends on them now, because those users lose functionality on day one unless you plan replacements. Also list SSO configuration, SDK customizations, and anything calling the RESTful API.

6. Platform stack

   OS version, database version for the CMS repository, Java, and web tier. Check each against the BI 2025 Product Availability Matrix. A supported 4.3 stack is not automatically a supported BI 2025 stack.

the inventory decides the timeline. skip it and the timeline decides itself

The runbook

The upgrade sequence

This is the runbook shape we use. SAP supports an in-place install over 4.3, but for production estates we recommend a side-by-side build with a content promotion, because it gives you a rollback that actually works.

1. 1. Complete the inventory aboveSize the remediation work. This step sets the timeline for everything else.
2. 2. Remediate deprecations on 4.3 firstConvert UNV to UNX, redesign multi-source universes, retire dead reports, plan Live Office and AOLAP replacements. Doing this before the upgrade means you’re testing one change at a time.
3. 3. Request the license key, check the PAMConfirm your OS, database, Java, and web tier against the BI 2025 Product Availability Matrix. Order any infrastructure now.
4. 4. Take full backups, then restore oneCMS system database, audit database, filestore (Input and Output FRS), and server configuration. An unverified backup is a hope, not a rollback plan.
5. 5. Build the BI 2025 environmentFresh install on new infrastructure, or in-place on a cloned copy of production first if you’re taking the supported in-place path. Never run your first in-place upgrade against live production.
6. 6. Promote content in a defined orderPromotion Management or a full CMS copy, depending on path. Universes, connections, reports, schedules, users, security. Reconcile counts against your inventory.
7. 7. Re-point and re-test integrationsSSO, database connections, SDK jobs, API consumers, delivery destinations. This is where http 500 errors and blank login screens live. Test the web tier under real user load, not one admin login.
8. 8. Run validation with real usersA representative report set per department, checked against the same reports on 4.3: data values, formatting, prompts, scheduling output. Sign-off per department, in writing.
9. 9. Parallel-run both platformsTwo to four scheduling cycles (see below), then cut users over in waves.
10. 10. Decommission 4.3Only after a full month-end, or your longest reporting cycle, has completed cleanly on BI 2025. Keep the final backups.

Where these upgrades actually fail

Five failure points come up again and again, and only one of them is the installer.

• The SIA doesn’t come back. The clearest early-adopter report of a failed in-place 4.3 to BI 2025 upgrade is the Server Intelligence Agent stopping immediately after start, surviving both a repair and a new node. Others who completed the same jump found servers silently deleted from the CMS and #TOREFRESH errors across Web Intelligence documents. This is the single strongest argument for building side by side: if the SIA doesn’t start, an in-place upgrade leaves you with no reporting platform at all.
• UNV conversion side effects. Converted universes can change report behavior in subtle ways: aggregate handling, prompt behavior, list-of-values performance. Some teams have also seen conversion affect the source UNV, so always convert from a copy. Regression-test reports, not just universes.
• The web tier. Fresh BI 2025 installs failing with http 500 errors is a known early-adopter pain. Almost always it’s the Java version, the web application server configuration, or a certificate, not the BI platform itself. Validate the stack against the PAM before blaming the product.
• Schedules and destinations. Schedules that promote cleanly but point at the old server’s file paths, or SMTP settings that never got copied. Users experience this as “the upgrade broke my reports” even though every report runs fine on demand.
• Security drift. Custom access levels and folder rights that don’t promote exactly, leaving users either locked out or seeing too much. Re-validate the security model against your inventory export, don’t assume.

The parallel-run strategy

Keep 4.3 and BI 2025 running side by side through at least two full scheduling cycles, including one month-end. During the parallel window: schedules run on both platforms, users work on BI 2025, and 4.3 is the fallback. Compare scheduled outputs daily. When a full cycle completes with zero unexplained differences, you cut over for real. The parallel run is the insurance that makes an aggressive timeline safe, so don’t cut it to save two weeks.

Planning bands, not promises

How long does it take?

Your inventory moves every number below. Find the profile that matches what you actually found in step zero.

Work backwards from December 31, 2026. A heavy estate starting in mid-2026 is already relying on the security-fix year. After mainstream maintenance ends, SAP provides one further year of security fixes for high-severity vulnerabilities only (CVSS 7.0 and above), and then Customer-Specific Maintenance. That’s a narrowing safety net, not an extension.

When to bring in help

Plenty of teams run this upgrade themselves, and if your estate is in the clean-and-small band, you probably should. Bring in outside help when any of these are true: your inventory turned up a large UNV or Live Office footprint, your BO admin count is one (or zero, after attrition), you can’t afford a failed month-end, or the same team that must run the upgrade is already underwater running daily operations. That last one is the most common. The upgrade doesn’t fail for technical reasons; it fails because nobody had two free days in a row.

That’s the work we do. TechTiera has 30+ BusinessObjects consultants, 20+ years on the platform, 24×7 coverage, and a 2 to 4 week support takeover that runs in parallel with your incumbent team, so the upgrade gets dedicated hands while daily operations keep running.

Frequently asked questions

Is there an official SOP or runbook from SAP for the 4.3 to BI 2025 upgrade?

SAP publishes the upgrade reference and how-to as knowledge base articles (KBAs 3739732 and 3654924 are the starting points) plus the installation guides. They cover the supported paths and the installer. They don’t cover inventory, deprecation remediation, parallel-run design, or timeline planning, which is why the sequence in this article exists.

Can we upgrade in place, or do we need new servers?

In-place installation over 4.3 is a supported path, and the early field reports are the reason we still recommend side-by-side for production estates. An in-place run that stalls (a halted installer, an SIA that won’t restart) leaves you with no working platform and only your backups. Side by side gives you a genuine rollback and a parallel-run window. If you do go in-place, rehearse it on a cloned copy of production first and verify your backups restore before you start.

What happens to our UNV universes?

UNV universes are removed in BI 2025, along with the Universe Design Tool workflow that maintains them. Convert each UNV to UNX using the Information Design Tool before the upgrade, always working from a copy, and regression-test the reports that depend on each converted universe. Converted universes can behave slightly differently, so test reports, not just the universe itself.

Is BI 2025 stable enough to move to now, or should we wait for BI 2027?

BI 2025 shipped in March 2025 and early adopters are running it in production, with the usual early patch-level friction (“no upgrade is ever seamless” is a fair summary from the field). BI 2027 timing is quoted anywhere from late 2026 to Q1 2027 depending on the source, which is right at or past the 4.3 deadline. Planning a 2027 upgrade means planning to run 4.3 unsupported, so for most estates BI 2025 at a current patch level is the realistic target. SAP has since committed to BI 2027 and BI 2029 with maintenance into the 2030s, so this is not a dead-end platform.

How does patching change in BI 2025?

Service Packs are gone. BI 2025 ships patches on a rolling 6 to 8 week cadence, so your patch process becomes a routine instead of an annual event. Plan for it: a standing patch window, a regression set you can run quickly, and a test environment that stays close to production. The Priority One support tier was also removed, so check what your support contract actually entitles you to before you rely on it during cutover.

Do we need a new license key for BI 2025?

Yes. BI 2025 requires a new license key; your 4.3 key doesn’t carry over. Request it from SAP early in the project. 90-day emergency keys exist if you get stuck, but treat them as a contingency, not a plan.

Our fresh BI 2025 install ends with an http 500 error. Is that normal?

It’s a common early-install symptom, and it’s almost always the surrounding stack rather than the BI platform: an unsupported Java version, a web application server misconfiguration, or a certificate problem. Check every component against the BI 2025 Product Availability Matrix, review the tomcat and platform logs, and validate the web tier separately before reinstalling anything.

We’re still on 4.2, not 4.3. Does this SOP apply to us?

The shape applies but the path is longer: 4.2 is already out of support, so you’re running without fixes today. Depending on your patch level you may step through 4.3 on the way to BI 2025, and your deprecation exposure (UNV especially) is usually larger. The inventory stage matters even more for you, and the calendar pressure is higher because your unsupported window has already started.

How do we keep schedules and publications safe through the upgrade?

Inventory every recurring schedule with its owner, destination, and expiry date before you start. After promotion, reconcile the schedule count against that inventory, re-test destinations (file paths and SMTP settings frequently point at the old environment), and run at least two full scheduling cycles in parallel before decommissioning 4.3. Expiring schedules are worth a sweep too: schedules that quietly lapse mid-project get blamed on the upgrade.

Further reading

• Should You Leave BusinessObjects for Power BI?
• BO 4.3 After December 2026: Your Four Options