Migrate from Domo to Metabase

Migrate from Domo to Metabase: what the move involves

Metabase can carry a business dashboard workload from Domo, but the harder part is moving the data underneath it. Metabase does not ingest data the way Domo does. It queries a database or warehouse you already run, so the connectors, ETL dataflows and stored datasets that Domo bundles must be rebuilt upstream in a warehouse or database Metabase can reach before any card is recreated. Teams usually start this move after consumption credit costs rise or when a data residency requirement means Domo-hosted data can no longer stay where it is. Expect the work to fall into two streams: relocating datasets and their refresh logic, and rebuilding cards as questions and dashboards. Effort and risk depend mostly on how many Magic ETL flows feed each dashboard and how many people depend on them, so inventory those dependencies before estimating anything.

Internal BI or platform staff usually own the migration, often with an implementation partner for the pipeline and permission design. The people who know the business definitions behind each Domo card should review every rebuilt metric, because a Metabase question can return a number that looks right and still uses a different filter or time basis. Confirm with your own team which Domo exports you can take: the Domo documentation and your administrator should show what can be extracted from each dataset and in what format. Also confirm which connectors your target warehouse already supports, since any source Domo reached through a bundled connector needs a new ingestion path. Those confirmations decide whether the rebuild is a rewrite or a repointing exercise, and they shape the cutover plan.

Plan the cutover around the dashboards people open every day. Run Metabase and Domo in parallel for a defined set of reports, compare results with the business owners, and retire Domo content only after those owners sign off. Keep the Metabase application database on PostgreSQL rather than the embedded H2 database, which Metabase itself treats as suitable for demos, and back it up before each upgrade. Check Metabase's version support page when choosing the release line, since LTS and non-LTS releases have different end-of-life dates. Row-level rules that Domo enforced through its own permission model should be mapped to Metabase groups and sandboxing settings on your chosen plan, and the cost of that plan belongs in the business case from the start.

Which Domo capabilities map cleanly to Metabase

This table maps the Domo capabilities a business-dashboard team usually depends on to their nearest Metabase equivalents, marking each as clean, needs rework or gap. Read it as a checklist: the rows marked needs rework or gap are where you should plan design time or a separate tool before cutover. Confirm connector coverage and embedding needs against your own environment before committing to a scope.

Domo capability	Metabase equivalent	Fit
Cards and dashboards	Questions (saved queries and charts) assembled into dashboards with filters	Clean
Beast Mode calculations	Custom expressions in the query builder or saved SQL questions; complex logic often moves into models	Needs rework
Datasets as reusable sources	Models and saved questions that other questions build on	Needs rework
Row-level access rules	Row and column level permissions, available on Pro and Enterprise plans only, not on Open Source or Starter	Needs rework
Scheduled delivery of dashboards	Dashboard subscriptions and alerts by email or Slack, confirm the delivery channels you use	Clean
Embedding dashboards for external users	Metabase embedding, with the isolation rules enforced by your host application; confirm plan requirements for your model	Needs rework
Connectors and Magic ETL pipelines	Metabase reads from your database or warehouse but does not extract, transform or load data; a separate pipeline tool is required	Gap
Domo-hosted storage and dataflows	Storage and transformations move to your own warehouse, which Metabase then queries	Gap

What data and integrations must move, and by which documented path

A Domo to Metabase move has three moving parts: the datasets Domo currently feeds, the pipelines that produce them, and the Metabase instance and its sign-in. Each card below covers one of these so the inventory can be scoped before any cards are rebuilt.

Inventory dataset sources and export paths

List every Domo dataset that backs a card, including its source connector, refresh schedule and downstream owner. Metabase queries a database or warehouse, not Domo, so each dataset needs a durable home first. Do not assume a Domo export API exists for your tenant. Ask Domo to confirm which export paths are available to you, and record which datasets can be extracted in full and which need a rebuilt source.

Relocate datasets into a queryable warehouse

Choose a PostgreSQL, MySQL or warehouse target that Metabase can connect to, and load each dataset there with its keys, data types and history intact. Illustrative example: a sales table with a monthly snapshot needs the snapshot dates preserved, or trend cards will silently change. Confirm that your chosen database has a supported driver and that the service account used by Metabase has read access only.

Rebuild Domo pipelines outside Domo

Domo dataflows and Magic ETL steps do not carry into Metabase, so each transformation must be rebuilt in a pipeline tool your team operates, or as SQL views in the warehouse. Document every join, filter and calculated field as you go, because Metabase questions will depend on these outputs. Treat the pipeline rebuild as the largest effort item, and estimate it from your dataflow count rather than from card count.

Move the application database from H2

Metabase ships with an embedded H2 application database for demos, and its documentation recommends PostgreSQL for production. The one-time load-from-h2 command moves that data, and it must run with the same Metabase version that last updated the H2 file. Plan this on a copy first, and confirm the target database meets the supported MySQL or MariaDB versions if you do not use PostgreSQL.

Re-point identity to supported SSO

Domo users and groups must be recreated under Metabase's sign-in options. Google sign-in and LDAP are available on the open source and Starter plans, while JWT, OIDC, SAML and SCIM provisioning require Pro or Enterprise. Confirm which identity method your organization uses before choosing a plan, because the choice determines whether group-based row rules can be enforced.

The migration sequence from inventory to decommission

This sequence moves Domo dashboards for business teams onto Metabase in an order that proves each step before the next one depends on it. Each step ends with a written output, so the cutover decision rests on evidence rather than on memory of what Domo did.

Inventory cards, datasets, row rules and users
Export the full list of Domo cards, pages, datasets, dataflows and their owners, along with every row-level rule that limits who sees which records and every user and group that holds access. Record which cards are used weekly, which are stale and which feed a recurring business meeting. The output is a card register that maps each card to its source dataset, its consumers and its access rule, and this register becomes the scope for everything that follows.
Decide the warehouse and retire unused content
Confirm where each dataset will live after Domo, since Metabase queries a warehouse or database and does not replace Domo's ingestion. Ask your data team which systems already hold the source data and whether a warehouse exists or must be built. Mark cards that nobody uses for retirement so they are not migrated. The output is a signed-off target for each dataset and a shortened register of cards in scope.
Pilot one business domain end to end
Choose a single business domain, such as sales operations or finance reporting, and move its datasets, questions, dashboards and access rules into a non-production Metabase instance on PostgreSQL. Rebuild row rules as Metabase permissions for the plan you pick, and test them with a user from each group. The output is a validated pilot dashboard set with a short list of defects and the fixes applied, which shows whether the approach holds before you scale it.
Build pipelines and the production application database
Stand up the pipelines that load each in-scope dataset into the warehouse on the refresh schedule the business needs, and deploy the production Metabase with PostgreSQL as its application database. If you started on the embedded H2 database during the pilot, use the documented load-from-h2 command with the same Metabase version that last wrote the file. The output is a documented pipeline schedule and a production instance that passes a backup and restore test.
Run both platforms in parallel and reconcile
For a set period agreed in advance, have business owners use Domo and Metabase side by side and compare key figures for each in-scope card against the same source data. Log every difference, its cause and its resolution, including timing differences from refresh schedules and changes in how calculations treat nulls or time zones. The output is a reconciliation log in which each card shows a matched result or an accepted, explained variance.
Cut over users and sign the checklist
Move the in-scope audiences to Metabase, redirect links and scheduled reports, and confirm access for each group in the production instance. Complete a cutover checklist covering data freshness, permissions, alert and subscription delivery, support contacts and a rollback path. The output is a signed cutover checklist from the business owners and the platform owner, which records the date Domo stopped being the source of record for each domain.
Decommission Domo and archive evidence
After the agreed stabilization period, disable Domo dataflows and scheduled jobs, revoke connector credentials and user access, and confirm with Domo's terms and your contract what happens to stored data and exports. Export a final copy of card definitions and the reconciliation records for your records. The output is a decommission record showing that no active jobs, credentials or user accounts remain in Domo and that the evidence is archived under your retention rules.

How Metabase's application database and upgrades shape the plan

The first decision is where Metabase keeps its own state. Metabase ships with an embedded H2 application database, which is suitable for demos, and recommends PostgreSQL for production. MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4 are also supported. Plan for PostgreSQL from the start, because the application database holds questions, dashboards, users, groups and permission settings, and moving it later is an extra step. If a pilot was built on H2, Metabase documents a one-time load-from-h2 command to move the data to PostgreSQL or MySQL. That command must be run with the same Metabase version that last updated the H2 file, so record the version before anything else changes.

Every upgrade runs application database migrations automatically. Before any upgrade, back up the application database and confirm the restore works on a copy. For major upgrades, Metabase's upgrading guide recommends reducing a cluster to a single node because of a migration lock, so schedule a short maintenance window and confirm with your platform team how scaled-out nodes will be stopped and restarted. If your current instance is on a release older than 40, plan to upgrade one release at a time rather than jumping straight to the latest version.

Choose the target version with the support calendar in view. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after two months. Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027, and Metabase 65 followed on 12 October 2026. For a business-dashboard migration, most teams will prefer an LTS line so that upgrades are less frequent, but confirm the current status on Metabase's version support page before you fix the date, since the calendar moves forward.

What drives migration cost and duration

This table breaks migration cost into its components, shows who is paid for each, and names the drivers that push effort up or down. Use it to shape the written scope and the questions you put to any quote, since no DeployOpen prices or durations are implied here.

Cost component	Who is paid or who carries it	One-time or recurring	What drives it, and how to keep it down
Internal staff time	Your BI owners, data engineers and security reviewers	One-time during migration, then recurring for card upkeep	Card and dataset count drives it. Retire unused Domo cards before export so you rebuild only what business teams open.
Implementation partner fees	A partner such as DeployOpen, paid under a fixed written scope	One-time per agreed scope	Scope size, row rule complexity and validation depth set the fee. Ask for deliverables listed by dataset and dashboard.
Warehouse and pipeline infrastructure	Your cloud account or data center, plus the warehouse vendor if you use one	Recurring compute and storage, plus one-time setup	Number of sources and refresh frequency drive it. Consolidate feeds into one warehouse before sizing.
Metabase plan choice	Metabase, per its pricing page: Open Source is free, Starter is $100 per month ($90 billed yearly) with 5 users, Pro is $575 per month ($517.50 billed yearly) with 10 users, Enterprise is quoted from $20,000 per year	Recurring subscription on paid plans	Row and column permissions, SSO and multi-tenant segregation are included only in Pro and Enterprise. Confirm which controls you need before choosing a plan.
Identity integration	Your identity team and the partner, scoped in the written plan	One-time setup, then recurring access reviews	SAML, OIDC, JWT and SCIM sync need Pro or Enterprise. Document your group structure before the build starts.
Row rule mapping	Partner and your data owners who approve the rules	One-time per rule set	Each Domo PDP-style rule becomes Metabase permission logic by plan. Simplify rules into groups where possible.
Support and upgrades	Metabase for paid support, and your team or a retainer partner for upgrades	Recurring	Metabase LTS releases are supported for 14 months and non-LTS for about 2 months, so plan a regular upgrade cadence. Backing up the application database before each upgrade is part of the cost.
Validation depth	Your business owners and, where needed, an independent auditor	One-time per dashboard set, then periodic	Number of figures you reconcile against Domo drives effort. Agree a sample of key metrics and a tolerance before cutover.

What usually goes wrong and how to prevent it

Most Domo to Metabase migrations fail on details rather than on the tool itself. The cards below cover the failures that recur during parallel runs, permission mapping, identity, connectors, upgrades and cutover, with the prevention step for each.

Numeric drift during parallel runs

Domo Beast Mode formulas, dataflow rounding and time zone handling often differ from the SQL that Metabase generates against the same warehouse. Teams see one dashboard show 1,240 and the other show 1,236 and lose trust in both. Before parallel runs begin, agree on a reference set of metrics, compare totals at the grain the business uses, and sign off each difference in writing. Ask whether the Domo export and the Metabase question read the same filter boundaries.

Row rules not translated to permissions

Domo row-level rules, often set through PDP-style policies on datasets, do not carry over automatically. If they are not rebuilt, a regional manager may see every region after cutover. Map each Domo rule to a Metabase group and a row or column permission, then confirm which Metabase plan includes row and column level permissions. Per the Metabase pricing page, those permissions are included only in the Pro and Enterprise plans, not in Open Source or Starter, so the plan choice is a design decision. Test each rule with a sample user from every group.

Users lost in identity mapping

Domo users, groups and external accounts rarely match the directory that Metabase will use. Accounts can be duplicated, orphaned or given the wrong group, and former staff may keep access. Decide early which identity source is authoritative, and confirm which sign-in methods your plan supports. Per Metabase's people and groups documentation, Google sign-in and LDAP are available on Open Source and Starter, while SAML, OIDC, JWT and SCIM require Pro or Enterprise. Reconcile the user list against the directory before inviting anyone.

Dependence on Domo-only connectors

Domo ships many prebuilt connectors that run inside the platform, and some datasets depend on them. When a source has no equivalent connector in your pipeline tool, the data stops arriving in the warehouse Metabase queries. Inventory every dataset and its connector before design starts, mark each one as replaced, rebuilt or retired, and assign an owner to each source that has no direct replacement. Build the warehouse load for these sources first, because Metabase depends on it.

Upgrades run without backups

Metabase runs application database migrations automatically during upgrades, so a failed upgrade can leave the application database in a state that is hard to roll back. The upgrade guidance recommends backing up the application database first, reducing a cluster to a single node for major upgrades because of a migration lock, and upgrading release by release from versions older than 40. Schedule each upgrade against a tested restore, and confirm the target release against the version support page before you start.

Scheduled reports and alerts forgotten

Domo subscriptions, alerts and scheduled email deliveries often run quietly for teams that never open the dashboard. When the platform is switched off, these notifications stop without warning, and finance or operations may notice weeks later. Export a list of every schedule, alert and recipient from Domo, recreate each one in Metabase or a replacement channel, and run both in parallel until each recipient confirms receipt. Make the list a cutover gate, not an afterthought.

How the migration differs by starting point

A team with a few dozen cards that all read from one warehouse usually has the simplest path. Most of the effort is rebuilding questions and dashboards against tables that already exist, because Metabase queries the warehouse directly and does not need Domo's connectors or dataflows copied across. The main decision is whether the warehouse already holds clean, documented tables for each card, or whether some Domo dataflows contain logic that must be recreated first.

Warehouse tables: Confirm each card's source table exists in the warehouse and matches the Domo dataset's grain and filters.
Card inventory: List every card with its owner, refresh frequency and audience, then retire cards nobody opens.
Rebuild as questions: Recreate simple cards as Metabase questions and group them into dashboards by audience.
Open Source edition: The free self-hosted edition offers unlimited users and dashboards, so a small team may not need a paid plan at the start, provided it does not need the features the pricing page reserves for Pro or Enterprise.
Application database: Plan to move from the embedded H2 database to PostgreSQL before production use, as the docs recommend.

Before starting, check which Domo cards depend on Beast Mode logic or Magic ETL steps, because those are the items most likely to need a rewrite rather than a copy.

Questions buyers ask before moving from Domo to Metabase

How much effort and cost should we expect when moving from Domo to Metabase?

The effort depends mostly on how many datasets, cards and dashboards you run, how much of your logic lives in Domo-specific transforms, and how many row-level rules you enforce today. Costs fall into a few components: the warehouse or database that holds the data, any pipeline tool that replaces Domo's ingestion, the Metabase hosting and application database, and the people who do the rebuild. Metabase's Open Source edition is free to self-host with unlimited users, while the pricing page lists Starter at $100 per month ($90 billed yearly) and Pro at $575 per month ($517.50 billed yearly). Ask any implementation partner for a quote built from a written inventory of your Domo content.

How long does a Domo to Metabase migration take?

The timeline is set by the inventory and the data work, not by the number of charts alone. Teams usually finish the dataset move and the permission design first, then rebuild cards in priority order, then run both platforms in parallel while business users compare results. No researched duration is available for this migration, so ask for a timeline in your written scope that lists each phase, the owners and the acceptance checks. Plan for the cutover window to include a Metabase upgrade path if you start on an older release.

What does the migration need from our internal staff?

Your team needs to supply knowledge that exists only inside your organization. Data owners must confirm which datasets are authoritative and which Domo dataflows produce them. Analysts must explain the business meaning of each important metric, because Beast Mode style calculations need to be rewritten as SQL or Metabase questions. Security or identity staff must decide how Metabase users, groups and row rules map to your directory. Expect these people to spend time reviewing outputs side by side with Domo, so ask the partner to name who approves each dashboard before work begins.

Can our team migrate from Domo to Metabase without a partner?

Yes, a capable internal team can do this, provided it has someone who can run Metabase, manage a PostgreSQL database and write SQL against your warehouse. The main risks for an in-house effort are the data pipeline work that Domo currently hides, the permission model, and the cutover itself. An outside partner can take fixed-scope pieces such as the inventory, the self-hosted deployment, hardening and backups, or the rebuild of a defined set of dashboards. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure under written, fixed-scope agreements.

Do our Domo row-level rules carry over to Metabase?

Only some of them carry over directly, and the plan you choose determines how. Metabase's pricing page states that row and column level permissions are included in the Pro and Enterprise plans, not in Open Source or Starter. On a lower plan, you would need to enforce row restrictions another way, such as separate database views or separate collections. Before you commit to a plan, list each Domo row rule, decide whether it belongs in the warehouse, and test that a restricted user cannot see another segment's data in Metabase.

What happens to Domo connectors that Metabase does not have?

Metabase is a query and visualization layer, so it does not replace Domo's bundled connectors and ingestion. Each source you pulled through a Domo connector needs an alternative route into your warehouse, such as a pipeline or integration tool you run yourself. Make a list of every connector in use, then confirm for each one whether a self-hosted tool can load it and who will maintain the credentials and schedules. Connectors that are rarely used or that feed a single report can sometimes be retired instead of rebuilt.

What should we check in Metabase before choosing a version to run?

Check the version support dates, because they affect how often you must upgrade. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months. Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027. Also confirm your application database choice: Metabase recommends PostgreSQL for production, and its H2 database is intended for demos. Ask your partner to document the upgrade path and a backup step before every upgrade.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans and implements self-hosted Metabase inside your own cloud accounts, data centers or air-gapped network, and migrates Domo dashboards for business teams into it. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and testing are available as a retainer.

How we scope

Inventory every Domo card, page and dataset that business teams use, and mark which ones are still needed.
Agree where datasets will be loaded into a warehouse that Metabase can query, and who owns that warehouse.
Map each Domo row-level rule to a Metabase permission group and plan tier, and confirm which plan you need before build starts.

How we build

Deploy Metabase with PostgreSQL as the application database, backed by your own infrastructure rather than a demo H2 database.
Rebuild priority cards as Metabase questions and dashboards, and test each one against Domo output using agreed sample figures.
Configure groups, permissions and sign-in (such as SSO on the plan you select), then test access for each business role.

How we hand over

Document the data loads, Metabase configuration, permission model and runbook for upgrades and backups.
Run a cutover rehearsal with the agreed business owners, including a fallback path back to Domo for a defined window.
Hand over administration access and training material so your own team can add questions, dashboards and users.

How we support

Provide ongoing support, upgrades and continuous testing under a retainer when you want DeployOpen to keep operating the stack.
Plan Metabase upgrades against the published version support schedule, with application database backups taken first.
Confirm with your auditors or assessors which evidence they need, since DeployOpen prepares controls and evidence but does not issue audit reports.

Migrate from Domo to Metabase