How to migrate from Metabase Cloud to self-hosted Metabase
A team running Metabase Cloud that wants the instance in its own cloud account or data center can move its questions, dashboards, people and settings. The migration starts with a snapshot of the application database, and only Metabase's success team can provide that snapshot, so customers cannot generate it themselves. Effort depends on five things: the snapshot timing, version matching, the PostgreSQL setup, the connected data sources and the identity configuration. DeployOpen scopes these in writing before work starts.
Snapshot timing is the first dependency. The snapshot is an H2 file (.mv.db) that is loaded into an empty self-hosted application database with the load-from-h2 command. Anything changed in Cloud after the snapshot is missing from the new instance. Plan a cutover window, freeze edits to questions, dashboards and permissions during it, and ask Metabase when the snapshot is taken and how long delivery takes. Agree with the content owners how any late changes will be re-entered.
Version matching is the second dependency. The load must run with a Metabase JAR of the same major version as the Cloud instance. Confirm the Cloud version with Metabase before you download a JAR. After the load, plan the upgrade to the release you will keep running. Check the version support page first, because LTS releases are supported for 14 months and non-LTS releases usually reach end of life after 2 months.
PostgreSQL setup comes next. Metabase recommends PostgreSQL for the self-hosted application database, and the migrated database becomes your system of record. Choose a supported major version that will still be in support when the instance goes live. Confirm who owns backups and point-in-time recovery before the load, and confirm network access, sizing and the connection path from Metabase.
Connected data sources and identity need their own checks. Each database that Cloud reaches must be reachable from your network, with firewall rules and service accounts that you control. If Cloud uses SSO, the self-hosted instance needs its own identity configuration, and SSO requires a Pro or Enterprise plan. Cloud Pro customers must cancel Cloud Pro and buy a self-hosted Pro plan with a license token, so confirm billing timing to avoid a gap in access. Ask DeployOpen for a written scope that names each step, the owner of each check and the post-load verification of questions, dashboards, users and permissions.
Which Metabase Cloud content migrates cleanly
This table compares what Metabase Cloud holds with where each item lands in a self-hosted instance. Read the Cloud column to see what the snapshot carries, and the self-hosted column for what you must set up or verify after loading. The main takeaway is that content and people move through the H2 snapshot, while licensing, SSO, permissions and data source connections need deliberate work.
| Capability | Metabase Cloud | Self-hosted Metabase |
|---|---|---|
| Saved questions and dashboards | Included in the application database snapshot | Loaded with load-from-h2, then checked in the browser after first start |
| Collections | Stored in the application database and included in the snapshot | Verify folder structure and item placement after the load completes |
| People and groups | User accounts and group memberships stored in the snapshot | Accounts load with the snapshot, but group sync and sign-in must be confirmed |
| Settings | Instance settings stored in the Cloud application database | Re-check site URL, email and other settings that depend on the new host |
| Application database | Managed by Metabase, snapshot provided on request to the success team | H2 file (.mv.db) loaded into an empty PostgreSQL database with load-from-h2 |
| Pro plan license | Cloud Pro subscription must be cancelled before self-hosted purchase | Self-hosted Pro plan with a license token, bought separately from Cloud |
| SSO | Requires Pro or Enterprise plan | Requires Pro or Enterprise license; identity provider setup must be configured again |
| Row and column permissions and usage analytics | Requires Pro or Enterprise plan | Requires Pro or Enterprise license; confirm permission rules after the load |
| Database connections, embedding and network paths | Managed in Cloud, with data source reachability handled by Metabase | Configured again; confirm network paths, credentials and embedding setup |
Documented import paths for moving the Metabase Cloud instance
The migration rests on three documented steps: a snapshot from Metabase's success team, a Metabase JAR that matches the snapshot's version, and a one-time load into an empty PostgreSQL application database. Each step has an owner and a check that confirms the next step can start. The cards below set out what each step produces, who runs it and what to verify before moving on.
Snapshot from the success team
Customers cannot generate the application database snapshot themselves, so the request goes to Metabase's success team. The snapshot is an H2 file with a .mv.db extension that holds questions, dashboards, people and settings. Ask the team to confirm which Cloud instance the file came from and the date it was produced. Store the file under the same access rules as your other database backups, because it contains user and permission data.
Matching Metabase version for the load
The load-from-h2 command must run with the Metabase JAR of the same version that last updated the H2 file, and the Cloud instance's major version is the reference point. Ask the success team which version last wrote the file, then obtain that exact JAR from an official Metabase release. Record the version in your change ticket so the load, the startup and every later check refer to the same build. Confirm the version before the import begins, not after it fails.
Load-from-h2 into empty PostgreSQL
Run load-from-h2 once, against an empty PostgreSQL application database, so the import writes into a clean schema. Your platform team runs the command with the matching JAR and the H2 file, then points the instance at the new database through its application database settings. Metabase recommends PostgreSQL for production. Choose a PostgreSQL version still inside its support window, since 14 is supported until November 12, 2026 and 13 and earlier are unsupported.
Post-load checks before users return
After the load, confirm the instance starts on the matching JAR and that questions, dashboards, collections, people and settings match what the Cloud instance showed. Check that group memberships and permissions carried over, since access review depends on them. Take an application database backup once these checks pass, so a later upgrade has a restore point. Keep the Cloud instance and its snapshot until your team signs off the migration.
Paths outside the documented process
Custom export scripts and unofficial converters are not supported paths for this migration, and Metabase's documentation does not describe them. A failed load or missing content produced by such a path cannot be traced to a supported procedure. If a team proposes a non-standard route, ask Metabase's success team for the documented equivalent first. Any remaining option needs its own test environment, rollback plan and sign-off before it touches production data.
Switching a Cloud Pro plan to a self-hosted license
Moving a Cloud Pro instance in house changes the license as well as the hosting. Cloud Pro customers cancel Cloud Pro and buy a self-hosted Pro plan, which comes with a license token that activates Pro features on the instance you run. The Pro plan includes single sign-on, row and column level permissions, and usage analytics and auditing. Before you start the migration, list which of these features your team relies on, such as the identity provider, permission groups and audit reports, so you can verify each one on the self-hosted instance after cutover.
Metabase's pricing page lists Pro at $575 per month, or $517.50 per month billed yearly, with the first 10 users included. Each additional Pro user is listed at $12 per month. Multiply the user count you expect after migration by these figures to build a first estimate, but treat the result as a starting point. Confirm current pricing, the yearly billing terms, how users are counted and how the first invoice is calculated with Metabase before you budget. Ask for the quote in writing so the plan, user count, billing period and start date are stated.
Plan the cancellation date around cutover. Keep Cloud Pro active until the self-hosted instance has loaded the snapshot, runs the matching version and has the license token applied, so your team can still compare results in both environments. Ask Metabase's success team how a cancellation near the snapshot date affects billing, access to the Cloud instance and retention of Cloud data. Store the license token in your secrets manager, limit who can view it, and record which self-hosted instance it was applied to so that later restarts and maintenance work have the token available.
Do not treat the open source edition as a free way to keep the same features. Metabase's open source edition is licensed under the AGPL, while the commercial editions are covered by the Metabase Commercial Software License. These are different license models with different obligations. Pro features come from the commercial license and the token, so a deployment on the open source edition does not include SSO, row and column level permissions, or usage analytics and auditing. Have your legal and procurement teams confirm the license terms with Metabase before the team chooses a license path.
Migrate from Metabase Cloud in five stages with a parallel run
This sequence moves questions, dashboards, people and settings from Metabase Cloud to a self-hosted instance in controlled stages. Each stage closes with a check the platform owner can sign off, and the parallel run gives analysts evidence that results match before Cloud is retired.
Inventory Cloud content, connections, users and SSO
Before requesting anything, list what the Cloud instance holds: collections, saved questions, dashboards, database connections, user accounts, groups, permission settings, and any SSO, email or embedding configuration. Mark every item that depends on a Pro feature, such as SSO or row and column level permissions, because the self-hosted instance will need a Pro plan and license token for those. Record the Cloud version and list scheduled subscriptions and alerts so they can be checked after the move. The inventory is complete when the platform owner has signed it off and each database connection has a named credential owner.
Request the application database snapshot from Metabase
Customers cannot generate the application database snapshot themselves, so your team asks Metabase's success team for a copy of the Cloud application database. Confirm the delivery method, the file format (an H2 file with the .mv.db extension), the Cloud version it came from, and the handling terms that apply to it. Store the file in a restricted location because it holds user records and connection details. The step is done when the file is received, its checksum is recorded, and the version matches the inventory from the previous step.
Load the snapshot into staging PostgreSQL
Provision an empty PostgreSQL database to serve as the self-hosted application database, choosing a major version that is still supported for the expected life of the instance. Run the load-from-h2 command with a Metabase JAR of the same major version as the Cloud instance, pointing it at the snapshot and the new database. Confirm the exact version requirement with Metabase before you run it, because the command must match the version that last updated the H2 file. Start the staging instance and compare collection, dashboard, user and group counts against the inventory. The step is done when the counts match and staging loads without errors.
Back up before any version change
Before you move staging, or later production, to a different Metabase version, take a backup of the application database. Metabase runs application database migrations automatically during an upgrade, so the schema changes as soon as the new version starts. Test the backup by restoring it into a separate database and starting Metabase against that copy. For major upgrades, reduce a cluster to a single node because of the migration lock, and upgrade one release at a time if the source version is older than version 40. The step is done when a restore test succeeds and the upgrade notes for the target version have been reviewed.
Run a pilot with a subset of users
Choose a small group of users that spans analysts, business owners and at least one administrator. Configure SSO for them on the self-hosted instance, which requires the Pro plan, and ask them to test saved questions, dashboards, permissions and scheduled deliveries against the staging copy. Where possible, give pilot connections a read-only database user. Log every defect with its reproduction steps and fix or formally accept each one before wider access. The step is done when the pilot group signs off against a written checklist and no open defects block daily use.
Run Cloud and self-hosted in parallel
Both instances serve users during this stage, with Cloud remaining the system of record until cutover. Agree in advance which key questions and dashboards will be run on both, how results will be compared, and what difference counts as an exception. Account for the fact that data refresh timing can differ between the two instances, so compare against the same data state where you can. Investigate every discrepancy and record its cause. The step is done when the agreed comparison set matches for the agreed period, and each remaining exception has a documented explanation.
Cut over with DNS, identity and license switch
Cancel Cloud Pro, purchase a self-hosted Pro plan, and apply the license token to the new instance. Switch DNS to the self-hosted instance, update the identity provider application registration and its redirect addresses, and confirm SSO sign-in works for the pilot group. Update embedded content, bookmarks and internal links. Ask Metabase how the Cloud instance remains available during the rollback window after cancellation, and write that answer into the cutover plan. The step is done when DNS resolves to the new instance, SSO sign-in succeeds, and scheduled subscriptions have run successfully.
Decommission Cloud after the rollback window closes
Once the rollback window agreed during cutover closes with no open defects, export a final record of the Cloud content and settings and archive it according to your retention policy. Keep the final application database backup from the self-hosted instance under the same policy. Then retire the Cloud instance and remove any remaining credentials, connections and access grants that pointed to it. The step is done when the decommission record is signed by the platform owner and the Cloud instance no longer serves any users.
Why PostgreSQL is the target application database for this migration
PostgreSQL is the right target for the application database because Metabase recommends it for production, and the load-from-h2 step writes your Cloud content into whichever database you prepare. The application database holds your questions, dashboards, people, groups and settings, so the engine you choose becomes a long-term operating dependency. MySQL 8.4.0 or MariaDB 10.6.0 and later, both with utf8mb4, are also supported by Metabase. Choose one engine before the migration rehearsal starts, because the load command targets an empty database, and changing engines later means repeating the load. Confirm the supported engine versions against Metabase's application database documentation before you provision anything.
PostgreSQL is released under the PostgreSQL License, a liberal open source license similar to the BSD and MIT licenses. Ask legal or procurement to confirm that this license terms are acceptable for your internal deployment, since your obligations depend on how you distribute software, not on the database itself. On versions, the PostgreSQL versioning policy lists 18 (final release November 14, 2030), 17 (to November 8, 2029), 16 (to November 9, 2028), 15 (to November 11, 2027) and 14 (to November 12, 2026). Versions 13 and earlier are unsupported. Pick the newest major version your Metabase release supports, and check its end-of-support date against the years you expect to run the instance. Minor releases never change the internal storage format, so applying them means replacing executables and restarting the server.
Running the database in your own infrastructure means your team owns its resilience. Set up backups and continuous archiving so you can perform point-in-time recovery, and test a restore into a separate environment before cutover, not after. Connection pooling with PgBouncer is worth evaluating if several Metabase nodes or other tools connect to the same database, because it limits the number of direct server connections. For high availability, PostgreSQL supports hot standby servers, along with synchronous and asynchronous replication, but it does not include software that detects a primary failure and promotes a standby. Decide whether you will use an external failover tool or a documented manual failover runbook, and assign who makes that call. Metabase upgrades also back up this database first, so these backups serve both purposes.
Before the migration, your database administrator should confirm three decisions with your team. First, choose the PostgreSQL major version and the replication topology, and write down who owns failover. Second, confirm the authentication method for the Metabase database user, keeping in mind that PostgreSQL 18 deprecated MD5 password authentication in favor of SCRAM. Third, ask Metabase's success team for the application database snapshot early, because customers cannot generate it themselves and the request sets the timing of your cutover. Metabase's guidance requires the load-from-h2 command to run with the same Metabase major version as the Cloud instance, so confirm the version pairing in writing with your team before the load starts.
What a Metabase Cloud migration costs and how long it takes
This table compares the cost and effort drivers for moving a Metabase Cloud instance onto infrastructure you control. Read each row for who is paid for the work, whether the cost is one-time or recurring, and what to request in a written quote. The written scope sets the actual figures, and the only prices shown are Metabase's published plan prices.
| Driver | Who is paid for the work | One-time or recurring | What to request in a quote |
|---|---|---|---|
| Metabase success team snapshot | Metabase, outside DeployOpen's control | One-time | Ask Metabase to confirm the request steps and turnaround before scheduling the build |
| Data source connections | DeployOpen for reconnection and testing; your team for credentials and network access | One-time setup, recurring access reviews | Connection count, database types, network paths and which sources need new credentials |
| SSO and identity provider | DeployOpen for configuration; your team for identity provider admin access | One-time build, recurring identity provider maintenance | Protocol (SAML, OIDC or LDAP) and confirmation that it needs Pro or Enterprise |
| PostgreSQL build and high availability | DeployOpen for build and testing; your team or cloud provider for hosting | One-time build, recurring hosting, backups and upgrades | Node count, backup and point-in-time recovery scope, and the failover tool, since PostgreSQL does not detect primary failure itself |
| Parallel run length | Your team for staff time; DeployOpen for validation support | Recurring until cutover | Parallel run period, exit criteria and the sign-off owner written into the scope |
| Users and groups | Metabase for licensing; DeployOpen for group and permission mapping | Recurring seat cost above included users | User count, group structure, and seats needed beyond the 10 included on Pro |
| Embedded content | DeployOpen for embedding setup; your team for application changes | One-time build, recurring application maintenance | Embedding method and whether SSO-based embedding, which requires Pro or Enterprise, is needed |
| License decisions | Metabase for the subscription; your organization for the plan choice | Recurring subscription | Pro is $575 per month or $517.50 billed yearly on Metabase's pricing page; confirm current terms with Metabase |
| Upgrades and backups after cutover | DeployOpen under a retainer if chosen; your team for infrastructure | Recurring | Upgrade and backup responsibilities, release cadence, and support hours in the written scope |
What usually goes wrong when moving off Metabase Cloud
Migrations that stall usually trace back to a few early decisions: which snapshot version gets loaded, which plan carries the license, and which network paths the new instance can reach. Each card below names one failure, why it hurts, and the check that prevents it. Review them before you request the snapshot so the success team and your staging environment are ready when the file arrives.
Loading the snapshot with a mismatched version
The Cloud snapshot is an H2 file that must be loaded with the Metabase version that last updated it, using a JAR of the matching major version. A mismatch can block the load or leave restored content in a state you did not plan for. Before you move the file, ask the success team to confirm the exact version of the snapshot, then pin the same build in your staging environment. Record that version in the migration runbook so the production load uses an identical JAR.
Starting a fresh instance instead of loading the snapshot
A new self-hosted Metabase creates an empty application database on first start, and it is easy to finish the setup wizard and begin building content before the snapshot arrives. The result is a working instance with none of the Cloud questions, dashboards, people or settings. Run the load-from-h2 command against an empty PostgreSQL database before the first startup. Confirm the load by checking that known dashboards and collections appear, and keep the setup wizard closed until that check passes.
Cancelling Cloud before the license token is active
Cloud Pro customers must cancel Cloud Pro and buy a self-hosted Pro plan with a license token. Cancelling Cloud before the token activates can leave users without a working instance and remove the fallback you need during the parallel run. Confirm that the token is issued and activates on your staging instance, then keep Cloud running until the cutover is verified and the rollback window has closed. Ask the vendor to confirm the Cloud cancellation date and what happens to your data afterward.
Missing data source network paths and credentials
Questions and dashboards query the databases behind them, so the self-hosted instance needs routes, firewall rules and credentials for every data source it reads. Allowlists that permitted Cloud's connections will not automatically permit the new host. Inventory each connection and record the host, port, network segment and service account. Test a query from the self-hosted instance before cutover, and handle credentials carefully, keeping secrets out of shared migration notes.
SSO features the chosen plan does not include
SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included only in Pro and Enterprise. Teams that used SAML, OIDC or JWT sign-in on Cloud may find that a self-hosted plan without those features cannot run the same flows. Advanced LDAP group sync and SCIM provisioning also require Pro or Enterprise. List every identity and permission feature your users depend on, then confirm each one against the plan you intend to buy before purchase.
Unplanned upgrades during the parallel run
Running Cloud and the self-hosted instance side by side invites drift, and a self-hosted upgrade runs application database migrations automatically. Freeze the self-hosted version for the parallel run and treat any upgrade as a separate, planned change. Before upgrading, back up the application database, reduce a cluster to one node for major upgrades, and upgrade release by release from versions older than 40. Rollback means restoring that backup, so verify the backup before you start.
Questions buyers ask before hiring help with a Metabase Cloud migration
How much does a Metabase Cloud to self-hosted migration cost?
Cost comes from three places: the Metabase license after the move, the infrastructure you run it on, and the implementation work, which is quoted from a written scope. The Metabase pricing page lists Pro at $575 per month, or $517.50 per month billed yearly, with the first 10 users included and additional users at $12 per month. Cloud Pro must be cancelled and a self-hosted Pro plan bought with a license token, so confirm with Metabase whether the self-hosted rate matches the Cloud rate. Implementation cost depends on the number of instances, the number of data sources, PostgreSQL hosting, SSO setup and how much verification your content needs. Ask for a quote that separates one-time work from recurring costs such as licensing, hosting, backups and upgrades, and that states what is excluded.
How long does it take to move Metabase Cloud to self-hosted?
No duration is fixed in advance, and the answer depends on the factors your written scope should state. The critical path starts with the application database snapshot, which only Metabase's success team can provide, so ask Metabase for its current turnaround before you set a cutover date. After the snapshot arrives, the work covers standing up PostgreSQL, matching the Metabase version to the Cloud instance, running load-from-h2, verifying questions, dashboards, people and settings, reconnecting data sources, and switching the license. Instances with many users, many data sources or SSO configuration usually need more verification time. Request a scope and timeline in writing before any work starts, and plan the snapshot request as the first task.
Can our own team migrate Metabase Cloud without a partner?
Yes, an internal team can do it alone if it has the skills, access and a test environment. The steps are operational: provisioning PostgreSQL, running a Metabase JAR of the same major version as the Cloud instance, executing the one-time load-from-h2 command, configuring the server, and checking the result. The risks sit in the details, including a version mismatch, an incomplete snapshot, network paths to data sources that were never opened, and gaps in verification. A partner is worth considering when the team has little PostgreSQL or Java operations experience, has no staging instance, or needs SSO and hardening completed in the same window. Whichever route you take, the written scope should name an owner for each step and the person who signs off the cutover.
Can we generate the Metabase Cloud application database snapshot ourselves?
No. Customers cannot generate the application database snapshot themselves, so you must ask Metabase's success team to provide it. Make that request early, because the rest of the migration depends on it. The snapshot is an H2 file with a .mv.db extension, and it is loaded into an empty self-hosted application database with the load-from-h2 command. Ask Metabase which version produced the snapshot so you can run a Metabase JAR of the same major version. Record the request date, delivery date and a file checksum in your change record so the cutover team can trace exactly what was loaded. If your security team has handling rules for database files in transit, raise them with Metabase before you submit the request.
Do saved questions and dashboards survive a move from Metabase Cloud?
Yes. Migrating from Metabase Cloud to self-hosted keeps questions, dashboards, people and settings, because they live in the application database that is loaded from the snapshot. Users sign in to the same objects after cutover. Verify this in your own environment anyway. Compare counts of questions, dashboards, collections, users and groups before and after the load, and open a sample of dashboards for each data source. Confirm in the written scope how other content, such as scheduled deliveries, alerts and custom application settings, is handled, since you should not assume every feature is covered by the same description. Test that group membership and permissions match what your access review expects before you invite users to the new instance.
Which Metabase plan is needed for SSO after moving to self-hosted?
SSO requires a Pro or Enterprise plan. According to Metabase's pricing page, SSO is included in Pro and Enterprise only, and Open Source and Starter do not include it. Within those plans, JWT, OIDC and SAML are supported, with documented setups for Auth0, Entra ID, Google, Keycloak and Okta. Advanced LDAP group and attribute sync and SCIM provisioning also require Pro or Enterprise. Open Source and Starter support Google sign-in and LDAP. If you move to a self-hosted Pro plan during the migration, treat the identity provider configuration as a separate step with a test group of users. Confirm your chosen identity provider path with Metabase before cutover, and confirm the plan requirement for the exact features you need.
What happens to our database connections when Metabase leaves Cloud?
Your data sources stay where they are, and the self-hosted Metabase connects to them from its new location. The databases and warehouses themselves do not move, but the connection settings and stored credentials must work from the new host. Confirm in the written scope how connection details are carried across and how stored credentials are protected on the new instance. The new host must reach each source over the network, which often requires firewall rules, DNS entries, TLS trust and allowlist changes. Plan a connection test for each source, including any sync or scheduled scan that depends on it. Involve the owners of each data source, because a changed host or credential can affect many saved questions at once.
What does rollback look like if a Metabase migration fails?
Rollback depends on when you decide to stop. Until users move to the new instance, the Cloud instance remains the working system, so the simplest rollback is to keep users on it. After cutover, take a backup of the new PostgreSQL application database immediately after the load, so you have a known state to return to. Metabase's documented rollback for upgrades is to restore a pre-upgrade application database backup, which is the recommended method, or to run the migrate down command with the newer JAR. Keep the H2 snapshot and the PostgreSQL backup for an agreed retention period. Write the rollback criteria, the decision owner and the steps into the written scope before cutover, and rehearse them in a staging instance first.
How DeployOpen scopes, delivers and supports the migration
DeployOpen plans and runs this migration inside your own infrastructure, from the request for the Metabase Cloud application database snapshot through to a working self-hosted instance. Each engagement is fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. Ongoing support is available as a retainer once the instance is live.
How we scope
- The written scope names the Metabase Cloud instance, the target hosting environment and the PostgreSQL version to run.
- Scope covers the snapshot request to Metabase's success team, which customers cannot generate themselves.
- Licensing is scoped separately: moving from Cloud Pro to a self-hosted Pro plan needs a license token.
How we build
- We load the H2 snapshot into an empty PostgreSQL application database using the load-from-h2 command.
- The Metabase JAR must match the Cloud major version and the version that last updated the H2 file.
- Testing covers a rehearsal load, then comparison of questions, dashboards, people and settings against the Cloud instance.
How we hand over
- Handover documents the snapshot request, load steps, versions used and the PostgreSQL connection and backup settings.
- Your team receives a runbook for application database backups before any upgrade, following Metabase's upgrade guidance.
- Access, admin roles and plan settings are reviewed with the owners before the Cloud instance is retired.
How we support
- Ongoing support covers upgrades, backups and PostgreSQL maintenance, available as a retainer after go-live.
- Upgrades follow Metabase's version support dates, with release-by-release steps and rollback by restoring the pre-upgrade backup.
- PostgreSQL patching and major upgrade planning are scoped separately, since minor releases never change the storage format.
