Migrate from Power BI to Metabase

Migrate from Power BI to Metabase: what the move involves

Most teams moving report consumers off Power BI Pro, Premium Per User, Fabric capacity or Power BI Report Server to self-hosted Metabase find that most consumer reports and dashboards translate, but DAX measures, Power Query logic and sign-in need deliberate rework rather than a copy. The consumer layer (filters, charts, scheduled subscriptions and shared dashboards) maps reasonably well to Metabase questions and dashboards. The logic underneath, which lives in DAX calculations and upstream Power Query transformations, has to be rewritten as SQL, Metabase models or upstream pipeline steps, and every rewritten number should be reconciled against the original report before users switch over. The work is usually done by internal analysts who know the reports, working with platform engineers who host Metabase and its application database. Some teams bring in an implementation partner for the hosting, the sign-in setup and the reconciliation checks. Effort and risk rise with the number of semantic models, the amount of DAX that carries business rules, and the number of reports that depend on row-level security. A team that inventories reports by data source and by DAX complexity first can size the move before committing to a timeline. The Metabase Open Source edition is free to self-host with unlimited users and dashboards, so licensing does not block a pilot. Confirm, however, that the features your organization depends on are in the plan you intend to run. According to the Metabase pricing page, SSO, row and column level permissions and usage analytics are included only in the Pro and Enterprise plans, so a move that relies on Microsoft Entra ID sign-in or per-user data restrictions must budget for a paid plan. Ask Metabase for current pricing in writing before you decide.

Which Power BI capabilities map to Metabase, and what needs rework

This table maps the Power BI capabilities that most teams rely on to their nearest Metabase equivalent and labels each row clean, needs rework or gap. Read the label as a starting point for planning, not a final verdict, because Metabase features vary by plan and release. Confirm current feature availability in the Metabase docs and on the pricing page for the plan you intend to buy before you commit.

Power BI capability	Metabase equivalent	Status	What to confirm or rebuild
Report viewing and browsing	Dashboards, saved questions and collections in the Open Source edition	Clean	Check that consumer groups map to collection permissions in your version
Filters and drill-through	Dashboard filters and click behavior on questions	Clean	Test complex drill paths and cross-filtering against source reports
Scheduled email or Slack delivery	Dashboard subscriptions and alerts	Clean	Confirm delivery channels and attachment formats on your plan
Row-level security	Sandboxing via permissions and row and column rules on Pro or Enterprise	Needs rework	Row and column permissions are a paid feature; DAX RLS roles must be rewritten as data-level rules
Single sign-on	SAML, JWT or OIDC on Pro or Enterprise; Google sign-in and LDAP on Open Source and Starter	Needs rework	Entra ID setups are documented, but confirm the chosen protocol and group sync on your plan
DAX measures	Metabase models, metrics and SQL-based questions	Needs rework	Rebuild each measure as SQL or a metric definition and validate totals against the Power BI output
Power Query transformations	Transforms in the source database, SQL views or an upstream pipeline	Needs rework	Metabase does not replace a data preparation layer; move the logic upstream first
Semantic model reuse	Shared models and metrics across questions	Needs rework	Reuse depends on how many models you define; plan naming and governance early
Embedding for external users	Embedding options by plan, including signed embedding	Needs rework	Confirm embedding features and tenant isolation requirements for your plan
On-premises hosting like Report Server	Self-hosted Metabase on your own servers or cloud accounts	Clean	Report Server file formats do not convert directly; rebuild reports as Metabase content

Which Power BI reports translate to Metabase questions and dashboards

Sort every Power BI report into one of two groups before you plan any rebuild. Simple visuals that query a single table, such as a bar chart of open tickets by team or a table of monthly invoices, translate to Metabase questions that use the visual query builder or native SQL. Multi-page reports that share one semantic model and feed many consumers translate to Metabase dashboards built on Metabase models, which are curated, reusable definitions of a table or a joined dataset. The first group is usually a same-week rebuild. The second group needs the model designed first, because the model is where the business logic lives.

Reports that depend on heavy DAX time intelligence, such as year-to-date, same-period-last-year or custom fiscal calendars, need a redesign rather than a copy. Many-to-many relationships and measures that change meaning by filter context also have no direct equivalent, so write each one down as an explicit SQL calculation or a metric and have a finance owner sign off the numbers against the Power BI output for the same period. Expect pixel-level formatting, custom visual packages and bookmarks to be lost or simplified, and tell report owners this before the cutover, not after. Start the inventory with the download limits. Workspace Contributors can download a .pbix file from the Power BI service, but a download with data is blocked for Direct Lake models, models with incremental refresh and models larger than 50 GB, so those reports cannot be exported with their data from the service. For each report, record the semantic model type, refresh mode, data size, source connections and the workspace role of the person who will run the export. Reports in the blocked categories need their source queries or warehouse tables documented directly, which is a separate piece of work. Confirm the current download rules in Microsoft's documentation for your tenant before you rely on them.

Migration sequence from Power BI inventory to Metabase decommission

This sequence moves Power BI report consumers to Metabase in controlled stages, so each audience is switched only after its numbers have been checked against the source. It ends with licenses and capacity released on a date the team has recorded.

Inventory workspaces, reports and consumers
List every Power BI workspace, report, semantic model, dataset refresh schedule and downstream consumer, including subscriptions, email digests and embedded views. Record which Contributors own each item and which audience groups rely on it. Note any model that cannot be downloaded as a .pbix with its data, such as Direct Lake models, models with incremental refresh or models over 50 GB, because those need a different extraction path. The step is done when the inventory has one row per report with owner, audience, source tables, refresh cadence and business use, and the team has signed off on the list.
Reconcile metrics and source queries
For each report in scope, write down the business metrics it shows and the DAX measures or Power Query steps that produce them. Map the source tables to the database that Metabase will query, and identify where DAX logic must be rebuilt as SQL in a Metabase question or model. Agree with the metric owners which definition is authoritative when the two disagree. The step is done when a reconciled metrics list exists, with each metric tied to a named query and an owner who has approved it.
Stand up Metabase on production-grade storage
Install Metabase in your own environment and configure PostgreSQL or MySQL as the application database rather than the embedded H2 database, which Metabase documents for demos. Connect the source databases with read-only service accounts and confirm that access controls match the Power BI workspace permissions being replaced. Record the Metabase version you deploy, since it determines the support window. The step is done when a test instance points at the intended databases, the application database has been backed up, and the access model has been reviewed by the team that owns the data.
Pilot with a small consumer group
Rebuild a limited set of reports as Metabase questions and dashboards for a small group of report consumers, chosen to represent different use cases. Ask pilot users to compare the Metabase output with their current Power BI views and log every difference, including filters, date handling and rounding. Decide in advance how row-level access will be enforced, because row and column level permissions depend on the plan you choose. The step is done when a pilot dashboard set has been signed off by the pilot users and the metric owners, and all open differences are either resolved or accepted in writing.
Run both tools in parallel
Keep the Power BI reports live while the matching Metabase content refreshes from the same source data for an agreed period. At a fixed review point, compare totals, trends and filtered views between the two tools for every in-scope metric and record the variance for each. Investigate any variance until it is explained by a known difference, such as a refresh timing gap or a filter default. The step is done when the parallel run has produced a reconciliation report that the metric owners have signed, with no unexplained variances for the metrics in scope.
Cut over by audience group
Move consumers in audience groups rather than all at once, starting with the group whose reports have the lowest dependency on other content. For each group, publish the Metabase links, retire scheduled Power BI subscriptions for that group, and confirm sign-in works through your chosen identity method, such as Google sign-in, LDAP, or SSO on a plan that includes it. Keep the Power BI copy read-only for a defined fallback window agreed with the business. The step is done when each group has a recorded cutover date, a communication sent, and a confirmed list of users who can sign in.
Archive Power BI content and export records
Before removing anything, export the Power BI content that must be retained, using .pbix downloads where permitted and the documented export paths for models that block download. Store the exports, the inventory, and the reconciliation records in a location your records policy covers. Confirm with your compliance and records owners which items must be kept and for how long. The step is done when an archive index lists every retained artifact, its location, and its approver.
Decommission Power BI licenses and capacity
Remove Power BI Pro and Premium Per User assignments, release Fabric or Premium capacity, and retire Power BI Report Server if it was in use, after confirming that no scheduled jobs or embedded views still depend on them. Check your contract or Microsoft licensing terms for notice periods and renewal dates before changing anything, because those set when savings take effect. Record the decommission date and the date each license or capacity was released. The step is done when the license and capacity inventory shows zero active Power BI assignments, the decommission date is recorded, and the owner of the Metabase environment has accepted operational responsibility.

How DAX logic is rebuilt as SQL or Metabase models

DAX measures do not import into Metabase, so every measure has to be rewritten by hand. In practice there are three destinations: a native SQL question for a one-off or low-traffic figure, a reusable Metabase model that exposes a clean, joined table for business users to build on, or a database view or transformation upstream in the warehouse, where the logic is shared by every tool that reads the data. Decide per measure, not per report. Measures that feed many dashboards, such as revenue, active customers or margin, belong upstream. Measures that only one analyst uses can stay as a native question. Start by exporting the semantic model and listing each measure with its filter context, including CALCULATE modifiers, time intelligence functions and ALL or REMOVEFILTERS patterns, since these are where rewrites most often diverge.

Shared calculations should live in version-controlled SQL views or dbt-style transformations, not inside individual Metabase questions. That gives each definition a file, a review history and a test suite, and it lets the data team check row counts, null handling and grain before a dashboard is published. Power Query steps have no automatic equivalent either. Type conversions, merges, unpivots and custom columns must be reproduced in the database or in your transformation tool, and the Power Query M source should be archived alongside the SQL so the lineage stays readable. Confirm which Metabase edition you will run before you design the model layer, because the features you rely on for permissions and sign-in differ by plan.

Run a parallel period in which Power BI and Metabase show the same figures for the same filters. Reconcile totals at the grand-total level first, then at each grouping level, because a measure that is correct in a matrix can still be wrong in a card or a single-row visual where the filter context is different. Pay particular attention to date tables, time zones, blank handling, distinct counts and relationship direction, which often explain the gaps. Record every difference and its cause in a reconciliation log that your business owners sign off. Treat a mismatch you cannot explain as a blocker for cutover rather than a rounding issue to accept.

What SSO and row-level security cost on paid Metabase plans

The Open Source edition is free to self-host and has unlimited users and dashboards, so the licensing line for this plan is zero. What it does not include is SSO beyond the basics, and it does not include row and column level permissions. Teams moving from Power BI often assume that a free edition will carry their security model across unchanged, and that assumption is where the planning effort starts.

Sign-in options: Google sign-in and LDAP are available, and email and password accounts can be used for smaller groups.
Permissions: Access is managed through groups and collection permissions, not per-row rules.
Operating cost: Your costs are the servers, the PostgreSQL application database, backups and the staff time to run upgrades.
Identity gap: Power BI users signing in with Microsoft Entra ID need a remapped path, either through LDAP or a plan that supports SAML or OIDC.
Security rules: Row-level restrictions from Power BI roles must be rebuilt as separate questions, models or database views.

Confirm with Metabase which sign-in methods the current Open Source edition supports before you design the identity architecture.

Data, identities and integrations to move or rebuild

Moving Power BI consumers to Metabase is less a file copy than four separate workstreams: report definitions, identities, data connections and scheduled delivery. Each one has a different source of truth and a different failure mode, so each needs its own owner and check. Start with the application database decision, because everything Metabase stores sits there.

Report and semantic model definitions

Export .pbix files from the Power BI service where a Contributor can download them with data. Direct Lake models, models with incremental refresh and models over 50 GB cannot be downloaded with their data, so plan to rebuild those from source. Rewrite DAX measures as SQL questions or Metabase models and metrics, and check each total against the Power BI figure before retiring the original. Confirm the download options against Microsoft's current documentation for your tenant.

Users, groups and permissions from Entra ID

Map Microsoft Entra ID groups to Metabase groups before users log in, and decide who owns each collection. Google sign-in and LDAP are available on the free edition, but SAML, OIDC, JWT and SCIM provisioning require Pro or Enterprise. Row-level permissions on Metabase also sit on Pro and Enterprise, so any Power BI row security rule must be rebuilt in the paid tier or in the database. Ask Metabase to confirm which identity setup your plan supports.

Data source connections

Recreate every Power BI data source as a Metabase database connection, using service accounts with read-only grants rather than personal credentials. Power Query steps that reshape data upstream must move into SQL views, dbt models or the warehouse, because Metabase does not run them. Test each connection with the same credentials your production schedule will use, and record which Power Query transformation each view replaces.

Application database for production

Metabase stores users, questions, dashboards and settings in its application database. The embedded H2 database suits demos only, and PostgreSQL is the recommended choice for production, with MySQL 8.4.0 or MariaDB 10.6.0 and later also supported. If a pilot ran on H2, the documented load-from-h2 command moves it to PostgreSQL or MySQL, but it must run with the same Metabase version that last wrote the H2 file. Back up before any migration step.

Subscriptions, alerts and embedded reports

Power BI subscriptions, data alerts and embedded reports each need a Metabase equivalent that is configured and tested by hand. Recreate scheduled email deliveries and alerts with their recipients and thresholds, then confirm that delivery works through your mail relay. Embedded reports depend on the Metabase embedding model, and the tenant isolation logic that Power BI Embedded handled must be rebuilt, so review it with a security tester before go-live.

What drives migration cost and duration

This table lists the inventory and design factors that move the effort of a Power BI to Metabase migration, why each one matters, and how to keep it down. Use it to prepare your own inventory before asking for a fixed-scope estimate, since no duration is given here.

Driver	Why it changes cost or effort	How to keep it down
Number of reports and semantic models	Each report that must be rebuilt as a Metabase question or dashboard adds build and test work. Shared semantic models multiply the effort because one change affects many reports.	Retire unused reports first, using workspace usage data. Consolidate near-duplicate reports before migrating them.
DAX complexity	Measures with context transition, time intelligence or iterators have no direct equivalent in Metabase. Each one is rebuilt as SQL, a Metabase model or a metric, then checked against Power BI results.	Move logic into the warehouse as views or curated tables. Keep a reference set of key measure values to compare against.
Power Query depth	Transformations in Power Query that reshape data must be reproduced upstream in SQL, dbt or the pipeline. Deep, multi-step queries take longer to re-create and validate than simple source connections.	Inventory each query step by step and move shared transformations into one maintained layer. Drop steps that no report uses.
Direct Lake and large-model exclusions	Microsoft lists Direct Lake models, models with incremental refresh and models over 50 GB as blocked from download with data. These need a rebuild from source systems, not a file export, which adds data engineering work.	Identify blocked models early. Confirm source access and credentials for each one so rebuilds start without waiting.
Row-level security rules	Power BI RLS rules are defined in the model and must be restated as Metabase row and column permissions, which are available on paid plans. Each rule needs a test with real user accounts.	Count rules and group them by pattern. Confirm which rules Metabase Pro or Enterprise permissions can express before design starts.
Identity integration needs	Sign-in from Microsoft Entra ID through SAML, OIDC or SCIM, and group sync, depends on plan. Open source and Starter cover Google sign-in and LDAP, so the identity design decides which plan is needed.	Agree the identity method and group mapping with your identity team before building. Confirm the Entra ID setup with Metabase for your plan.
Embedding requirements	If Power BI reports are embedded in customer-facing products, tenant isolation and embedding setup must be rebuilt. This is separate from internal viewing and adds design and testing work.	Separate internal and embedded use cases in the inventory. Review Metabase embedding documentation to confirm what your plan supports.
Plan choice	Open Source is free and self-hosted, but SSO and row and column permissions require Pro or Enterprise. Pro is priced per month with users included, and Enterprise is priced by quote, so the required features set the recurring cost.	Map each requirement to a plan before sizing users. Ask for the Pro or Enterprise price in writing for your user count.
Parallel-run cycles	Running Power BI and Metabase side by side for reconciliation adds cycles of comparison, fixes and sign-off. Each cycle adds effort, and the number depends on how many reports disagree on first comparison.	Agree reconciliation criteria and sign-off owners up front. Limit parallel runs to the reports that carry financial or regulatory figures.

What usually goes wrong and how to prevent it

Most failed Power BI to Metabase moves do not fail on installation. They fail when metrics quietly change meaning, when permissions do not carry over, when old reports stay in use, or when an upgrade touches data that was never backed up. Each card below names one of these risks and the check that catches it before consumers notice.

Mismatched metric definitions

A DAX measure such as a filtered CALCULATE or a time intelligence expression does not always return the same figure as a hand-written SQL query. Differences in null handling, date tables, filter context and rounding show up as numbers that look close but do not match. Before cutover, run both versions side by side for a fixed period and have the finance or business owner sign off each reconciled metric in writing. Record the SQL logic in a Metabase model or metric so the definition has one owner.

Row-level security gaps

Power BI row-level security roles are defined in the semantic model, and Metabase implements row and column permissions as a separate control that depends on your plan. Rules that existed in the model can be missing in Metabase, or applied to the wrong group after sync. Create test accounts for each sensitive segment, sign in as each one, and confirm which rows and columns appear. Check the plan's feature list before relying on the control, because SSO and row-level permissions are paid features and the free edition does not include them.

Unmanaged cutover

When Power BI stays open, consumers keep using the old reports, and figures drift apart over months. Some reports get rebuilt while others are forgotten, and nobody owns the decision to retire them. Publish an inventory of every report with its owner and consumers, mark each one as moved, parallel or retired, and set a dated cutover for each group. Freeze edits to the Power BI source once its replacement is signed off, and tell consumers where the new content lives.

Upgrade failures from automatic migrations

Metabase runs application database migrations automatically when a newer version starts. A failed or interrupted migration can leave the application database in a state that is hard to roll back, so an upgrade is not a simple binary swap. Test each upgrade in a staging copy first, and step through versions in order when you are coming from an old release. Follow the upgrade guidance for the version you are moving to, rather than assuming the last upgrade path still applies.

Skipped application database backups

The application database stores dashboards, questions, users, permissions and settings. Teams that move from the embedded H2 file to PostgreSQL or MySQL often do not back up the result, and lose the work of rebuilding content after a failed upgrade or disk fault. Take and test a backup of the application database before every upgrade. For major upgrades, reduce a clustered deployment to a single node first because of the migration lock, then scale back out once the upgrade is verified.

Questions buyers ask before moving from Power BI to Metabase

What does a move from Power BI to Metabase cost?

The cost is the sum of several components, and only some are licence fees. The Metabase Open Source edition is free to self-host with unlimited users and dashboards, so the software line is zero. The recurring costs are the servers and database that host Metabase, the people who maintain the instance, and any paid Metabase plan you choose for SSO or row-level permissions. Implementation is usually one-time: rebuilding models, questions and dashboards, and setting up sign-in. Ask any quote to split one-time and recurring items, to state what is included in the written scope, and to list the Power BI licences it replaces, such as Pro, Premium Per User or Report Server licensing, so you can compare totals.

How long does a Power BI to Metabase migration take?

The duration depends mainly on inventory: how many reports, semantic models and data sources you have, how much DAX logic sits in measures, and how many Power Query steps must be reproduced upstream. A small set of dashboards on one clean database is far quicker to move than dozens of models with incremental refresh and calculated tables. Before agreeing a timeline, inventory every report and its consumers, mark which ones are used and which are retired, and identify the data sources behind each. A written scope should state the timeline and the assumptions behind it, and should name the reports that will be rebuilt rather than exported.

What does our team need to provide for the migration?

The team needs to supply access and context that only it holds. This includes the Power BI workspaces and report owners who can confirm what each report is for, read access to the underlying databases or warehouse, and a list of the users and groups who consume reports. Your identity provider administrators must be available for sign-in setup, and your infrastructure team must confirm where Metabase will run and which PostgreSQL or MySQL instance will hold its application database. Named business owners should sign off on each rebuilt dashboard. Ask the implementation partner to list these inputs in writing before work starts.

Can our internal team migrate from Power BI to Metabase alone?

Many teams can, provided they have someone who knows the data model and someone who can operate the server. The work is mostly rebuilding logic in SQL and Metabase models, which requires strong SQL skills, plus hosting, backup and identity configuration. Teams without these skills often underestimate the reconciliation work, where rebuilt numbers must match the Power BI originals. A useful test is whether your staff can reproduce three of your most-used reports end to end and check the figures against the source. If not, a fixed-scope engagement can cover the gap, and DeployOpen plans, implements, documents and supports self-hosted platforms in your own infrastructure.

Is the free Metabase edition enough for SSO and row-level permissions?

Usually not on its own, if you need those features. According to the Metabase pricing page, SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included only in the Pro and Enterprise plans, not in Open Source or Starter. The Open Source edition supports Google sign-in and LDAP, but SAML, OIDC, JWT, SCIM and advanced LDAP group sync require Pro or Enterprise. Pro is listed at $575 per month, or $517.50 per month billed yearly, with the first 10 users included, and additional users cost $12 per month. Confirm current prices on the pricing page before budgeting, because they change.

How are Metabase upgrades handled after go-live?

Upgrades are a recurring operational task that should be planned from the start. Metabase runs application database migrations automatically during an upgrade, so the documented practice is to back up the application database first. For major upgrades, reduce a cluster to a single node because of a migration lock, and upgrade release by release if your instance is older than version 40. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months. Choose which line to run and budget for regular upgrade windows, testing and rollback. Ask any support or retainer proposal to state who performs upgrades and how often.

Will the Power BI reports and DAX measures move over automatically?

No. Power BI reports cannot be imported into Metabase, and DAX measures must be rewritten. Metabase works with SQL questions, a semantic-style model layer, and dashboards built on those. Simple aggregations usually translate directly, while complex context-dependent DAX, time intelligence and calculated tables need careful redesign and reconciliation against the originals. Power BI .pbix downloads are blocked for some models, including those with incremental refresh, Direct Lake and models over 50 GB, so you may need to extract definitions from the data source instead. Treat each report as a rebuild with a sign-off check, not a file conversion.

How DeployOpen scopes and runs the Power BI to Metabase migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted Metabase inside your own infrastructure, whether that is your cloud accounts, your data center or an air-gapped network. The work starts with a written scope that names the Power BI reports to be rebuilt, the data sources Metabase will query, the identity provider, the hosting topology and the people who sign off on each deliverable. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any build work begins. A quote follows from that written scope, and DeployOpen does not publish a price list.

Scoping decisions shape the cost more than any single tool choice. The inventory should record which Power BI reports are actually used, which semantic models sit behind them, which row-level security roles apply, and which sign-in method each audience uses today. Those answers determine how much of the work is rebuilding questions and dashboards, how much is recreating DAX logic as SQL or Metabase models, and whether the paid plan features covered in this page's pricing section are needed. Ask for the inventory and the sign-in and permission mapping to be listed as explicit deliverables, so the scope can be checked against them.

Ongoing work is handled separately from the initial build. Metabase releases run database migrations automatically, so upgrades need a tested backup of the application database, a plan for reducing a cluster to a single node during major upgrades, and a validation pass on dashboards afterward. DeployOpen can provide these as a retainer covering support, upgrades and periodic checks, agreed in writing alongside the migration scope. DeployOpen prepares systems, controls and documentation for compliance reviews, but independent auditors and certification bodies issue any audit reports or attestations.

Migrate from Power BI to Metabase