SAP BusinessObjects End-of-Life 2027: Your Power BI Migration Checklist
SAP BusinessObjects mainstream maintenance ends in 2027. For UK organisations that built their reporting estate on SAP BO over the past decade or two, this is a real deadline with real consequences — not just a vendor roadmap note to file away. This guide gives you the practical steps to plan and execute the migration successfully, drawn from 16+ years of hands-on SAP BO and Power BI work in UK enterprises.
What "end-of-life" actually means for your organisation
SAP has committed to mainstream maintenance for SAP BusinessObjects BI Platform 4.3 until December 31, 2027. After that date:
- No new patches or security fixes will be released
- Support tickets will not be accepted for product defects
- Third-party integrations (especially with newer data sources and OS versions) will progressively break
- Licensing costs typically increase as you move to extended maintenance
The organisations that will be hurt most are those that wait. A migration of 200+ reports, complex universes and row-level security configurations cannot be executed in six months under pressure. The organisations that start planning in 2025 will migrate calmly. Those that start in Q4 2027 will be making expensive compromises.
The migration checklist — phase by phase
Audit your current SAP BO estate
Before anything else, you need to know what you have. This is typically the most underestimated phase.
- Export a full report inventory from the CMC — report name, owner, last run date, schedule frequency, universe
- Identify "zombie reports" — reports that have not been run in 12+ months and can be archived rather than migrated
- Classify reports by criticality: operational (run daily/weekly), analytical (run monthly), ad hoc
- Document all universes and their underlying data sources (SAP BW, SQL Server, Oracle, etc.)
- List all scheduled distributions — email bursting, BI Inbox, file system exports
- Identify reports with complex row-level security (RLS) or object-level security requirements
- Document any Crystal Reports that are embedded in SAP BO or run standalone
Common discovery finding: In most SAP BO estates we audit, 30–45% of reports have not been accessed in over a year. Migrating them wastes budget. Archive them first, migrate only what is genuinely used.
Design your Power BI semantic layer
The biggest mistake in SAP BO migrations is rebuilding universes as Power BI datasets report-by-report. Instead, design a shared tabular model first.
- Map SAP BO universes to Power BI tabular semantic models — one model per subject area (Finance, HR, Sales, Operations)
- Identify which metrics from SAP BO universe objects translate to DAX measures — these need to be rewritten, not copied
- Design a star schema for each model — SAP BO's multi-source joins do not translate directly
- Confirm Power BI Premium or Fabric capacity requirements for large datasets
- Set up dataflows (or Fabric pipelines) for shared transformation logic to avoid duplication across reports
- Plan row-level security roles in Power BI — Dynamic RLS using DAX USERNAME() function
Establish your Power BI governance framework before you migrate
One of the costliest errors is migrating reports into an ungoverned Power BI workspace structure, then spending 18 months cleaning it up afterwards.
- Define workspace taxonomy — one workspace per department or business domain, not one per report author
- Set up Power BI deployment pipelines (Dev → Test → Production) to match your change control process
- Define certified vs promoted vs informal dataset labels
- Configure sensitivity labels in Microsoft Purview aligned to your data classification policy
- Set up lineage tracking so report owners can see which datasets their reports depend on
- Define a dataset ownership model — who is accountable for each semantic model
- Document your naming conventions before migration (workspace, dataset, report, measure naming)
Migrate reports in priority order
Migrate operational reports first — they have the clearest requirements and the most visible impact.
- Rebuild Tier 1 (operational) reports in Power BI — do not use automated conversion tools for complex reports; the output is unreliable
- Validate calculated fields: every SAP BO formula must be revalidated in DAX against source data
- Reconcile numbers: run SAP BO and Power BI reports side-by-side for one full reporting cycle before decommissioning BO
- Migrate Tier 2 (analytical) reports — these typically involve more complex date intelligence and year-over-year calculations
- For scheduled distributions, set up Power BI subscriptions and Power Automate flows to replace BI Inbox bursting
- Migrate Crystal Reports to Power BI paginated reports (PBRS) — pixel-perfect layouts require SSRS/paginated, not standard Power BI
- Archive Tier 3 (unused) reports — do not migrate, document and store in SharePoint
Train your team so they can maintain it independently
A migration that leaves the organisation dependent on external consultants is only half-complete.
- Train report authors on Power Query and basic DAX — these are the two skills most SAP BO universe designers are missing
- Train Power BI administrators on capacity management, refresh monitoring, and gateway configuration
- Document each migrated semantic model with a data dictionary — table names, relationships, key measures with business definitions
- Establish a Power BI Champions network within the business to handle ad hoc report requests without bottlenecking IT
- Set a hard cutover date for SAP BO decommission — without a deadline, BO stays running "just in case" indefinitely
Common pitfalls we have seen repeatedly
Migrating universes as-is. SAP BO universes contain years of accumulated complexity — tables joined for convenience, columns added without documentation, calculated objects that no one fully understands. Power BI migrations are an opportunity to rationalise. Rebuild from source, not from the universe.
Underestimating DAX complexity. SAP BO's measure definitions are often simple aggregations. In Power BI, moving to a tabular model requires rewriting those as DAX — a different syntax with its own evaluation context rules. Budget time for this.
Skipping UAT. Users who have worked with SAP BO numbers for years will notice discrepancies. Run a formal user acceptance testing phase with a reconciliation spreadsheet. Document every variance and resolve it before cutover.
Ignoring scheduled reports. SAP BO schedule subscriptions are often invisible to the IT team but critical to the finance team that receives them at 7am every Monday. Audit all schedules before migration and rebuild every one of them in Power BI subscriptions or Power Automate.
How long does a migration take?
A typical UK mid-market organisation with 100–300 SAP BO reports, 3–5 universes, and 20–50 active report consumers should plan for 4–8 months end-to-end for a well-governed migration. This includes discovery, semantic model design, migration, UAT, training, and cutover.
Organisations with Crystal Reports estate, complex RLS, or SAP BW as their primary data source should add 2–3 months to that estimate.
Planning a SAP BO to Power BI migration?
Book a free 30-minute call. We will review your current SAP BO estate, scope the migration effort, and give you an honest timeline and cost estimate — no obligation.
Book free scoping call →