Cube schema before chart count
We document every ElastiCube table, relationship, custom column and build step, with the sources behind them, before estimating anything. Cubes accumulate tables nobody reads; those get retired rather than reproduced.
Leaving Sisense Fusion
A Sisense to Power BI migration scoped from your ElastiCube, not your dashboard count
We inventory the ElastiCube schema and its build schedules, translate it into a VertiPaq semantic model, rewrite JAQL widget formulas as DAX, rebuild dashboards and BloX widgets as Power BI report pages, and move Embed SDK integrations to Power BI Embedded.
Representative dashboard — sample data
Where the work really sits
The cube is the project. The widgets are the easy part.
Teams usually estimate this move by counting dashboards, then discover the estimate was measuring the wrong thing. Sisense keeps the modeling in the ElastiCube — imported tables, relationships, custom columns and a build schedule — and keeps the business logic scattered across widget-level JAQL. Rebuilding forty widgets is a week. Working out which of the four revenue definitions hiding in those widgets is the real one is the project.
So we scope from the cube outward. What tables does it actually load, what does each build step do, which security rules sit on it, and how many of the widgets on top are genuinely in use? That inventory decides the timeline, and it usually shrinks it.
What we translate
- ElastiCube → semantic model
- JAQL → DAX
- Widgets → visuals
- BloX & plugins
- Data security → RLS
- Embed SDK → Power BI Embedded
Try us risk-free for 4 hours
Start with a block of prepaid Flex hours and, if you're unhappy within the first 4 hours, we refund you in full — no questions asked. An ElastiCube and widget inventory is the natural first task: it tells you the real size of the job before you commit a budget to it.
How we approach it
Six things we do differently on a cube-first rebuild
Anyone can redraw a chart. The value is in what the cube was really doing, and what quietly disagreed with itself inside it.
Every JAQL formula collected
Widget formulas are pulled out and listed side by side, including the near-duplicates. You approve one definition per metric, and it becomes a single DAX measure instead of nine slightly different ones.
A star schema, not a flattened cube
ElastiCubes tolerate wide, denormalised tables. Power BI rewards facts surrounded by dimensions, so we reshape on the way across — which is where most of the performance gain actually comes from.
BloX and plugins handled honestly
Some custom widgets map to a native visual, some to an AppSource visual, and a few need a rethink. We tell you which is which in the inventory, rather than discovering it in week three.
OEM embedding as its own workstream
If customers see Sisense inside your product, the Embed SDK or Compose SDK integration is a software change, not a reporting change. It gets scoped, staged and tested separately from the internal dashboards.
Reconciled against the live cube
Every rebuilt page is compared with its Sisense original on the same filters and date range. Differences get explained line by line — and a few of them turn out to be defects we just fixed.
What does the ElastiCube actually become?
An ElastiCube is Sisense's in-memory analytical store: you import tables into it, relate them, add custom columns, and rebuild it on a schedule so the dashboards read from cached data rather than hammering the source. Power BI's Import mode does the same job with a different engine — data is compressed and stored by the VertiPaq storage engine, then loaded into memory for querying, as Microsoft describes in its guide to semantic model modes (opens in new tab). The concept transfers cleanly. The shape does not, because VertiPaq compresses a narrow, well-related model far better than the wide flat tables cubes tend to accumulate.
If you run Live Models against a warehouse instead of importing, that maps to DirectQuery, and a mixed estate maps to a composite model — some tables imported, some queried live. We decide that per table during the inventory rather than picking one mode for the whole migration.
Scope note: this page is about Sisense Fusion — the ElastiCube, widget and dashboard platform. Sisense for Cloud Data Teams, the SQL, Python and R notebook product that came from the Periscope Data acquisition, is a different product with a different migration path, and we would scope that separately rather than pretend it is the same job.
How do Sisense concepts map to Power BI?
Here is the working map we build the plan from. It is deliberately dull — a good migration is one where nothing surprising happens after the estimate is signed.
| Sisense | Power BI equivalent | What changes in practice |
|---|---|---|
| ElastiCube | Import-mode semantic model (VertiPaq) | Tables are reshaped into a star schema on the way in; compression improves as the model narrows |
| Live Model / live connection | DirectQuery, or a composite model | Storage mode is decided per table rather than once for the whole estate |
| ElastiCube build schedule | Scheduled refresh, plus incremental refresh | Full rebuilds are replaced by partitioned refresh where the fact table is large |
| Custom column in the cube | Power Query step or calculated column | Row-level logic moves to Power Query where it can; genuine measures become DAX instead |
| JAQL widget formula / shared formula | DAX measure on the model | Duplicated widget-level logic collapses into one reusable, documented definition |
| Widget | Report visual | Most chart types map directly; a few are consolidated because Power BI does the job in one visual |
| Dashboard & dashboard filters | Report page with slicers and filters | Filter scope becomes explicit — visual, page or report level — rather than implicit |
| BloX widget | Card and table visuals with buttons and bookmarks | The JSON-defined card layout is rebuilt natively; call-to-action behaviour becomes a button action |
| Plugin / custom JS widget | AppSource custom visual, or a native rebuild | Each one is triaged individually; we never promise a like-for-like match we cannot ship |
| Data security rule | Row-level security role | Per-user and per-group cube rules usually consolidate into one dynamic, testable role |
| Embed SDK / Compose SDK | Power BI Embedded, app-owns-data | Iframes and SDK components are replaced by embed tokens issued from your back end |
The modeling half of that table is the same discipline covered on our Power BI data modeling and DAX page, and Microsoft's guidance on star schema design (opens in new tab) explains why the reshape matters more than the chart work. Where cube data security rules are dense, our guide to Power BI row level security setup covers how we build and test the replacement roles.
What about the dashboards our customers see?
Sisense earns a lot of its revenue from OEM embedding, so a meaningful share of the teams asking about this are software companies with analytics inside their own product. That changes the job. Internal dashboards can move page by page; a customer-facing embed has to keep working for every tenant on the day of the switch.
The Power BI destination is app-owns-data embedding, where your application authenticates, requests an embed token, and renders the report for a customer who does not need a Power BI licence of their own — Microsoft's Power BI embedded analytics documentation (opens in new tab) sets out the model and the capacity it needs. Tenant isolation moves from Sisense data security rules to row-level security on the semantic model. We run that as a staged workstream against a test tenant before it touches production, and our Power BI Embedded page covers the capacity and licensing decisions behind it.
What does it cost and how long does it take?
Work runs on prepaid Flex hours that never expire: Starter $2,500, Growth $4,600, or Power $8,000, with hourly rates from $100 on the largest block. The ElastiCube and widget inventory usually fits inside a Starter block, and it is the task we recommend buying first, because it converts a vague replatform into a list of scoped items with hours against each one.
After that, cost follows how much logic the cube carries and how many widgets survive triage — a straightforward sales cube is a different job from one with eleven custom columns, three build steps and a BloX layer. Individual dashboards typically ship within 3–5 business days of approval, and the migration runs as a sequence of those rather than one big-bang cutover. Running both platforms in parallel for a single reporting cycle is worth the overlap: people compare old and new on live data, and the Sisense contract gets switched off with nothing left stranded.
Who this is for
Analytics and product teams running Sisense Fusion with a renewal in sight and a Microsoft 365 or Azure estate already paid for — particularly software companies carrying both an internal reporting stack and a customer-facing embed. It is a poor fit for anyone wanting a like-for-like copy with no decisions made, because the duplicated widget formulas are precisely the thing worth fixing in transit. Mixed estates are normal: the broader Power BI migration service covers the Excel and SSRS routes, Qlik to Power BI migration deals with set analysis and the associative model, and Domo to Power BI migration takes on Beast Modes, Magic ETL and PDP policies.
What you get
- ElastiCube schema and build-step inventory
- Every JAQL formula documented and deduplicated
- A star-schema semantic model with tested DAX
- Data security rules rebuilt as RLS roles
- Reconciliation against the live Sisense output
3–5
business days per dashboard
Phased
not big-bang
You
own everything
Start with the cube inventory and decide the rest once the real scope is visible. See Flex pricing.
How it works
From cube inventory to a model your team trusts
- 1
Inventory the cube and the widgets
We catalogue ElastiCube tables, relationships, custom columns, build steps and data security rules, then list every dashboard and widget with owner and usage. You approve a rebuild, merge or retire call on each before anything is built.
- 2
Rebuild the model, then the pages
Surviving content is rebuilt on one star-schema semantic model, with JAQL formulas rewritten as DAX measures and cube custom columns re-expressed in Power Query. Report pages and visuals follow the model, not the other way round.
- 3
Reconcile, embed and hand over
We compare each page to its Sisense original, explain every variance, publish to your workspace, migrate any Embed SDK integration to Power BI Embedded against a staging build, and walk your users through what moved where.
Representative perspective
The formula inventory was uncomfortable reading — we had four definitions of net revenue living in different widgets, and nobody could say which one the board deck used.Head of analytics, B2B software company
Representative perspective
Splitting the customer-facing embed from the internal dashboards was the right call. One was a product release with its own testing; the other was just reporting work.VP of engineering, SaaS platform
Find out what your cube is really carrying
Tell us roughly how many ElastiCubes and dashboards you have, whether anything is embedded in your product, and when the renewal lands. We'll scope the inventory task in hours so you know the size before committing.
FAQ
Questions teams ask before committing
No, and nobody has a credible converter. An ElastiCube holds imported tables, relationships and build logic in Sisense's own format; a Power BI Import model holds tables compressed by the VertiPaq engine with relationships and DAX. We inventory the cube table by table, rebuild it as a star schema, then reconcile the numbers against the live Sisense widgets.
They are rewritten as DAX measures on the new model. JAQL expresses aggregation and filtering as JSON inside a widget, so the logic often lives in several widgets at once. We collect every variant, agree one definition with you, and write it once as a measure that every report page then reuses.
Yes, through Power BI Embedded in an app-owns-data setup. Sisense Embed SDK iframes or Compose SDK components are replaced by embed tokens issued from your back end, with tenant isolation enforced by row-level security. It is real engineering work in your application, so we scope and stage it separately from the report rebuild.
They become row-level security roles on the semantic model. Sisense applies data security rules per cube table and column for named users or groups; Power BI filters the model by a role that we test by viewing the report as each role. Per-tenant rules in an embedded product usually collapse into one dynamic role.
Not on this page. Sisense for Cloud Data Teams is the SQL, Python and R notebook product Sisense acquired with Periscope Data, and moving it is a code and warehouse exercise rather than a cube and widget rebuild. Tell us if that is what you run and we will scope it honestly as a different job.
Related work
This page covers the Sisense Fusion path specifically; the mixed-estate links for Excel, Qlik and Domo are above. The semantic model rebuild draws directly on our Power BI data modeling and DAX work, and once the estate is live a Power BI health check keeps refresh and performance honest. Every task is scoped from your prepaid block of senior-led hours — no project minimums, no change-order surprises, and hours are deducted only for work you approve.
Book a free demo
Get senior Power BI help, on demand
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
- Prepaid hours from $100/hour — and they never expire
- Senior-led delivery — 20+ years on the Microsoft platform
- Typical 3–5 business day turnaround
- Full refund if you’re unhappy in your first 4 hours
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.