Inventory before opinion
Every card is listed with its page, owner, dataset, and how recently anyone viewed it, then marked rebuild, merge, or retire. You approve that list, and the hours behind it, before a visual is drawn.
Leaving Domo
A Domo to Power BI migration built card by card, not by a converter
We inventory every card, page, dataset and Magic ETL flow, rewrite the Beast Modes as DAX on one governed model, re-express PDP as row-level security, then run the rebuilt reports beside the originals until the numbers agree.
Representative dashboard — sample data
Why teams move
The renewal arrives, and so does the arithmetic
Most instances are not abandoned because the product stopped working. They are re-evaluated because the seat count grew faster than the number of people who actually open a card, because the transformation logic now lives somewhere the data team cannot version-control it, and because the same organisation is already paying for Microsoft 365. The renewal date is when someone finally puts those three facts on one page.
There is a second reason to look at the timing this year. On 22 July 2026, Domo announced an agreement to sell substantially all of its assets and certain liabilities to Progress Software, with closing expected before the end of Progress' fiscal year on 30 November 2026. We have no view on what that means for the roadmap, and neither should anyone selling you a migration. What it does mean, practically, is that at renewal an ownership change is a reasonable prompt to re-examine seat cost and where your data and transformation logic actually live.
What the migration covers
- Card and page inventory
- Beast Modes → DAX
- Magic ETL unpacked
- PDP → row-level security
- Datasets remapped
- Refresh & orchestration
- Alerts and subscriptions
- Reconciliation & cutover
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. The card inventory makes a sensible first task: it tells you how much of the instance is genuinely load-bearing before you commit a budget to rebuilding it.
How we approach it
A systematic mapping, done by engineers who have read the logic
Nothing exports cleanly out of one platform and into the other. What makes the work predictable is that every construct has a known counterpart, and we work through them in a fixed order instead of discovering them in week three.
Beast Modes read, then reconciled
Card-level calculations drift. Three cards can each carry their own version of gross margin and all look official. We collect them, put the variants side by side, and settle one definition before rewriting it as a measure.
Magic ETL turned into readable steps
Visual flow tiles become named Power Query steps or a dataflow, so the transformation is legible in a diff and reviewable by someone who did not build it. Heavy joins usually drop back to the warehouse where they belong.
PDP rewritten as tested roles
Personalized Data Permissions become row-level security roles, expressed in DAX and driven by security groups. Each role is tested with a real account before release, because access rules are the one thing nobody wants to discover in production.
Refresh you can see failing
Scheduled jobs and workflow triggers move onto gateways and refresh schedules with real failure notifications, so a broken load is an alert on Tuesday morning rather than a stale figure someone spots at month-end.
Reconciled, not just rebuilt
Every rebuilt report is run beside its original on the same filters and date range. Differences are explained before sign-off, and a few of them turn out to be corrections nobody had noticed.
Is there a converter for any of this?
No, and that is the most useful thing to know before budgeting. No tool reads a card, a Beast Mode, a Magic ETL flow, a Workflow, or a PDP policy and emits a working Power BI equivalent. The platforms divide responsibilities differently: one bundles ingestion, storage, transformation, calculation, and delivery into a single subscription, while Power BI splits them across gateways, dataflows, a semantic model, and a workspace.
That is not a reason to be nervous about the estimate. A rebuild with a complete map is more predictable than a conversion that half-works and leaves someone debugging a machine-generated formula. The mapping below is deliberately boring, because the point of migrating is that nothing surprising surfaces late.
How do Domo constructs map to Power BI?
Each row is a decision we make per object rather than a rule applied blindly. A card counted twice is cheap; a Beast Mode misread is expensive.
| Domo construct | Power BI equivalent | What changes in practice |
|---|---|---|
| Card | A visual on a standard report page | Cards that were separate objects become visuals that cross-filter each other on one page |
| Beast Mode calculation | DAX measure on the shared semantic model | Written once and reused, instead of re-entered per card and drifting between them |
| Magic ETL flow | Power Query steps or a Power BI dataflow | Visual tiles become named, reviewable steps; heavy joins often move back to the warehouse |
| PDP row security policy | Row-level security roles on the model | Filters are expressed in DAX and mapped to security groups, then tested role by role |
| Domo Workflows | Gateways plus scheduled refresh and external orchestration | Triggered sequences become an explicit schedule with monitored, alerting failures |
| Dataset / dataflow | Power BI dataflow, imported table, or DirectQuery | Storage mode becomes a deliberate choice per table rather than a platform default |
| Page or dashboard collection | Report pages published in a workspace app | Navigation and audience are managed by workspace roles and app permissions |
| Card alert | Data-driven alert or report subscription | Thresholds are re-created against measures, and delivery moves to email subscriptions |
Two rows carry most of the effort. Beast Modes are the reason a rebuild is an engineering job rather than a design job, which is why the measure layer is treated as its own workstream and shares the discipline described on our data modeling and DAX page. PDP is the other: translating it well means understanding who is filtered, by which attribute, and from which directory group, and our walkthrough of Power BI row-level security setup covers the pattern we apply. Microsoft's own Power BI migration guidance (opens in new tab) sequences the work the same way: assess and prioritise the estate before rebuilding any of it.
What does the rebuild actually cost?
Work runs on prepaid Flex hours that never expire: Starter 20 hours at $125/hour ($2,500), Growth 40 hours at $115/hour ($4,600), or Power 80 hours at $100/hour ($8,000). Inventory and classification of a typical mid-market instance fits inside a Starter block, and it is the task we suggest buying first, because it converts a vague card count into a scoped list with hours against each line.
After that, cost tracks how much logic survives classification rather than how many cards exist. A card fed by a clean warehouse table with one Beast Mode is a short task. A page whose figures depend on four chained Magic ETL flows and a PDP policy that nobody has documented is not. You get an estimate per report, approve only what you want built, and any hours you do not use stay banked.
How long does the migration take?
Individual reports typically ship within 3–5 business days of approval, and the estate moves in waves: the reports that leadership reads first, the long tail last, retirements never. Running both platforms through one full reporting cycle is worth the overlap, because users compare outputs on live data and the old instance is switched off only after a real month-end has passed against the replacement.
The realistic constraint is rarely our capacity. It is how quickly your team can answer which of the three margin definitions is correct, and who is allowed to see the western region. The migration is often the first time anyone has had to write those answers down.
Who this is for
Analytics, finance, and operations teams with a live instance, a renewal in sight, and enough logic inside the platform that the move needs a plan rather than a weekend. It is a poor fit for anyone hoping for a like-for-like copy with no decisions made, because the duplicate metric definitions are exactly the thing worth fixing on the way across.
If your estate spans more than one tool, the broader migration to Power BI service covers the Excel and SSRS routes as well. The neighbouring rebuilds share most of this method: Qlik to Power BI migration deals with set analysis and the associative model, Tableau to Power BI migration handles LOD expressions and extracts, and Cognos to Power BI migration takes on Framework Manager metadata models and Report Studio specifications. Teams leaving a cube-based platform with analytics embedded in their own product should read our Sisense to Power BI migration page, where the ElastiCube rebuild and the Embed SDK move are scoped as two separate workstreams.
What you get
- A full card and page inventory with owners and usage
- Rebuild / merge / retire calls you approve
- Every Beast Mode documented and rewritten as DAX
- Magic ETL logic rebuilt as reviewable query steps
- PDP mapped to tested row-level security roles
- Reconciliation against the originals, then handover
3–5
business days per report
Phased
not big-bang
You
own everything
Buy the inventory task first and decide the rest once the real scope is visible on paper.
How it works
From a crowded instance to a model your team can maintain
- 1
Inventory and classify
We catalogue cards, pages, datasets, Beast Modes, Magic ETL flows and PDP policies, with owner, usage and complexity against each, then classify every item as rebuild, merge, or retire. You approve the list and the hours before work starts.
- 2
Rebuild in priority order
Surviving reports are rebuilt highest-value first on one governed semantic model: Beast Modes become tested DAX measures, transformation logic moves into Power Query or the warehouse, and PDP becomes row-level security roles.
- 3
Reconcile, cut over, support
Each report runs beside its original until the figures agree and every difference is explained. Then we publish, set refresh, permissions and subscriptions, walk your users through it, and stay available on the hours you have left.
Representative perspective
We assumed the whole instance had to come across. The inventory showed most of it was cards someone built for one meeting two years ago, and the part the executive team actually reads fitted on two pages.VP of finance, mid-market SaaS
Representative perspective
The Beast Mode audit was uncomfortable and worth it. We had three definitions of contribution margin in production, and the rebuild forced us to pick one before anything got published.Analytics manager, distribution group
Find out how much of your instance is load-bearing
Tell us roughly how many cards and datasets you have, and which pages leadership opens each month. We'll scope the inventory and classification task in hours, so you can see the real project before committing a budget to it.
FAQ
Questions teams ask before they commit
No. There is no exporter that turns a Domo card, Beast Mode, or Magic ETL flow into a working Power BI equivalent, because the two products model data differently. What is systematic is the mapping: every construct has a known counterpart, so the rebuild is methodical rather than exploratory.
Each one is read, classified, and rewritten as DAX. Because Beast Modes are authored per card, the same metric is often defined several slightly different ways across an estate. We reconcile those variants into one measure on the shared model and show you which cards changed and why.
Personalized Data Permissions become row-level security roles on the semantic model. Each policy is read out, its filter logic is expressed in DAX, and every role is tested against real accounts before release. Group membership usually moves to Microsoft Entra security groups so access is managed alongside the rest of your identity.
Individual reports usually ship within three to five business days of approval, and the estate moves in waves rather than one cutover. Pace depends far more on how much Beast Mode and Magic ETL logic sits behind each card than on the raw number of cards in the instance.
You give up the all-in-one convenience: connectors, storage, transformation, scheduling, and delivery arrive under one subscription. In Power BI those layers are assembled from gateways, dataflows, and workspaces. What you gain is ownership, because the model, the measures, and the refresh schedule are yours in files you keep.
Start with the inventory
Tell us the task in the form below. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days, from a prepaid block of senior-led hours, with hours deducted only for work you have approved. If the renewal is close, the inventory is the piece of work that turns the decision into arithmetic rather than a debate.
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.