Domo to Power BI migration services that unbundle cards, Beast Modes and Magic ETL

Domo is a bundle; Power BI is a layer you assemble

The defining fact about moving off Domo is not that the charts look different. It is that Domo sells connectors, cloud storage, ETL, visualization, alerting, chat and an app framework as one subscription, in one place, and Power BI does not. Power BI is the visualization and semantic-model layer of a platform whose other layers — storage, pipelines, notification, custom apps — are separate Microsoft products you already own or can add. A migration that treats this as a card-for-visual exercise runs out of road in week two, when someone asks where the DataSet actually comes from now.

So the first deliverable is a map, not a report. For every card that matters we trace the lineage backwards: card, to Beast Mode, to DataSet, to the Magic ETL flow that built it, to the connector that fed it, to the system of record behind that. Most of the time the system of record is still there and still reachable, and Power Query can be pointed straight at it, skipping the Domo copy entirely. Sometimes it is not, and a DataSet has quietly become the only surviving copy of something a retired system produced. That distinction sets the timeline more than the number of cards does, and it is why we read the instance before quoting.

Two things follow from that map. First, the scope names an owner for each of Domo's bundled layers — typically Power BI for reporting, your existing warehouse or a Fabric lakehouse for storage, Power Query or Dataflows Gen2 (opens in new tab) for transformation, and the on-premises data gateway (opens in new tab) for anything behind your firewall. Second, the scope says plainly which Domo capabilities have no single Power BI equivalent, so nobody discovers that at cutover.

Beast Mode is SQL against a DataSet; DAX is a language for a model

Beast Mode is the piece teams worry about, and rightly. It is a calculated field authored in a SQL-like syntax and evaluated at query time against a single flat DataSet, which makes it easy to write and easy to write a lot of. Instances that have been live for a few years commonly hold hundreds of them, many defined on one card, invisible to everybody else, and quietly disagreeing with a near-identical Beast Mode on the card next to it.

DAX works from the opposite premise. It evaluates against a model of related tables, and its behaviour depends on filter context rather than on a single table's rows. Microsoft's own DAX documentation (opens in new tab) is the reference we work against, and CALCULATE (opens in new tab) — documented as evaluating an expression in a modified filter context — is the function that carries most conditional Beast Mode logic across. A CASE WHEN that flags a row usually becomes a Power Query column or a dimension attribute, not a measure. A SUM wrapped in a filter usually becomes a measure built on CALCULATE. An aggregate Beast Mode dividing two aggregates almost always becomes two measures and a third that divides them, which is where several long-standing averaging errors surface.

The consolidation is deliberate. Three Beast Modes that all compute revenue slightly differently become one measure and a written note about which of the three definitions the business chose. That conversation is uncomfortable and it is the single most valuable hour of the project. The result is a model built on star schema principles (opens in new tab) where a measure is defined once and reused, rather than a flat DataSet with logic scattered across the cards that happen to sit on top of it.

Magic ETL, and the parts with no one-to-one equivalent

Magic ETL flows translate more predictably than Beast Modes do. Joins, appends, filters, group-bys, pivots and column derivations all have direct Power Query counterparts, and Power Query (opens in new tab) is where the light ones land. Heavy flows that several DataSets depend on are better as Dataflows Gen2 so the result is computed once and reused, and flows doing warehouse-scale work usually belong upstream in the warehouse or in a scheduled pipeline instead. A useful share of Magic ETL steps also turn out to exist only to reshape what a Domo connector delivered, and simply disappear when Power Query reads the source directly.

Being plain about the rest matters more than being optimistic. Domo's integrated ETL, alerting and app layer has no one-to-one Power BI equivalent, and we say that in writing before you sign rather than after. Domo alerting is a first-class feature attached to a card, with thresholds, subscribers and delivery to email, mobile and Buzz; the nearest Power BI arrangement is data alerts in the Power BI service (opens in new tab), extended with Power Automate wherever the notification has to do more than land in an inbox. Domo Apps, App Studio and custom Bricks are custom code hosted inside Domo, and Power BI simply has no place to put them; they are rebuilt as Power Apps or Power Pages, or retired, and each one is a line item rather than a rounding error. Buzz conversations attached to cards become Teams conversations attached to a report, which is close in spirit and not the same thing.

Where each Domo object lands

Most Domo instances decompose into the same set of objects. The table below is the mapping we work from; the inventory in your written scope is a filled-in version of it, card by card and flow by flow.

Three rows in that table decide a timeline. The DataSet row decides whether this is mostly modeling work or also a data-extraction project. The Domo Everywhere row decides whether an application team is involved. And the Apps row decides whether anything has to be rebuilt as software rather than as a report — which we would rather price in week zero than discover in week three.

Card types with no native Power BI counterpart

Domo's chart library is broader than Power BI's out of the box, and pretending otherwise sets a project up to disappoint. Bar, line, combo, stacked, pie, donut, gauge, table, heat map, scatter, bubble, funnel, waterfall and map cards all have native Power BI visuals, and those rebuild directly. Sankey diagrams, word clouds, calendar heatmaps, radial and chord layouts and several of Domo's more decorative card types do not.

For each of those we put a choice in the scope rather than a surprise in the delivery. Some are best served by a certified visual from AppSource, and Microsoft's guidance on Power BI custom visuals (opens in new tab) covers what your tenant administrator has to allow before one can be used — a governance decision, not a design one, and worth making before the build. Others are better redesigned: a Sankey showing where orders drop out is frequently clearer as a funnel with a decomposition tree behind it. A handful are cosmetic and simply retire. What does not happen is a like-for-like promise we cannot keep.

Embedded analytics after Domo Everywhere

If you embed Domo content into a customer-facing product, that is a second project inside the first, and it deserves separate scope. Domo Everywhere hides a lot: identity, filtering per customer, and delivery are largely configuration inside Domo. Power BI Embedded (opens in new tab) reaches the same destination by a route your own application walks: an embed-for-your-customers model, capacity sized for concurrency rather than headcount, a service principal registered in Entra ID, and embed tokens minted server-side so no customer ever holds a Power BI licence. Row-level security carries the per-customer filtering, using the same roles built for internal reporting, which is one of the places the migration genuinely pays back.

The honest framing is that this is application work with a Power BI dependency, not a Power BI setting. We scope it as its own phase, with its own reconciliation: the same customer, signed in to your product, sees the same numbers they saw before cutover.

What the licence swap does and does not save

Domo does not publish list pricing; it is quoted per contract, so the only reliable figure for what you pay today is on your own renewal paperwork. Power BI is the opposite, and that asymmetry is worth using: Microsoft publishes Power BI pricing (opens in new tab) openly, with Power BI Pro at $14 per user per month and Premium Per User at $24, so you can build the after side of the comparison exactly before you commit to anything.

The comparison people get wrong is the shape of it, not the arithmetic. Domo's fee covers storage, ETL and delivery as well as viewing, so a per-seat swap flatters Power BI. Count the whole picture: Pro seats for everyone who opens or builds a report, plus whatever now holds the data, plus embedding capacity if you have external users. Check the Microsoft 365 plan you already pay for first — E5 includes Power BI Pro, and the seat plans most mid-market companies run do not. Our guide to Power BI licensing for small business works through the mix in detail, and what a Power BI dashboard actually costs covers the build side of the budget.

Prices shown are Microsoft's published list prices for Power BI at the time of writing; your own Domo figure comes from your contract, and we build the comparison with your numbers rather than assumed ones.

Who this is for

It fits small and mid-size US organizations running a Domo instance with a renewal date in view, a Microsoft 365 tenant already paid for, and a growing sense that the reporting layer and the data platform should not be the same vendor. It is scoped as one fixed-fee project with a stated end date, not a rolling program, and we are candid when a card is better retired than rebuilt — in most instances a meaningful share of cards have not been opened in a year.

If the incumbent is a different platform, a sibling page fits you better, and the differences are real rather than cosmetic. Our Tableau to Power BI migration service deals with workbooks that carry their own calculation logic, where LODs and table calculations are the translation problem and the data platform underneath is usually already yours. Our QlikView to Power BI migration service is dominated by the associative engine and the QVD layer. Our Cognos to Power BI migration service starts from a Framework Manager package that already holds a modeling layer, so the work is rationalization and validation rather than reconstruction. Our MicroStrategy to Power BI migration service sits at the other end of the spectrum entirely: attributes, facts and metrics declared once in a project metadata repository, where the translation problem is level metrics into DAX rather than Beast Modes into measures. Domo is unlike all four because the vendor also owns your ETL, your storage and, if you embed, your delivery channel — so the question is never only how the charts get rebuilt, but which product takes over each of the layers that came in the box.

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, and our Azure Data Factory pipeline development service builds the scheduled loads that take over from your connectors and Magic ETL flows.

Delivery in three phases

Most Domo instances sort cleanly into three phases. The table shows scope and typical timeline rather than prices, because an honest number requires reading your instance first — the same principle described on how our fixed-fee process works.

Nothing is switched off early. Your Domo instance keeps refreshing on its existing schedule while Power BI reads 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.