Migrate from Tableau to Metabase: what the move involves
A Metabase migration suits a Tableau estate where most users view and filter dashboards and a small group builds content. The effort depends mainly on how much calculated logic lives inside Tableau workbooks and how much row-level security must be rebuilt, so the first task is to inventory those two things before anyone estimates the work. Teams facing a renewal or a licensing change usually have a Tableau Server or Tableau Cloud estate with many Viewer and Explorer users and a handful of Creators, which is the profile Metabase handles most naturally. In most cases an internal BI or platform team owns the migration and brings in an implementation partner for the parts it lacks time or specialist skills for. Exporting workbooks through the Tableau REST API gives the team a .twb or .twbx inventory to work from, but the workbook files do not convert automatically into Metabase questions and dashboards. Each data source must be reconnected in Metabase, and each calculated field must be rewritten as SQL, a saved question or a model. Ask the partner to quote per workbook or per dashboard family, and ask what share of the work is inventory and what share is rebuilding.
The open-source edition of Metabase, which is free and self-hosted, does not include SSO or row and column level permissions. If your Tableau estate relies on per-user data restrictions or a corporate identity provider, confirm which of these you need before you choose a plan. Those features sit in the Pro and Enterprise plans on Metabase's pricing page, so the licensing decision is part of the migration scope, not an afterthought. Confirm current plan contents directly with Metabase, because plan details change. Run the Tableau and Metabase estates in parallel for a defined pilot group, compare results for key dashboards, and only then retire Tableau access. Keep the cost of a paid Metabase plan, the infrastructure and backups for the application database, and internal staff time in the same budget, and ask any partner to show each of these as a separate line.
Which Tableau content maps cleanly to Metabase
This table maps each part of a Tableau estate to its closest Metabase equivalent and marks it as clean, needs rework or gap. Read it by row: most view-and-filter content moves cleanly, while calculated logic, extracts and sign-in need planning. The main takeaway is that SSO and row and column level permissions sit in the Pro and Enterprise plans, not the open-source edition.
| Tableau content | Metabase equivalent | Status | What to check |
|---|---|---|---|
| Workbooks and dashboards | Dashboards built from saved questions | Needs rework | Dashboards are rebuilt from questions, so layout and per-sheet logic must be re-created, not imported. |
| Data sources and connections | Database connections and models | Clean | Confirm each source has a supported Metabase driver and that the service account can read the required schemas. |
| Calculated fields | Custom expressions or SQL questions | Needs rework | Simple arithmetic maps to custom expressions. Table calculations and LOD-style logic usually need SQL in a model. |
| Filters and quick filters | Dashboard filters linked to questions | Clean | Confirm each filter maps to a column in every card it should affect. |
| Parameters | Variables in SQL questions or dashboard filters | Needs rework | Parameters that change measures or dimensions need an explicit design in SQL or a model. |
| Extracts (.hyper) | Live queries against the warehouse or database | Gap | Metabase queries the source directly. Plan for database load and caching, and export extract data before retiring Tableau. |
| Permissions and groups | Collections and permission groups | Needs rework | Map Creator, Explorer and Viewer intent to Metabase groups. Access to data sources is set per group. |
| Row and column level permissions | Sandboxing in Pro or Enterprise | Gap | The open-source edition does not include these. Confirm the required plan before migrating restricted data. |
| Sign-in and SSO | Email, Google or LDAP sign-in in open source, SAML or OIDC in Pro or Enterprise | Gap | SAML and OIDC setups are plan-dependent. Confirm your identity provider integration before cutover. |
Which exports and integrations to move
A Tableau to Metabase move is mostly a set of hand-offs: what you can export from Tableau, which databases Metabase must reach, where its own metadata lives, and which delivery paths must be rebuilt. Each card below covers one of those hand-offs and the check to run before cutover.
Tableau workbook export via REST API
The REST API Download Workbook method returns each workbook as a .twb (XML) or .twbx packaged file, which is the documented bulk export path. A .twb shows the sheets, calculated fields, joins and filters you need to rebuild as Metabase questions and dashboards, but it does not carry the data. Check which workbooks are packaged as .twbx, confirm the API version your site supports, and inventory the sheets that depend on extracts.
Source databases behind each workbook
Metabase queries live databases directly, so every Tableau data source needs a matching Metabase database connection before any question can be rebuilt. Map each workbook to its underlying table or query and confirm the warehouse, driver and credentials Metabase will use. Extract-based workbooks need a decision: point Metabase at the source system, or land the extracted data in a database that Metabase can read.
Metabase application database
Metabase stores its questions, dashboards, users and settings in an application database. The embedded H2 database suits demos only, and Metabase recommends PostgreSQL for production, with MySQL 8.4.0 or MariaDB 10.6.0 and later also supported. If a test instance used H2, Metabase documents a one-time load-from-h2 command, which must run with the same Metabase version that last wrote the H2 file.
Users, groups and permissions
Tableau site users, groups and project permissions do not transfer automatically, and Tableau's Creator, Explorer and Viewer roles have no one-to-one Metabase equivalent. Export the user and group lists, then decide which groups map to Metabase groups and which access rules need row or column permissions. Confirm which sign-in methods your plan supports, since SSO and advanced group sync are not part of the open source edition.
Subscriptions, alerts and embedded views
Tableau subscriptions, data-driven alerts and embedded views on portals do not move with the workbook file. Each scheduled email, alert threshold and embedded dashboard must be listed and recreated by hand in Metabase, with the delivery channel and recipients confirmed. Embedding also depends on the plan you choose, so check the embedding model and identity design before promising customer-facing views.
Upgrade path for the Metabase instance
Once Metabase is in production, its upgrades run application database migrations automatically, so the migration plan should include a backup of the application database first. For major upgrades, the docs recommend reducing a cluster to a single node because of a migration lock, and upgrading release by release from versions older than 40. Choose between LTS and non-LTS releases based on how often your team can take upgrades.
Migration sequence from inventory to decommission
This sequence moves Tableau content to Metabase in controlled stages, so each group of users switches only after the numbers have been checked against Tableau. Each step closes with a named output that the next step depends on.
Inventory workbooks and usage by audience
Build a content register that lists every workbook, its data sources, its owner, its last-viewed date where your Tableau admin views expose it, and the audience that uses it. Tag each item by how people use it: viewed and filtered, or edited and extended by Creators. Export the workbook files in bulk through the Tableau REST API Download Workbook method while your licenses are still active, and confirm the .twb or .twbx files open. This step is done when the register is signed off by the business owners and the export archive is verified.
Map content to Metabase objects
For each register entry, decide whether it becomes a Metabase question, a dashboard, a model or a retired item. Record the data source it reads, the calculated fields that must be rewritten as SQL or Metabase custom expressions, and any Tableau-only features such as complex parameters or custom visualizations that need a different design. Confirm which users need SSO or row-level permissions, because those require a Pro or Enterprise plan. The output is a mapping sheet with a decision for every item and a list of gaps to resolve.
Stand up the Metabase application database
Install Metabase from the open-source Docker image or JAR and do not rely on the embedded H2 database for anything beyond a demo. Configure PostgreSQL or MySQL as the application database, following the Metabase documentation for supported versions and utf8mb4 for MySQL or MariaDB. Set up backups for the application database before any content is loaded. The check is a working instance that restarts cleanly and restores from a backup in a test copy.
Pilot a small set of dashboards
Choose a small group of dashboards that cover different data sources and calculation types, and rebuild them in Metabase with the same business owners reviewing them. Test filters, drill-downs, scheduled subscriptions and permissions for a few representative viewers. Record each gap in the register, including any feature that needs a paid plan. The pilot is complete when the owners accept the rebuilt content and the gap list has a decision for each item.
Run a parallel comparison
Keep Tableau and Metabase live on the same source data for the agreed dashboards. Compare totals, row counts, filter results and key ratios between the two tools for the same date ranges and user scopes, and log every difference with its cause, such as time zone handling, null treatment or extract refresh timing. Repeat the comparison after each source refresh until differences are explained. The output is a signed-off comparison record from the data owners and the report owners.
Cut over group by group
Move audiences to Metabase in groups, starting with the least sensitive, and make the Tableau version read-only for each group once its content is signed off. Communicate the new URLs and any retired reports to users, and keep a rollback path to Tableau for each group until its first full reporting cycle has passed. Confirm access through your identity provider or the Metabase user model for each group, and log who moved and when.
Archive and decommission Tableau
Once every group has cut over, store the final exported workbook files, data source definitions, the content register, the mapping sheet and the comparison records in an archive you control. Remove Tableau site content and users, then let the subscription or license terms end without renewal, according to your contract. Confirm with your vendor how license keys are released and how the archive should be retained. The closing output is an archived set of exported workbooks and a written record that Tableau access has been removed.
What drives migration cost and duration
This table lists the cost components of moving Tableau dashboards to Metabase and the factors that raise or lower each one. Read it as a checklist for a quote: the Metabase prices come from its published pricing page, while staff time and partner scope depend on your own estate.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it |
|---|---|---|---|
| Internal staff time for export and inventory | Your Tableau administrators and analysts | One-time | Number of workbooks, data sources and extracts, and how many owners must confirm their content moved correctly |
| Rebuilding calculated fields as Metabase questions | Your analysts, or a partner under a written scope | One-time | Workbooks with heavy calculated fields, table calculations and LOD expressions that must be rewritten in SQL or Metabase query builder |
| Row-level permission rules | Your security team and the implementation partner | One-time, plus review | Row-level security rules that must be recreated; these need Pro or Enterprise on the Metabase pricing page |
| Identity provider integration | Your identity team and the implementation partner | One-time, plus support | SSO through JWT, OIDC, SAML or advanced LDAP sync, which the Metabase pricing page places in Pro or Enterprise, and the number of IdPs in use |
| Metabase Starter or Pro subscription | Metabase, per the published pricing page | Recurring, monthly or yearly | Starter at $100 per month, or $90 per month billed yearly, includes 5 users; Pro at $575 per month, or $517.50 per month billed yearly, includes 10 users (Metabase pricing page) |
| Additional paid users | Metabase, per the published pricing page | Recurring, per user | Each extra user costs $6 per month on Starter or $12 per month on Pro (Metabase pricing page), so the count of users needing SSO or row-level features sets the plan |
| Enterprise plan | Metabase, by quote | Recurring, annual | Enterprise is priced by quote starting at $20,000 per year (Metabase pricing page); only needed for air-gapped deployment or other Enterprise-only needs |
| Hosting and application database | Your cloud or data center team | Recurring | Server sizing, backups of the PostgreSQL or MySQL application database, and whether you run a cluster for availability |
| Partner implementation scope | DeployOpen or another partner, under a written scope | One-time, plus optional retainer | Number of dashboards in scope, data source connections, testing and documentation depth; quotes follow from the written scope |
How the migration changes by starting point
This starting point fits a team where most people open dashboards, filter them and export results, while a handful of analysts build the content. Metabase Open Source is free to self-host with unlimited users and dashboards, so the main work is rebuilding the content you actually use rather than buying seats. Plan on a single Metabase instance backed by PostgreSQL, since the embedded H2 database is only suitable for demos.
- Inventory usage first: Identify which workbooks and views are opened weekly, and retire the rest instead of rebuilding them.
- Rebuild as saved questions: Recreate the common chart and filter logic as Metabase questions, then group them into dashboards with dashboard filters.
- Use Google sign-in or LDAP: Open Source and Starter support these, so you can avoid the Pro plan if your directory allows it.
- Set up the application database early: Point Metabase at PostgreSQL before loading content, so later upgrades run against a database you back up.
- Plan a single node upgrade path: Read the upgrading documentation before each release, since application database migrations run automatically.
Confirm with your team which Tableau views are truly used, and confirm that your identity setup works with the free sign-in options before you commit to Open Source.
This starting point fits an organization that needs SAML or OIDC sign-in, or that must limit which rows and columns each group sees. In Metabase these features require the Pro or Enterprise plan, and the open source edition does not include them. The work shifts from rebuilding content to choosing a plan, configuring identity and designing permissions before users arrive.
- Choose the plan by requirement: Pro includes SSO and row and column level permissions, while Enterprise adds air-gapped deployment and other capabilities listed on the pricing page.
- Map groups before import: Decide which Tableau site roles and project permissions correspond to Metabase groups, then configure SAML, OIDC or SCIM against your identity provider.
- Model row-level rules in the database: Confirm which access rules can be expressed as Metabase permissions and which need to live in database views.
- Price the seats: Pro starts with 10 users included, and additional users carry a per-user monthly charge, so count named users and not only licenses.
- Test the permission matrix: Verify each group against sample data before cutover, and keep the results as evidence.
Ask the Metabase sales team for a written quote covering Pro seats and support, and confirm that every SSO provider you use appears in the documented setups.
This starting point fits an estate where many Creator users build complex workbooks, calculated fields, parameter-driven views and extract-based dashboards every week. Metabase's question builder covers common analysis well, but it is not a like-for-like replacement for Tableau's visual authoring depth. Before committing, decide whether Metabase will serve the viewers while authors move to a different tool, or whether authoring needs remain on a platform built for it.
- Score each workbook: Mark workbooks by complexity, such as table calculations, custom level-of-detail logic and heavy parameter use, and count how many fall in each band.
- Move SQL-heavy logic to the warehouse: Calculations that can live in SQL views are easier to reuse in Metabase than calculations embedded in workbooks.
- Consider a second tool: Apache Superset is SQL-first and is a more natural target for authors who write complex queries, so review that option alongside Metabase.
- Keep Tableau for authors during transition: Plan a period where authors work in Tableau while viewers move, if your renewal timing allows it.
- Account for export limits: Power BI and Looker have download limits, and Tableau workbooks should be exported with the REST API before any subscription lapses.
Confirm with a sample of your heaviest authors whether the rebuilt content meets their needs before you retire any Creator licenses.
How the self-hosted Metabase stack is run after cutover
Once users are on Metabase, the work shifts to running it. The open-source edition ships as a JAR or as the metabase/metabase Docker image, and both connect to an application database that stores questions, dashboards, users and settings. Metabase ships with an embedded H2 database for demos, so the first production decision is to point it at PostgreSQL, which the documentation recommends for production, or MySQL or MariaDB if your standards require them. Confirm the supported versions for your chosen database against the current configuration docs before you build the environment, and plan how the application database will be backed up, restored and monitored by the same team that runs your other databases.
Version support determines how often you will upgrade. According to Metabase's version support page, LTS releases 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, and Metabase 65 followed on 12 October 2026. Choose an LTS line for production so that upgrades fit a planned change window rather than a monthly cycle. Schedule the calendar now, because the end-of-life date is the deadline that forces an upgrade.
Upgrades run application database migrations automatically at startup, so treat every upgrade as a database change. Back up the application database first, and for a major upgrade reduce a clustered deployment to a single node because of the migration lock. The upgrade docs recommend moving release by release when starting from a version older than 40. Rehearse the upgrade on a copy of production and record the version, the backup location and the rollback steps in your change record. Ask your team to confirm who approves upgrades, who watches the logs during the migration and how long a restore takes in your environment, since none of these are fixed by the product.
What usually goes wrong and how to prevent it
Most failed Tableau-to-Metabase moves fail on assumptions rather than on features. The risks below cluster around edition boundaries, data semantics, and timing, and each one is easier to prevent before cutover than to unwind after users have started relying on the new numbers.
Assuming row-level security in open source
Teams often assume that the restrictions they set in Tableau, where users see only their region or business unit, carry over to the free edition. Per Metabase's pricing page, row and column level permissions are included only in Pro and Enterprise, so the Open Source edition cannot enforce them. Before cutover, list every Tableau filter that acts as a security boundary and confirm which Metabase plan enforces it. If the plan is not funded, keep those dashboards off the shared instance.
Extract and live query mismatches
Tableau extracts are snapshots, while Metabase queries the database at view time. Totals can differ after a refresh, a timezone change or a late-arriving load, and users will read the difference as a migration error. Compare the same measure in both tools over a fixed date range, document the refresh schedule of the source tables, and agree a sign-off tolerance with the business owner before retiring the Tableau workbook.
Lost calculated logic
Tableau calculated fields, level-of-detail expressions and table calculations do not transfer as files. Some become SQL in a Metabase question, others need a model or a saved question as a base, and a few have no direct equivalent. Inventory each calculation from the exported workbook XML, rebuild it in SQL or as a model, and test it against values from the original workbook.
SSO gaps for viewers
Viewers often sign in through the corporate identity provider, but SAML, OIDC and JWT are restricted to Pro or Enterprise, and Open Source and Starter support Google sign-in and LDAP only. Confirm which identity method your directory supports, and whether SCIM provisioning is needed to remove leavers. Without it, a shared login or a manually managed account list becomes the access control.
Upgrades that run migrations
Metabase applies application database migrations automatically when a newer version starts, and the docs advise backing up the application database first and reducing a cluster to a single node for major upgrades because of a migration lock. Schedule upgrades against the published support windows, rehearse them on a copy, and record the version in use so that the parallel run and the cutover test are on the same release.
Renewal dates passing before cutover
Tableau term licenses stop working when the subscription expires, so a renewal date that arrives before the parallel run leaves users without their dashboards. Export workbooks and data sources through the REST API while licenses are active, and set the Metabase cutover target a safe margin ahead of the renewal. Ask Tableau for a short renewal term if the timeline is at risk, and confirm the exact terms in writing.
Questions buyers ask before a Tableau to Metabase move
How much effort and cost should we expect for a Tableau to Metabase move?
Expect cost to follow the components of the work, not a single license line. Tableau's side is term licensing by role: Creator is the only role that includes Tableau Desktop, so the workbooks you still author decide how many Creator seats you pay for during the overlap. Metabase's side is either the free Open Source edition (self-hosted, unlimited users and dashboards) or a paid plan. The larger one-time costs are usually infrastructure setup, rebuilding dashboards as Metabase questions and dashboards, and access design, while recurring costs are hosting, backups, upgrades and support. Ask any vendor or partner for a quote that separates these lines and states which Metabase edition it assumes. Pricing figures for Metabase plans are on the Metabase pricing page.
How long does a Tableau to Metabase migration take?
The duration is set mainly by how many dashboards you have, how many of them rely on calculated fields or custom SQL, and how many data sources sit behind them. We do not have a supplied timeline to quote, so treat any number you see as something to verify against your own inventory. Start by counting workbooks, data sources and users who only view and filter, since those are the easiest to move. Work that needs a parallel run, identity integration or a Metabase upgrade plan will add time. A fixed-scope written plan is the right place to agree duration before work begins.
What does our team need to supply for the move?
Plan on supplying the people who know the business meaning of each dashboard, the database owners who grant read access to the warehouse or source systems, and someone who can approve the hosting target and network path. On the Tableau side, you need administrator access to export content through the REST API, including the Download Workbook method that returns .twb or .twbx files. On the Metabase side, decide the application database (PostgreSQL is recommended for production) and who owns upgrades. Confirm these details in your own environment before the scope is written.
Can we migrate from Tableau to Metabase ourselves?
Yes, a capable internal team can move a small set of view-and-filter dashboards, provided they can read SQL, administer a Linux host and a database, and maintain the application database. The Metabase code is open source under AGPL for the Open Source edition, so the software itself carries no license purchase. Harder parts tend to be Tableau calculations that have no direct equivalent, identity integration and parallel running. If those are significant, or if the team lacks capacity for upgrades and backups after go-live, a fixed-scope engagement from DeployOpen can cover planning, implementation, hardening and documentation inside your infrastructure. DeployOpen does not issue audit reports or certifications.
When do we need a paid Metabase plan?
You need a paid plan when you require features that the free Open Source edition does not include. According to the Metabase pricing page, SSO, row and column level permissions, multi-tenant data segregation and usage analytics and auditing are included only in Pro and Enterprise, not in Open Source or Starter. Starter supports Google sign-in and LDAP, but SAML, OIDC, JWT, SCIM and advanced LDAP group sync require Pro or Enterprise. Enterprise is quoted by sales starting at $20,000 per year, and it is the only plan that offers air-gapped deployment. Starter is listed at $100 per month, or $90 per month billed yearly, with the first 5 users included, and Pro at $575 per month, or $517.50 per month billed yearly, with the first 10 users included.
Do Tableau extracts carry over into Metabase?
Usually not as Tableau extracts. Metabase does not read Tableau's Hyper extracts, so the data behind each dashboard has to be connected to Metabase as a database or view directly. The REST API can download workbooks as .twb or .twbx files, and a .twbx packages the extract, which helps you inventory what data was embedded, but the logic must be rebuilt. Plan to point Metabase at the warehouse or source system that feeds each extract, and confirm refresh behavior and data freshness with the owners of those systems. Also check whether any extract was built from a source you no longer want exposed to Metabase.
What happens to access control and row-level permissions?
Access control does not carry over automatically, and the free Open Source edition does not provide row-level permissions or SSO. Tableau's per-role licensing (Display, Viewer, Explorer and Creator) and its project permissions have to be mapped to Metabase groups and data permissions by hand. If you need row-level restrictions, you will need a Metabase plan that includes row and column level permissions, which the pricing page lists under Pro and Enterprise. Before cutover, have your security and compliance owners review who can see which data, and confirm the design in writing. DeployOpen prepares controls and evidence for assessments, but independent auditors issue any formal attestation.
How DeployOpen scopes and runs a Tableau to Metabase migration
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted Metabase inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. The work is usually scoped as a fixed engagement, and the scope, deliverables and timeline are agreed in writing before any work starts. For a Tableau move, the written scope should name the workbooks and dashboards in the migration set, the data sources Metabase must reach, the Metabase edition (Open Source, Starter or Pro), the identity provider in use, the user groups that will carry over, and the cutover criteria. A scope that leaves these open tends to produce a quote that is either too low or too vague to compare.
The decisions that shape the scope are mostly made before any installation. Confirm whether single sign-on, row and column level permissions or usage auditing are required, because the Metabase pricing page places them in the Pro and Enterprise plans, and confirm whether the application database will be PostgreSQL or MySQL rather than the embedded H2 database used for demos. Each choice changes the implementation work, the hardening baseline and the recurring plan cost, so the written scope should record them as explicit assumptions. DeployOpen does not publish a price list. A quote follows from the written scope, and the cost components to ask about are the one-time implementation and migration effort, the infrastructure you run, and any Metabase plan fees or retainer that recurs after go-live.
After go-live, most of the cost and risk sits in upgrades. Metabase applies application database migrations automatically, so the runbook should include a backup of the application database, a single-node reduction for major upgrades, and a release-by-release path from older versions. Ongoing support, upgrades and continuous testing are available as retainers, which suit teams that do not want to maintain Metabase upgrades in-house. Ask any provider to show the upgrade runbook, the backup and restore test, and the hardening baseline as deliverables, and confirm with Metabase which version lifecycle your chosen release follows on its version support page before you commit to a support window.
