Migrate from ThoughtSpot to Metabase

How a ThoughtSpot to Metabase migration starts and what it asks of your team

A migration from ThoughtSpot to Metabase is a rebuild of semantic models and dashboards, not a file conversion. Metabase does not import ThoughtSpot Models, Liveboards or Answers, so the first task is to inventory what business users actually rely on, then recreate the meaning of each model, join and metric in Metabase. A business analytics lead should expect the project to start with a list of the ad hoc questions people ask in ThoughtSpot search, the Liveboards they open each week, and the owners who will confirm that the rebuilt answers match. Export the ThoughtSpot content as TML first so the specification for each model and Liveboard is written down before anyone starts building. BI engineers usually do most of the rebuild: they recreate models as Metabase models and metrics, connect the data sources, and build dashboards with the query builder for self-service questions. Data owners must confirm definitions such as revenue, active customer or period boundaries, because a rebuilt metric that disagrees with the ThoughtSpot figure will undermine trust quickly. Security and identity staff need to decide early how users will sign in and which data each group may see. Metabase's open source edition is free to self-host with unlimited users and dashboards, but SSO (SAML, OIDC, JWT or SCIM provisioning) and row and column level permissions require the Pro or Enterprise plan. Confirm those requirements against your own policy before choosing a plan, and ask Metabase for current pricing, since the quoted figures are subject to change.

The effort and risk depend mostly on how many Liveboards and models are in active use, how many of them depend on search-style questions, and how strict your access rules are. Users who type free-text questions into ThoughtSpot will need to learn the query builder, so plan training and a period when both tools run side by side. Running Metabase yourself also adds an application database to back up and upgrade. Metabase recommends PostgreSQL for production and documents a one-time load-from-h2 step if you start on the embedded H2 database, so decide on the database before go-live. Ask any implementation partner for a written scope that lists each model, dashboard and permission group to be rebuilt, the sign-in method, the plan required, and the acceptance checks each owner will sign off.

Which ThoughtSpot capabilities move cleanly to Metabase and which need rework

This table maps the ThoughtSpot capabilities that business users rely on to their Metabase equivalents and marks each as clean, needs rework or gap. Read the status column first, then the notes, and confirm every plan requirement against Metabase's pricing page before you commit to a tier for SSO or data permissions.

Capability	Status	Metabase equivalent and notes
ThoughtSpot Models (joins, formulas, column names)	Needs rework	Rebuild as Metabase models and metrics. Joins and calculated columns must be re-expressed in the query builder or SQL, so document them from the TML export first.
Liveboards	Needs rework	Recreate as Metabase dashboards. Layout, filters and cross-filtering must be rebuilt by hand, and the dashboard count is not a migration blocker.
Answers and saved search questions	Clean	Saved questions in the Metabase query builder map closely for filtered, grouped and summarized views that users already ask.
Search-style natural language questions	Gap	Metabase does not offer ThoughtSpot-style search as a native equivalent. Users must learn the query builder, so set expectations and provide short training.
Embedding in other applications	Needs rework	Metabase embedding is documented, but the signed-embedding and SSO setup must be planned and tested. Confirm the plan that supports your embedding model on the pricing page.
Single sign-on	Needs rework	SSO such as SAML or OIDC requires Pro or Enterprise. Confirm the plan that includes SSO on the pricing page before you rely on it.
Row-level security	Needs rework	Row and column level permissions require Pro or Enterprise. Confirm the plan on the pricing page and map each ThoughtSpot security filter to a Metabase permission rule.
Scheduled delivery and alerts	Needs rework	Confirm current subscription and alert options in your Metabase edition. Recreate each ThoughtSpot schedule and check recipient lists during testing.

What data and definitions to export and what must be rebuilt by hand

The ThoughtSpot export gives you the specification, but the rebuild in Metabase is manual work. Each card covers one part of the move: the definitions you keep, the content you recreate, the database that holds it, the users who sign in and the systems that consume it. Settle the database and access first so dashboards are tested against the right people and data.

Export TML as the specification

Export your Models, Liveboards and Answers as TML files before the migration starts, and keep them as the written specification for the rebuild. The files document the joins, formulas and column definitions that business users depend on, so each Metabase model can be checked against a named source. Store the export in version control with a dated folder per environment, and ask your ThoughtSpot administrator which objects your release and permissions allow you to export.

Rebuild joins and formulas by hand

Treat each join, calculated column and aggregation in the TML files as work to recreate in Metabase, either as a model or as a metric for shared business definitions. Start with the few models that feed the most-used questions, then compare row counts and totals against ThoughtSpot for the same filters. Expect formula translation to take the longest, because search-generated logic often hides in saved answers. Confirm each definition with the person who owns the metric, and confirm with Metabase which parts of an export, if any, can be loaded directly.

Recreate Liveboards as dashboards

Liveboards become Metabase dashboards built from saved questions, and the questions business users ran through search become query builder questions they can run themselves. Record which Liveboards are opened most often before you start, so the first rebuild covers actual use rather than every object. Dashboard filters, drill paths and layout are not carried over automatically, so list each filter and drill behavior in your inventory and test it with a named user group before cutover.

Move the application database off H2

Metabase ships with an embedded H2 application database intended for demos, and it stores users, saved questions, dashboards and permissions. For production, Metabase recommends PostgreSQL, and it also supports MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4. Metabase documents a one-time load-from-h2 command, which must run with the same Metabase version that last updated the H2 file. Set up the target database before rebuilding any content, because every model and dashboard will live in it and needs a backup routine from the start.

Recreate users and groups for sign-in

Recreate user and group records so access matches your ThoughtSpot groups before anyone signs in to the new tool. Google sign-in and LDAP are available on the Open Source and Starter plans, while JWT, OIDC, SAML, advanced LDAP group sync and SCIM provisioning require Pro or Enterprise. Decide the identity source first, then map each ThoughtSpot group to a Metabase group. SSO and row and column level permissions are included only in Pro and Enterprise, so confirm which plan your access model needs before you design it.

Rebuild downstream integrations and embeds

Alerts, scheduled deliveries, embedded analytics and any system that reads ThoughtSpot content must be inventoried and rebuilt against Metabase. Identify every consumer, including portals, extracts and internal tools, before cutover, and record who owns each one. Metabase documents embedding, but the method you use depends on your edition and hosting. Confirm each embed and API consumer with its owning team and test it in a staging instance that uses the same database version as production.

The migration sequence from inventory to decommission

This sequence moves ThoughtSpot Models, Liveboards and users into Metabase in controlled stages, so each step produces an artifact the next one depends on. It ends with ThoughtSpot switched off only after business users have confirmed that Metabase answers their questions.

Inventory models, Liveboards and users
Start by listing every ThoughtSpot Model, Liveboard, saved Answer and scheduled alert, along with the users and groups that use each one. Export the objects as TML so the joins, formulas and column definitions are recorded in files you control, and note which Liveboards are used weekly versus rarely. The output is a spreadsheet that maps each business question to its source table, its owner and its target Metabase model or dashboard. The step is done when every object has an owner and a disposition: rebuild, merge, retire or keep in ThoughtSpot until cutover.
Stand up Metabase on PostgreSQL
Install the open-source Metabase edition in your environment and point its application database at PostgreSQL instead of the embedded H2 file, which Metabase provides for demos and does not recommend for production. If a test instance already runs on H2, Metabase documents a one-time load-from-h2 command that moves the data to PostgreSQL or MySQL, and it must be run with the same Metabase version that last updated the H2 file. Back up the application database before any upgrade, because Metabase runs its migrations automatically on upgrade. The output is a running instance with a verified backup and a documented restore procedure.
Pilot with a small group of business users
Choose a small group of business users who ask ad hoc questions in ThoughtSpot and rebuild only the models and metrics those users need, using Metabase models and the query builder. Decide early which people need SSO and row or column level permissions, because those features sit in the Pro and Enterprise plans, and confirm that choice against the current Metabase pricing page before the pilot begins. Observe how the pilot users ask questions, where the query builder is slower than search, and which saved questions they need. The output is a short list of accepted rebuilds, open gaps and the permission model the pilot has tested.
Run both tools in parallel
Keep ThoughtSpot and Metabase running side by side and give the pilot users a fixed set of business questions that both tools should answer. Record the results from each tool and compare them, including row counts, totals, filters and date ranges, to catch differences in joins and metric definitions before users rely on them. Log every question that Metabase cannot answer without help and classify it as a model fix, a training need or an accepted limitation. The output is a reconciliation log signed off by the business owner of each metric, with each mismatch closed or accepted in writing.
Extend rebuilds to remaining teams
Using the reconciled models and metrics from the pilot, rebuild the remaining Liveboards as Metabase dashboards and move the remaining users in waves, with SSO or group sync configured for each wave. Confirm that group membership maps to the intended collections and permissions, and that the embedded or scheduled content each team depends on has an equivalent in Metabase. Schedule the wave changes around month-end reporting so finance and operations teams are not moved during close. The output is a dashboard inventory where every item is marked as rebuilt, verified and assigned to a live group.
Cut over and freeze ThoughtSpot
Announce the cutover date to all users, point their bookmarks and links to Metabase, and set ThoughtSpot to read-only so no new content is created there. Keep the final TML export and the Metabase backups in a controlled archive, and record which ThoughtSpot content was intentionally left behind. Watch support requests for an agreed period and fix any broken dashboards or permission gaps. The output is a signed cutover record that names the date, the owner of each team and the open issues carried forward.
Decommission ThoughtSpot and keep the evidence
Once the support queue is quiet and the owners accept the result, cancel or stop the ThoughtSpot subscription or self-managed software according to your contract, and confirm the terms for data retention and export in writing with the vendor. Retain the TML exports, reconciliation log and the last Metabase backup for your records, and document the upgrade path for Metabase, including release-by-release upgrades and the backup step before each one. The output is a decommission record that shows what was retired, where the retained evidence is stored and who owns the Metabase upgrade calendar.

How the Metabase model layer replaces ThoughtSpot search

The core of this migration for business users is replacing ThoughtSpot's search bar with a governed starting point in Metabase. In Metabase, a model is a curated question that a data team defines once, usually joining and cleaning the tables that business users need, and a metric is a named calculation such as active customers or net revenue that everyone reuses. Non-technical users then open the query builder, pick a model, and filter, group and summarize it without writing SQL. This is the structure that replaces what ThoughtSpot Models and worksheet-style joins did for search, so the first task is to list which ThoughtSpot Models your business users actually query and rebuild those as Metabase models before anyone else's questions are migrated.

Set expectations early, because search-style questions do not carry over one for one. ThoughtSpot users often type a free-text phrase and get a chart back, and Metabase does not offer that natural-language step in the open source edition. Users will instead pick a model, choose columns and apply filters in the query builder. Run a short session with a few power users from each department, give them the rebuilt models and ask them to answer their last five real questions. Note where they need more clicks, and confirm with Metabase which features your chosen edition includes before promising anything beyond the query builder.

Decide which questions become saved questions and which go to the data team. A question that is asked repeatedly, uses an agreed metric and needs no new joins is a good candidate for a saved question that business users can rerun and filter. A question that needs new joins, a new definition of a metric or access to a table not yet in a model should be routed to the data team and, where it recurs, promoted into a model. Record the decision for each ThoughtSpot Answer in your export inventory, so the list of saved questions reflects agreed definitions instead of whatever users built informally in the old tool.

What drives the cost and duration of the move

This table lists the main drivers of cost and effort when moving ThoughtSpot Models and Liveboards to Metabase, with why each matters and how to keep it down. Use it to scope your own move and to frame the questions you put to a provider in a written quote.

Driver	Why it changes cost or effort	How to keep it down
Number of ThoughtSpot Models and Liveboards	Each Model must be rebuilt as a Metabase model with its joins and metrics, and each Liveboard as a dashboard. Counts drive build and review hours more than any other item.	Export TML first, retire unused Liveboards, and rebuild shared Models once before dashboards.
Users who need SSO and row-level permissions	SSO, row and column level permissions are included only in the Pro and Enterprise plans, so this group sets the plan tier and the identity work.	Separate users who need row-level rules from those who only need a shared dashboard, and limit row rules to sensitive data.
Metabase plan chosen	Open Source is free to self-host but lacks SSO and row-level permissions. Starter and Pro add support, and Enterprise is priced by quote starting at $20,000 per year (Metabase pricing page). Pro is listed at $575 per month, or $517.50 billed yearly.	Match the plan to the features you need, and request a written quote for your own user count and support terms.
Identity provider integration	Connecting SAML, OIDC, JWT or SCIM to Entra ID, Okta, Keycloak or Google needs configuration, group mapping and testing, and some options require Pro or Enterprise.	Confirm the identity provider and group model early, and reuse existing setups documented for your provider.
Database connections and data access	Each source needs a driver, network path and read credentials. Permission models often need redesign when ThoughtSpot security rules are translated.	Inventory data sources and map existing ThoughtSpot security filters to a short list of Metabase permission groups.
PostgreSQL application database operation	Metabase recommends PostgreSQL for production, so someone must run backups, patching, capacity and monitoring. The H2 to PostgreSQL load must use the same Metabase version that last wrote the H2 file.	Use a managed or standard PostgreSQL service in your environment, back up before every change, and document the load steps.
Upgrade cadence and version support	Non-LTS versions usually reach end of life after 2 months, while LTS versions are supported for 14 months (Metabase version support page). Migrations run automatically on upgrade, and major upgrades may need a single node.	Choose an LTS line for production, schedule upgrades, and keep a tested rollback plan with a database backup.
Testing and user acceptance	Business users compare results against ThoughtSpot answers. Metric definitions and filter behavior often differ, and that comparison is where most rework appears.	Agree a reference set of questions and expected figures, and test each rebuilt dashboard against them before cutover.

What usually goes wrong in a ThoughtSpot to Metabase migration

Most failed Metabase migrations come from a few predictable gaps: access rules that were never translated, identity features left on a plan that does not include them, and data definitions that drifted during the rebuild. Each card below names one of these risks, why it matters for business users moving off ThoughtSpot, and the check that prevents it.

Permissions that do not match ThoughtSpot

ThoughtSpot users often see only the rows and objects their Models and sharing settings allow, and those rules rarely map one to one onto Metabase groups. Before go-live, list every ThoughtSpot group and data restriction, then map each to a Metabase group and a data permission setting. Test with a sample account from each group and confirm that a user cannot see a table they could not open in ThoughtSpot. Row-level restrictions need the plan that includes them, so confirm that early.

SSO left on the open source edition

Teams often stand up the free Open Source edition for a pilot and forget that SSO is not part of it. Pro and Enterprise include SSO, while Open Source and Starter support Google sign-in and LDAP only. Confirm which identity protocol your identity provider uses, such as SAML or OIDC, and verify that the chosen plan supports it before users are onboarded. Otherwise shared local accounts become the de facto access model.

Users expecting search semantics

ThoughtSpot users are used to typing a natural-language phrase and getting a chart back. Metabase's query builder works differently: users pick tables, columns, filters and summaries, and the experience depends on how well models and metrics are named. Run short training sessions with real questions from the ThoughtSpot Answers history, and publish a glossary of which Metabase object answers each common question. Set expectations that some ad hoc questions will take more clicks.

Metric definitions drifting during the rebuild

When Liveboards are recreated by hand, a metric such as active customer or net revenue is often redefined slightly in each dashboard. The result is two numbers for one concept after cutover. Use the exported ThoughtSpot TML files as the specification, record each metric once as a Metabase metric on a governed model, and have finance or the data owner sign off the expected values for a fixed reporting period before retiring the old Liveboards.

Failed H2 application database migration

Metabase ships with an embedded H2 application database that is suitable for demos only. Moving it to PostgreSQL or MySQL uses a one-time load command that must run with the same Metabase version that last updated the H2 file. Teams that use a newer or older binary, or that skip verifying row counts afterward, find dashboards, users or permissions missing. Take a copy of the H2 file, run the load with the matching version, and check users, collections and questions before pointing users at the new instance.

Upgrades run without a backup

Metabase runs application database migrations automatically during upgrades, so a failed upgrade can leave the application database in a state that is hard to reverse. Back up the application database before every upgrade, and reduce a cluster to a single node for major upgrades because of the migration lock. If the installed version is older than 40, upgrade release by release. Check the version support page to pick an LTS line that matches your maintenance window.

How the move differs by size and starting point

A small team with a limited set of ThoughtSpot Models and no single sign-on requirement usually has the simplest path. The free Open Source edition of Metabase is self-hosted with unlimited users and dashboards, so the main decisions are about where it runs and who maintains it. The rebuild effort tends to follow the number of Liveboards and Models rather than the number of people who view them.

Plan for the application database: Metabase ships with an embedded H2 database for demos, but production should use PostgreSQL or MySQL. Confirm which database your team already operates.
Start with the query builder: Many questions that people ask in ThoughtSpot search can be answered with the Metabase query builder once a clean model exists.
Rebuild a short list first: Recreate the most-viewed Liveboards as dashboards and retire the rest after checking usage with the business owners.
Name one maintainer: Upgrades run database migrations automatically, so someone must own backups and version updates.
Confirm login options: Google sign-in and LDAP are available on the free tier, so check whether these meet your needs before considering a paid plan.

Before committing, confirm with your own users which Liveboards they open each week and who will own the Metabase instance after go-live.

Questions buyers ask before moving from ThoughtSpot to Metabase

How much effort does a ThoughtSpot to Metabase migration take?

The effort depends mostly on how many Liveboards, Models and Answers your business users rely on, how many data sources sit behind them, and how much of your ThoughtSpot logic lives in formulas, joins and row-level rules. Each Liveboard typically has to be rebuilt as a Metabase dashboard by hand, and each ThoughtSpot Model has to be recreated as a Metabase model with its metrics and filters. Plan for effort in four areas: inventory and prioritization, rebuilding content, rebuilding permissions, and user training. Ask any implementation partner for a fixed-scope estimate built from your own inventory, not from a generic per-dashboard figure. A written scope lets you compare options on the same content list.

What sets the timeline for moving off ThoughtSpot?

The timeline is set by the size of the content inventory, the number of teams that must sign off, and how many data sources must be connected and validated before dashboards can be trusted. Hosting work also adds time: standing up Metabase, moving its application database from H2 to PostgreSQL or MySQL, configuring single sign-on and testing backups. Most teams run old and new side by side for a period so that business users can compare results, which extends the schedule but reduces risk. Ask for a timeline with milestones tied to the inventory, and confirm which dependencies sit with your data owners.

Can our internal team migrate from ThoughtSpot without outside help?

Yes, a capable internal team can do this if it has someone who can administer Metabase, a database administrator for the application database, and analysts who know the business definitions behind the ThoughtSpot content. The harder parts are usually not the software: they are agreeing on metric definitions, rebuilding row-level access correctly, and keeping backups and upgrades on a schedule. Many organizations bring in outside help for the scoping, the security configuration and the first upgrade cycle, then run the platform themselves. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, under a written scope.

What do business users and data owners need to provide during the migration?

Business users need to name the questions they actually ask in ThoughtSpot, review rebuilt dashboards against their current numbers, and accept that some search-style habits will change. Data owners need to confirm metric definitions, approve which tables are authoritative, and sign off on access rules for each group. Ask them to document any ThoughtSpot Model logic that is not obvious from the export, such as custom formulas, joins and filters that hide rows. Without these inputs, rebuilt content tends to be technically correct but unused, so agree on owners and review dates before work starts.

Which Metabase plan do we need for SSO and row-level permissions?

Based on 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. Open Source and Starter support Google sign-in and LDAP. JWT, OIDC, SAML with documented setups for Auth0, Entra ID, Google, Keycloak and Okta, advanced LDAP group and attribute sync and SCIM provisioning require Pro or Enterprise. Confirm the current plan list with Metabase before you buy, because plan contents can change. Pro is listed at $575 per month, or $517.50 per month billed yearly, with the first 10 users included and $12 per additional user per month. Enterprise is priced by quote, starting at $20,000 per year.

What does the Metabase open source edition cost to run?

The Open Source edition has no license fee and allows unlimited users and dashboards when self-hosted. Your costs are the servers or containers, the PostgreSQL or MySQL application database, storage and backup, network and load balancing, and the staff time to upgrade and monitor. Support, SSO and row-level permissions are the main reasons teams choose a paid plan. Ask any implementer for a quote that separates one-time work (scoping, rebuilding content, configuring authentication, cutover) from recurring work (hosting, backups, upgrades, support). Compare those recurring costs with your current ThoughtSpot per-user or credit charges.

Are ThoughtSpot TML exports enough to rebuild our content in Metabase?

TML exports are a useful specification, but they are not a finished migration. They describe Models, Tables, Views, Answers and Liveboards, including joins, formulas and columns, which helps you document what exists and what must be rebuilt. They do not produce Metabase models, metrics, dashboards or permissions, so each object is recreated by hand in Metabase. Keep the TML files as the reference for the migration, record every formula and filter, and check rebuilt numbers against ThoughtSpot results before retiring a Liveboard. Confirm with your implementer which export formats and objects are covered in the scope.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For this migration we start from a written scope covering your ThoughtSpot content, your data sources and the Metabase deployment, then build and hand it over in your environment.

How we scope

Inventory the ThoughtSpot Liveboards, Answers and Models that business users rely on for ad hoc questions.
Agree in writing which Metabase models, metrics, dashboards and permission groups are in scope.
Confirm which Metabase edition covers SSO and row and column permissions, and which identity provider it connects to.

How we build

Deploy Metabase with PostgreSQL as the application database in your cloud account or data center.
Recreate priority Liveboards as Metabase dashboards and key definitions as models and metrics.
Test query results against ThoughtSpot outputs for agreed questions before business users switch over.

How we hand over

Document the deployment, upgrade steps, backup routine and the database migration runbook for your team.
Provide a record mapping each ThoughtSpot object to its Metabase equivalent or to a noted gap.
Train named administrators and power users on the query builder, models and permission setup.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Request a quote based on the written scope, since DeployOpen does not publish a price list.