Metabase migration services

What a Metabase migration involves

A Metabase migration moves analytics content into Metabase from one of two sources: reports and dashboards coming from another BI tool, or an existing Metabase instance moving between servers or from Metabase Cloud to a self-hosted deployment. The two paths share a planning discipline but differ in what is actually moved. A tool-to-Metabase move starts from the other platform's exports and definitions, while an instance-to-instance move carries the application database, plugins and settings with it. Confirm which path applies before estimating anything, because the work, risks and vendor interactions are different.

Teams usually trigger these projects for a small set of reasons: a change in license terms or cost, a data residency requirement that puts analytics in infrastructure the organization controls, retiring an older BI tool, or consolidating several Metabase instances into one. Each trigger affects scope. A cost-driven move may keep most content, while a residency-driven move may need a full rebuild of connections and credentials inside the new environment.

Questions, collections and permissions should be rebuilt and then validated, not copied across blindly. Other tools rarely export a meaning that maps one to one onto Metabase models, collections, groups and data permissions, and permission settings tied to an old identity provider or old database accounts will not carry over as intended. Ask the team to inventory which content is still used, who owns it, and which groups can see which data, then check results against source figures before users are cut over.

Most teams with a small number of reports and simple permissions can do this in-house, provided someone owns the data source connections and the validation. Partner help tends to make more sense when report counts are high, when row-level or group-based permissions must be reproduced exactly, or when the move coincides with an upgrade or identity change. Use the implementation plan, upgrade and H2 migration topics for the adjacent work, since those are separate projects with their own steps.

What the migration work includes

The migration is delivered as a fixed set of work packages, each with a named deliverable. Reports and dashboards are rebuilt in Metabase's own model, and the numbers they show are checked against the source before anything is switched off.

Source inventory

Every report, dashboard, scheduled export and alert in the source tool is listed with its owner, last-used date and consumers. This list decides scope: items nobody opens are retired, not rebuilt. Confirm early whether scheduled deliveries to email or file shares must be replaced in Metabase or in another tool.

Data connection mapping

Each source data connection is mapped to a Metabase database connection, with the credentials, network path and schema it uses. Confirm which connections need a read-only service account, and which ones depend on views, extracts or custom SQL that exist only in the old tool.

Rebuilt questions and collections

Source logic is rewritten as Metabase questions, models and collections, not exported as files and imported. Calculated fields, filters and joins are rebuilt from the documented definitions. Expect to simplify some legacy reports during this step, and record every change so business owners can approve it.

Permission and group mapping

Source roles and folder permissions are translated into Metabase groups and collection permissions, with an owner for each group. Check which controls need a paid plan: row and column level permissions and SSO-driven group sync are not available on Open Source or Starter, so those requirements must be confirmed before design starts.

Parallel-run validation

Rebuilt questions run alongside the source reports for an agreed period, and results are compared row by row or total by total. Business owners sign off the source of truth for each number before any cutover. Differences in time zones, rounding and null handling are the most common causes of mismatch.

Cutover and decommissioning

Users, scheduled deliveries and links are moved to Metabase in a planned window, with a rollback path to the source tool until sign-off. Decommissioning removes source access, schedules and data copies in order, and confirms that retention obligations for old reports are met. Agree the cutover date and rollback criteria in writing.

Handover document

The handover covers the inventory, the mapping of connections and owners, group and permission design, validation results, known differences and the operating runbook. It gives your team what it needs to add dashboards and users without the partner. Ask for the document format and review date in the quote.

What drives migration cost and duration

This table lists the main drivers of Metabase migration effort, why each one changes the work, and what you can do before the move to keep it down.

Driver	Why it changes effort	How to reduce it
Source reports and dashboards	Each question, dashboard and collection must be exported, rebuilt or mapped, so volume usually sets the largest share of build time.	Retire unused content before the move and consolidate duplicate dashboards into one parameterized version.
Calculations and custom SQL	Nested logic, custom metrics and native SQL need manual translation and testing against results from the source tool.	Document each business definition first, then rebuild shared logic once as a model or metric that dashboards reuse.
Data sources and connections	Each database needs a connection, credentials, sync settings and a check that results match the original tool.	Confirm which sources are already connected to the target Metabase and who owns each set of credentials before the build starts.
Permissions and group structure	Collection access, group membership and data permissions must be mapped by hand, and each mapping needs testing.	Map current groups to a short list of roles, then test each role with one account. Row and column permissions need Pro or Enterprise.
User count	Accounts drive identity setup, access testing and licensing. Per-user plans charge for seats beyond those included in the plan.	Confirm the target user count early, and remove inactive users and shared accounts from the migration scope.
Edition required	If migrated permissions rely on SSO, row or column permissions or auditing, the plan must include them. Pro lists $575 per month with 10 users included (Metabase pricing page).	Inventory permission and identity features before choosing an edition. Additional users cost $12 per month on Pro (Metabase pricing page).
Number of environments	Each environment, such as test, staging and production, needs its own application database, connections and content checks.	Build in one non-production environment first, then promote configuration with a repeatable script or the Metabase API.

Migration phases and what each produces

The sequence moves reports, permissions and data connections into a self-hosted Metabase in a controlled order, with a check and a deliverable at every phase.

Inventory sources, questions and users
We catalog the existing BI tool or Metabase instance: data sources, saved questions, dashboards, collections, groups and the people who use them, and flag anything that depends on features the target plan does not include. You receive an inventory workbook with owners and a list of items to retire, keep or rebuild, confirmed with your business owners.
Design the target environment
We agree the edition, Metabase version, hosting model and application database choice in writing. PostgreSQL is the production recommendation in the vendor documentation, and MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4 are also supported. You receive a target design record covering these decisions, the upgrade approach and the sign-in method, which you approve before build starts.
Connect data sources with least privilege
We build the database connections in the target environment using dedicated, read-scoped credentials and confirm network paths from the Metabase hosts. You receive a connection register listing each source, its credential owner and a passing connection test, and you confirm that no connection uses an administrative account.
Rebuild questions, dashboards and collections
We recreate saved questions, models and dashboards from the inventory in the agreed collection structure, using the source logic as the reference. You receive the rebuilt content set with a mapping from each source item to its new location, so reviewers can trace every report to its origin.
Map groups and permissions
We translate source roles into Metabase groups and collection and data permissions, following your access model. Single sign-on group sync depends on the plan and sign-in method, so we confirm that before mapping. You receive a permissions matrix that a data owner has signed off.
Validate outputs against the source
We run agreed test queries and compare results, row counts, totals and dashboard figures with the source reports, and test access for representative users in each group. You receive a validation log with each difference explained or fixed, and sign-off from the report owners before cutover.
Cut over and stabilize
We schedule the switch, freeze changes in the source, take a backup of the application database before any move, and redirect users. Metabase upgrades run application database migrations automatically, so the backup is also your rollback point for later version changes. The stabilization period is agreed in the scope and covers issue triage, access requests and a final handover record.

What to keep in-house and what to outsource

The table lists each Metabase migration activity with its usual owner and the skills it needs, so you can see which parts to keep with your team and which to hand to a partner.

Activity	Usual owner	Skills required	Notes on the split
Inventory and sign-off on which reports matter	In-house	Knowledge of business owners, usage history from the source BI tool, prioritization	Only your staff can decide which reports the business still relies on
Data source access and credential setup	Shared	Database administration, least-privilege account design, Metabase data source configuration	Your team approves access and secrets; the partner configures connections and tests them
Rebuilding questions and collections	Often outsourced when volume is high	SQL, the source BI tool's data model, Metabase question and model building	Partner effort grows with the number of reports; a sample pilot helps size the work
Permission and group mapping	Shared	Metabase permissions, identity provider group design, data governance	Depends on identity decisions made by your security and IT teams before build
Parallel-run validation	Independent review recommended	SQL reconciliation, business metric knowledge, test planning	Reviewers who did not build the reports catch differences more reliably
Application database move and upgrades	Shared	PostgreSQL or MySQL administration, backup and restore, Metabase upgrade procedure	Confirm the target database version and utf8mb4 support against the Metabase application database docs
Cutover and hypercare	Shared	Change management, monitoring, Metabase administration, incident response	Your team owns go or no-go decisions; the partner supports the cutover window and early issues

What goes wrong in Metabase migrations

Most Metabase migration problems come from decisions made late or skipped entirely. The cards below name the failure, then the step that prevents it.

Metric definitions drift from the source tool

A revenue or active-user figure built in the old BI tool rarely reproduces exactly in Metabase, because joins, filters, time zones and null handling differ. Run the old and new reports side by side for an agreed period and reconcile totals before any user switches over.

Permissions the target edition cannot express

Row-level and column-level permissions and SSO are included only in the Pro and Enterprise plans, not in Open Source or Starter. Confirm the required edition against the permission matrix before build, because a restriction the old tool enforced may have no equivalent on the plan you buy.

Groups that do not map cleanly

Groups in the source system often reflect org charts, teams or projects, while Metabase groups control data access and collection rights. Map each source group to a Metabase group in a written table, and identify users who belong to several groups whose combined access must be checked.

Dashboards waiting on unconnected data sources

A dashboard can be moved into Metabase while the database it reads from is still undefined, so it appears finished but returns errors or empty charts. Inventory every dashboard's underlying sources and connect and test each one in staging before the dashboard is scheduled for migration.

Missing source-of-truth sign-off

Without a named owner for each metric, nobody can decide which version is correct when the old and new results differ. Require a sign-off record per metric and dashboard from the business owner before cutover, and keep it with the migration log.

Cutover without a rollback path

If the application database is changed during cutover and no restorable copy exists, returning to the previous state may be impossible. Take a backup of the Metabase application database, confirm it restores to a test instance, and document the exact steps and owner for reverting before the switch.

How the migration changes by starting point

Moving from another BI tool is a rebuild, not a copy. Questions, collections and permissions have to be re-expressed in Metabase's model, so the first decision is what you carry over and what you retire.

Semantics: Map each report's calculations, joins and filters to Metabase questions, models or metrics. Some logic from the old tool may not translate directly, so flag it early.
Metric definitions: Agree one written definition per business metric with its owner before building dashboards, so numbers match the old reports during validation.
Access model: Translate the old row, folder and dashboard permissions into Metabase groups and collection permissions. Row and column level permissions require Pro or Enterprise.
Identity: Confirm which sign-in method applies. SAML, OIDC, JWT and SCIM need Pro or Enterprise, while Google sign-in and LDAP are available on Open Source and Starter.
Parallel run: Plan a period where both tools answer the same questions, and compare results before retiring the old reports.

What your team needs to provide

Your team supplies access, inventory and decisions before any questions or collections are rebuilt. Read access to the source BI tool and its exports lets us compare what exists with what is rebuilt in Metabase. A current inventory of reports and dashboards, with a named owner for each, shows which items are live, which are duplicates and which can be retired. Late inventories are the most common reason a migration plan changes after kickoff.

Database credentials are needed for each source, each scoped to least-privilege read access on the schemas that the reports use. Your identity team provides the identity provider and group structure, since groups drive Metabase permissions. Also provide the target user count, which affects the edition decision, and a named business owner for each key metric so definitions can be confirmed before validation begins.

Decide the target edition early. The pricing page places SSO, row and column level permissions, and usage auditing in Pro and Enterprise only, so any current setup that relies on SAML, OIDC or row-level security needs a paid plan before permissions are rebuilt. Your team also provides a maintenance window for cutover and a host for the target Metabase and its application database, where PostgreSQL is the recommended production choice.

Two items must be confirmed in the current Metabase documentation before the plan is final: admin access to any Metabase Cloud instance being moved, and the encryption key used by the existing install. The key determines whether stored database connection details can be carried across without re-entry. Ask your team to locate both now, record who holds them, and agree how they are handled during the move.

Frequently asked questions about Metabase migration

Can our own team handle a Metabase migration in-house?

Yes, if your team has the database, identity and Metabase skills to run the work and the time to validate it. A migration needs an inventory of questions, dashboards, collections and permissions, a target application database (PostgreSQL is the production recommendation), data source connections, and a validation step that someone signs off. Gaps often appear at validation. Before deciding, list what you must provide: read access to source tools and databases, the people who own each dashboard, and an agreed change window. A partner can take the rebuild, the validation, or both, under a written scope.

What drives the cost and timeline of a Metabase migration?

The scope drives most of it: how many questions and dashboards exist, how many data sources they use, how complex the permission model is, whether SSO is in scope, and how much validation each figure needs. Metabase licensing is a separate line. Per Metabase's pricing page, Starter is $90 per month billed yearly with the first 5 users included, and Pro is $517.50 per month billed yearly with the first 10 users included. Additional users cost $6 per month on Starter and $12 per month on Pro. Ask for a quote that separates one-time work from recurring costs and names who performs each step.

Can we copy questions and dashboards directly from another BI tool?

Usually not as a direct copy. Each source tool stores its logic differently, so questions are rebuilt in Metabase, with SQL logic ported where it is portable and reviewed against the source. Expect to recreate filters, joins, calculated fields, dashboard parameters and collection layout. Start with an inventory that lists each report, its owner, its data source, its refresh schedule and its users. Retire reports nobody opens before you rebuild them, which reduces the volume you must validate. Confirm with your own team which features in the source tool have no direct equivalent in Metabase.

Do permissions and SSO carry over to the free edition?

Not in full. Metabase's Open Source and Starter plans support Google sign-in and LDAP. SAML, OIDC, JWT, advanced LDAP group sync and SCIM provisioning require Pro or Enterprise. According to Metabase's pricing page, SSO, row and column level permissions, and usage analytics and auditing are limited to Pro and Enterprise. If your source tool used SAML or row-level rules, those controls must be redesigned or licensed before cutover. Map each existing group and access rule to what your target edition can enforce, and record any gap as an accepted risk or a plan change.

Does moving Metabase Cloud to a self-hosted server need downtime?

Confirm this with Metabase for your plan, because the answer depends on which export and import options apply to your account. Plan a cutover window in which edits are frozen, the new instance is loaded, sign-in and permissions are tested, and users are pointed to the new address. Keep the Cloud instance unchanged until validation passes so you can return users to it if needed. Your self-hosted environment also needs a production application database, TLS, backups and a tested rollback before go-live.

How do you confirm migrated numbers match the source?

Compare each migrated question with its source using the same filters, date range, time zone and currency, then get sign-off from the owner. Practical checks include row counts, totals for key measures, spot checks of individual records, and a side-by-side run of the old and new dashboards over a fixed period. Record each result, the query used and the owner's approval so the evidence can be reviewed later. When two figures disagree, ask the owner which one is authoritative, because differences often come from logic or time zone rules rather than data loss. Your team provides source access and business owners.

How DeployOpen runs Metabase migrations

DeployOpen plans and carries out Metabase migrations inside your own infrastructure, whether reports come from another BI tool or an existing Metabase moves between servers or from Metabase Cloud to self-hosted. We rebuild questions, collections and permissions, then check that results match the source before cutover.

How we scope

Inventory the source reports, dashboards, collections and permission groups that the written scope will cover.
Confirm which data sources, application database and plan edition the migrated Metabase will run on.
Agree in writing which items move, which are retired, and how results will be compared during validation.

How we build

Rebuild questions, dashboards and collections in a staging Metabase connected to the same databases as production.
Map source permissions onto Metabase groups and collection rights, and document each mapping decision.
Compare migrated results against source outputs for each agreed report, and log every variance with its cause.

How we hand over

Deliver an inventory of migrated content with owners, source references and validation results for your review.
Document the cutover runbook, including application database backup, rollback steps and post-switch checks.
Walk your administrators through permissions, collection structure and the items that still need owner sign-off.

How we support

Offer post-migration support for fixes and questions as a retainer, where your engagement includes it.
Plan Metabase version upgrades and their application database backups as a separate, scoped piece of work.
Confirm with your team which support window, response expectations and change process apply after go-live.

Metabase migration