SAP BusinessObjects to Power BI migration
Fixed-fee SAP BusinessObjects to Power BI migration for US small and mid-size businesses, delivered by senior US-based Microsoft engineers: we read your universes as a specification and rebuild them as a governed semantic model, rebuild Web Intelligence documents as Power BI reports, re-express universe security profiles as row-level security, and replace scheduled instances and publications with refresh schedules and subscriptions — one written price, typical delivery in 2–4 weeks, 30 days of hypercare included.
Representative dashboard — sample data
What you get
BusinessObjects already has a governed modeling layer. Reading it properly is what separates a rebuild that reconciles from one that argues with itself for a quarter.
Objects, joins, contexts, derived tables and aggregate awareness are inventoried and re-expressed as a Power BI star schema with declared cardinality and one active filter path — not lifted object-for-object into a flat table.
Each .wid document is split the way Power BI expects: the query panel becomes model queries, report variables become measures, and sections, breaks and input controls become slicers, grouping and drill-through.
Report-local variables that were quietly redefined in eleven different documents get settled once, as named measures on the shared model, and reconciled against the figure your Webi document produces today.
Data and business security profiles applied at the universe move into security roles with DAX filter expressions on the semantic model, so the same person sees the same rows regardless of which report they open.
Scheduled instances become refresh schedules and subscriptions. Publications that burst a document by recipient are rebuilt as one secured report or as paginated reports delivered on a schedule — whichever the audience actually needs.
Every phase ends with your numbers side by side against the live BusinessObjects report. Agreed check figures have to match before anyone calls a phase finished or switches off a scheduled instance.
How it works
A free consultation plus a pass over your universes, Web Intelligence documents, publications and CMC groups shows where the logic and the audiences actually live. You get a written scope, a phase plan, one fixed price and a delivery date.
We build the star schema and its Power Query queries from the universe first, re-derive variables into DAX measures, rebuild each phase's documents as report pages, and reconcile them with your team against the live Webi numbers.
Reports publish to your workspace with row-level security, a refresh schedule and a gateway where sources stay on-premises. Once the final phase is signed off you get the decommission list, and we stay on for 30 days of hypercare.
Most of the organizations asking us about this are on BusinessObjects BI 4.3, and they are asking now for a specific reason: 4.3 leaves mainstream maintenance on 31 December 2026. Priority security fixes continue through 2027, after which the release moves to Customer-Specific Maintenance. That is a real, dated fork in the road, and it is the honest reason this page exists.
It is not, however, the end of the product, and you should be sceptical of anyone who tells you it is. SAP has confirmed further releases — BI 2025, BI 2027 and BI 2029 — with mainstream maintenance running to at least the end of 2031. Staying on BusinessObjects is a legitimate answer. What is no longer available is doing nothing: a 4.3 estate has to be upgraded or moved, and this is simply the moment when it is cheapest to ask which of the two is right for you.
Our bias, stated plainly: if BusinessObjects is genuinely load-bearing for a large finance or supply-chain function running against SAP BW, an in-place upgrade is often the cheaper answer and we will say so. Where a move to Power BI usually wins is the case we see most often in small and mid-size US organizations — a Microsoft 365 tenant already paid for, a BusinessObjects estate down to a few dozen documents that anyone still opens, and nobody left in-house who is comfortable in the Information Design Tool.
This is the single thing that makes a BusinessObjects migration different from a Tableau or QlikView one. Those platforms scatter their business logic across workbooks and load scripts, so the first job is archaeology. BusinessObjects did the opposite: someone already sat down and centralized the definitions. Your universe declares what a dimension is, how tables join, which context resolves an ambiguous path, and which summary table an aggregate-aware object should redirect to. That is an asset, and the migration succeeds or fails on whether it is read as one.
What it is not is portable. A universe describes a query-generation layer — it emits SQL per request. A Power BI semantic model is a different animal: relationships relate exactly one column to one column with a cardinality and a cross-filter direction you declare on purpose, and calculations are evaluated against that model rather than pushed into generated SQL. So contexts do not become anything; they become the reason a model is designed a particular way. We rebuild on star schema principles (opens in new tab), with the loading and reshaping handled in Power Query (opens in new tab) and every aggregation expressed as a named measure built on CALCULATE (opens in new tab), which modifies filter context the way a universe condition modified a generated WHERE clause.
The Web Intelligence layer gets the same treatment one level down. A .wid document holds a query definition and a set of report-local variables, and in most estates those variables are where the drift lives: the same measure, redefined slightly differently in each document, because it was easier than opening the universe. Consolidating them is uncomfortable and it is most of the value. It is the point at which three versions of “net revenue” that nobody had noticed disagreeing finally get settled by a person with the authority to settle them.
SAP sells two things that people both call “SAP reporting,” and mixing them up wastes a scoping call. This page is for BusinessObjects Enterprise — the BI platform: universes, Web Intelligence, BI Launch Pad, the CMS and CMC, scheduled instances and publications. If your reporting is Crystal Reports — pixel-perfect .rpt files with formula fields and subreports, often opened from a button inside an ERP and printed as invoices or statements — then our Crystal Reports to Power BI migration service is the page you want, and the work there is print fidelity and formula translation rather than a semantic layer.
Plenty of shops run both, and the two workstreams are scoped separately because they genuinely are different projects. Where they meet is Crystal Reports for Enterprise output published into the CMS: those documents come across as paginated reports, and we scope them alongside the Crystal estate rather than the Webi one.
If the incumbent is not SAP at all, a sibling page will fit better. Our Cognos to Power BI migration service is the closest analogue to this one — a Framework Manager package plays much the same role as a universe, and report bursting much the same role as publications. Our QlikView to Power BI migration service is the opposite case: no shared modeling layer at all, an associative engine to resolve into a star schema, and a proprietary QVD layer to bypass first. And our Tableau to Power BI migration service covers workbooks that each carry their own calculation logic, where LODs and table calculations are the translation problem.
Most BusinessObjects estates decompose into the same handful of pieces. The table below is the mapping we work from; the inventory in your written scope is a filled-in version of it, universe by universe and document by document.
| BusinessObjects artifact | What it actually holds | Where it lands in Power BI |
|---|---|---|
| Universe (.unx, or legacy .unv) | Business-friendly objects mapped to SQL, plus joins, contexts and aggregate awareness | A semantic model: star schema tables, explicit one-column relationships, and named DAX measures |
| Derived tables, @Select and @Where functions | SQL fragments reused across many objects, edited in the Information Design Tool | Power Query steps, a database view upstream, or the measure definition itself — decided per fragment |
| Contexts and aggregate awareness | Ambiguity resolution and automatic redirection to summary tables at query time | Not converted — they become deliberate model design: conformed dimensions, aggregations, one active filter path |
| Data and business security profiles | Row and object restrictions applied at the universe for a group | Row-level security roles with DAX filter expressions, enforced by the service at query time |
| Web Intelligence document (.wid) | Query definition, report blocks, sections, breaks and variables in one file | Split three ways: model queries, DAX measures, and report pages that replace the report tabs |
| Webi variables (dimension / detail / measure) | Report-local calculations, frequently redefined document by document | Named DAX measures defined once on the shared model and reused by every report |
| Merged dimensions across data providers | Manual stitching of two or more queries inside a single document | Model relationships where the sources can be conformed; a composite model where they genuinely must stay apart |
| Input controls, sections, breaks and drill filters | In-report filtering, grouping and navigation | Slicers, report and page filters, visual grouping, and drill-through pages |
| Scheduled instances | Time-triggered report runs stored in the CMS as saved output | Semantic model refresh schedules plus Power BI subscriptions against the live report |
| Publications and bursting by profile | One document distributed to many recipients, each seeing only their own slice | Row-level security on a single report where possible; paginated report subscriptions where recipients need a fixed document |
| BI Launch Pad folders, categories and favorites | Navigation, per-user saved output and personal folders | Workspaces and Power BI apps with per-audience permissions; Favorites and personal bookmarks in the service |
| CMC groups and access levels | Platform-wide security administration, often built up over a decade | Microsoft Entra groups mapped to workspace roles and app audiences — rationalized, not copied one-for-one |
| Crystal Reports for Enterprise output in the CMS | Pixel-perfect, print-fidelity documents living alongside the Webi estate | Paginated reports — scoped with our Crystal Reports service rather than the Web Intelligence workstream |
| OLAP connections to SAP BW / BEx queries | Live access to a cube already modelled inside BW | A direct connection to the same source, or a rebuilt import model where refresh performance and cost say otherwise |
| Lumira, Design Studio and Analysis for Office | Adjacent SAP front ends pointed at the same data | Power BI reports and Excel, both connected to the one shared semantic model |
Two rows in that table usually decide a timeline. If your universes sit on a relational warehouse you still control, the project is modeling and reconciliation work. If the primary source is SAP BW or HANA, connectivity design comes first — live connection versus import, and what that costs in refresh windows and licensing — and we scope it as its own phase rather than discovering it in week three. Row-level security is the other one: a publication that bursts to two hundred recipients is a different piece of work from one that emails a single PDF to finance, and the rebuild follows Microsoft's row-level security guidance (opens in new tab) rather than trying to reproduce the CMC's structure verbatim.
It fits small and mid-size US organizations running a BusinessObjects estate that has outlived the people who built it — typically a 4.3 deployment facing the maintenance date, a Microsoft 365 tenant already in place, and a Webi document list far longer than the list anyone still opens. It is scoped as one fixed-fee project with a stated end date, not a rolling program, and we are candid when a document is better retired than rebuilt. If your estate is a genuinely large enterprise BW landscape with thousands of documents and a dedicated BI team, we are not the right firm and will tell you on the call.
Once you have landed on Power BI, the work usually continues. Our fixed-fee Power BI dashboard development service covers reports built new on the model rather than migrated onto it, the guide to what a Power BI dashboard actually costs explains how scope drives a fixed fee, and how to choose a Power BI consultant covers the questions worth asking any firm quoting this work — including ours. If the scale of your estate eventually justifies it, our Power BI to Fabric migration service handles capacity, and where universe derived tables were doing work that belonged in a pipeline, our Azure Data Factory pipeline development service builds the scheduled loads that replace them.
Most BusinessObjects estates sort cleanly into three phases. The table shows scope and typical timeline rather than prices, because an honest number requires opening your universes first — the same principle described on how our fixed-fee process works.
| Phase | Scope | Typical timeline | Fee |
|---|---|---|---|
| Phase 1 — core universe and headline documents | The universe that carries most of the business definitions, rebuilt as a star schema; the Web Intelligence documents leadership opens weekly rebuilt on it; headline variables re-derived as DAX and reconciled; workspace, gateway and access configured | About the first week | Fixed fee — scoped after your free consultation |
| Phase 2 — departmental documents and security | Finance, sales or operations documents rebuilt as report pages on the shared model, universe security profiles re-expressed as row-level security roles and tested per group, drill-through in place of embedded detail blocks, and a walkthrough per team | Weeks 2–3 | Fixed fee — scoped after your free consultation |
| Phase 3 — distribution, long tail and decommission | Publications and scheduled instances rebuilt as subscriptions or paginated reports, refresh schedules finalized, low-traffic documents rebuilt, consolidated or retired by agreement, plus the written list of scheduled instances and CMS objects you can switch off | Week 4 and close-out | Fixed fee — scoped after your free consultation |
Nothing is switched off early. BusinessObjects keeps running on its existing schedule while Power BI connects to the same sources alongside it, so both can sit on one screen while your team argues about the numbers before anyone commits. Everything produced is yours from the first day: the semantic model, the report files, every measure and query, and the workspace configuration all live in your own Microsoft tenant, never in ours.
Related services
The other SAP estate: .rpt files, formula fields, subreports and print fidelity, scoped as its own project.
Fixed-fee dashboard development for the reports you want built new, once your estate has landed on Power BI.
The scoping process, what a written fixed-fee proposal contains, and what happens after delivery.
What to ask, what to check, and the answers that should make you walk away.
Pro vs Premium Per User vs Fabric, explained for small business budgets.
Where a modelled BI tool earns its place — and where a spreadsheet still wins.
FAQ
No. SAP has confirmed further BI releases — 2025, 2027 and 2029 — with mainstream maintenance running to at least the end of 2031. What is dated is BI 4.3: its mainstream maintenance ends on 31 December 2026. That makes this an upgrade-or-move decision, not a platform rescue.
Partly, and only after the semantic layer exists. Tools can read a .wid document and inventory its queries, blocks and variables, which saves real time. They cannot decide what a universe object should become in a star schema. We use tooling for the inventory and rebuild the model by hand.
A universe is read as a specification, not converted. Its objects, joins, contexts and aggregate awareness describe how your business defines each measure. We re-express that as a Power BI star schema with explicit relationships and named DAX measures, then check each figure against the same one in Web Intelligence.
Scheduled Webi instances become semantic model refreshes plus Power BI subscriptions. Publications that burst a document by recipient are rebuilt either as row-level security on one report or as paginated reports delivered by subscription. BI Launch Pad folders and categories become workspaces and apps with permissions set per audience.
No — same vendor, different product. Crystal Reports is pixel-perfect operational reporting, and that work is about .rpt files, formula fields and subreports. BusinessObjects Enterprise is the BI platform: universes, Web Intelligence, BI Launch Pad and publications. Many shops run both, and we scope them as separate workstreams.
It follows the shape of your estate: how many universes carry real logic, how many Web Intelligence documents genuinely move rather than retire, how much sits in publications and bursting, and whether sources are BW, HANA or a relational warehouse. After a free consultation you get a written scope with one fixed price.
Book a free consultation
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.