Migrate from Sisense to Metabase

Migrate from Sisense to Metabase for internal dashboards

If a Sisense renewal, a change in how you deploy it, or a data residency requirement has put your internal dashboards in question, Metabase suits internal dashboards that query the same databases you use today. The effort depends mainly on three things: the number of dashboards you need to rebuild, how many data security rules Sisense enforces through its ElastiCube and group setup, and how your identity provider is wired to the tool. Plan the work around those three, not around the chart types, which Metabase handles without much difficulty.

Internal platform or BI staff usually do most of the work, often with an implementation partner for the permission model and the identity setup. Your own people know which dashboards executives actually open and which ones nobody has touched in a year, so they should decide what gets rebuilt. A partner can help map Sisense groups to Metabase groups and collections, set up the application database, and run the upgrade process. Ask any partner to describe how they will handle row-level rules before agreeing to a scope.

The short answer on risk is moderate. It sits mostly in permissions and data definitions, not in the database connections. Confirm which of your Sisense security rules filter rows by user attribute, because Metabase only enforces row and column level permissions on the Pro or Enterprise plan, and SSO depends on the same tier. Check the Metabase pricing page against your user count and identity needs before you commit to a design, since a dashboard that looks correct in a test account can still expose data to the wrong group.

Which Sisense capabilities map cleanly to Metabase

This table compares the main Sisense capabilities that internal dashboard teams use with their Metabase counterparts. Read each row as clean, needs rework or gap, then confirm the specific widget types, scheduling and embedding options in the Metabase version you plan to deploy. The main takeaway is that the Metabase plan you buy decides whether SSO and row-level rules are available.

Sisense capability	Metabase equivalent	Status	What to confirm
Dashboards and widgets	Dashboards built from saved questions, with filters and cards	Needs rework	Rebuild each widget as a question; confirm the chart types you use exist in your version
Filters on dashboards	Dashboard filters linked to question fields	Needs rework	Map each Sisense filter to a field in the target table and test cross-filtering behavior
ElastiCube data models	Queries against the same databases, with models defined in the Metabase data model layer	Needs rework	Document every ElastiCube join and calculated field before rebuilding it as SQL or a Metabase model
Groups and data security rules	Groups for access to collections and data; row and column level permissions on Pro and Enterprise	Gap	Row-level rules require the Pro or Enterprise plan; the Open Source and Starter plans do not include them
Single sign-on	Google sign-in and LDAP on Open Source and Starter; JWT, OIDC, SAML and SCIM on Pro or Enterprise	Gap	Confirm your identity provider is covered by the plan you choose before you cut over users
Scheduled reports and sharing	Dashboard subscriptions and sharing links, with scope confirmed per version	Needs rework	Test subscription delivery and public or embedded link behavior in your own environment
Embedding	Embedding options that vary by Metabase plan	Needs rework	Confirm which embedding method your plan includes before planning host application changes
Application database	Metabase stores its own metadata; PostgreSQL is recommended for production	Clean	Plan a PostgreSQL or MySQL instance and back it up before upgrades

What data and identities move, and what must be rebuilt

Metabase does not import Sisense's data. It connects to the same databases Sisense queries, so the warehouse stays the source of truth and the work is in rebuilding the logic that sat inside Sisense. Any ElastiCube joins, calculated columns and aggregations need to be rewritten as SQL queries, saved questions, models or database views in the warehouse. Before you start, confirm with your Sisense administrators which data sources feed each ElastiCube, whether any of them hold extracted copies of data that no longer exist in a live source, and which transformations exist only inside the cube. Sisense's own export documentation is the place to confirm what a .dash export actually includes, since it may not contain the cube definitions or the data security rules you need.

Metabase also needs its own application database to store questions, dashboards, users and permissions. The embedded H2 database is suitable for demos only, so production instances should use PostgreSQL or MySQL 8.4.0 or MariaDB 10.6.0 and later with utf8mb4, as described in Metabase's application database documentation. If a test instance already holds content you want to keep, the documented load-from-h2 command moves the H2 file to PostgreSQL or MySQL, but it must be run with the same Metabase version that last updated that file. Plan a backup of the target database before the move.

Recreate group membership and data security rules deliberately rather than copying them blindly. Map Sisense groups to Metabase groups and decide which of them grant data access, since Metabase's permissions cover collections, data access and, on Pro and Enterprise plans, row and column level permissions. Sign-in is the other dependency: Open Source and Starter support Google sign-in and LDAP, while SAML, OIDC, JWT, advanced LDAP group sync and SCIM provisioning require Pro or Enterprise. Confirm with your identity team which protocol your provider supports and whether group sync must be automated, because that decision determines the plan you buy.

The migration sequence from inventory to decommission

The sequence moves Sisense content to Metabase in controlled stages, so each group of users is cut over only after its dashboards have matched the figures they already trust, and the Sisense environment is retired on a documented schedule.

Inventory dashboards, databases, groups and security rules
Your BI or data team lists every Sisense dashboard, the ElastiCubes or live connections behind it, the user groups that own or view it, and the data security rules that restrict rows or columns. Each item is tagged with an owner and a usage flag, so unused content can be retired rather than rebuilt. The step is done when the inventory is signed off by the business owners and every dashboard has a named target database in the new stack. Use the export guidance for Sisense to confirm what a .dash file does and does not carry, because sharing settings and custom actions usually need manual recording.
Stand up Metabase and run a pilot
Deploy Metabase with PostgreSQL as the application database, following the vendor's guidance on the application database and the H2 migration path if you test with the embedded database first. Your team rebuilds a small set of dashboards, typically those used by one group, against the same warehouse tables used in Sisense. The pilot also tests the permission model: group mappings, collection access and any row-level rules, which need a plan that includes them (see the pricing section). The pilot is complete when the pilot group signs off on layout, filters and refresh behavior.
Run Sisense and Metabase in parallel
For each rebuilt dashboard, both versions run against the same data over an agreed period, and an analyst compares key totals, filtered breakdowns and date ranges. Differences are traced to their cause, such as a join logic change in an ElastiCube, a time zone setting or a stale extract, before anyone accepts the new figure. The output is a comparison log per dashboard showing matched figures, documented variances and the person who approved each variance.
Cut over one group at a time
Users move group by group, starting with the pilot group and continuing with groups that depend on fewer shared dashboards. Before each cutover, the group's Metabase permissions are confirmed against the Sisense rules recorded in the inventory, and users are told which dashboard replaces which. The cutover is confirmed when the group's owners accept the new dashboards and no open issues remain in the log. Keep Sisense read access for the group until the next step so that users can still check a figure.
Back up and upgrade Metabase before go-live
Before the production cutover, back up the Metabase application database and record the Metabase version in use. Metabase runs application database migrations automatically on upgrade, and its documentation recommends reducing a cluster to a single node for major upgrades because of a migration lock, and upgrading release by release from versions older than 40. Schedule the upgrade to the supported version you choose from the version support page, and test the restore of the backup on a separate instance. The step is complete when the restore test succeeds and the upgrade notes are filed.
Decommission Sisense and retain its data per policy
When every group is cut over and the retention period agreed with your compliance owner has been confirmed, Sisense is set to read-only, its scheduled jobs and data connections are disabled, and the environment is shut down. Sisense data, including exported .dash files, ElastiCube backups and access logs, is kept or deleted according to the written retention policy and the records your regulators or auditors expect. The step is complete when a decommission record lists what was removed, what was archived, where it is stored and who approved it. Confirm the retention requirements with your legal and compliance teams before starting this step.

What drives cost and duration in this migration

This table lists the cost components of a Sisense to Metabase move and the drivers that push each one up or down. Read the driver rows first, then use the cost component rows to decide what to ask for in each quote. Metabase licensing is the smallest part of the picture for most internal deployments, while rebuild and validation effort usually carry the most weight.

Driver or component	Why it changes cost or effort	How to keep it down
Dashboard count and complexity	Each Sisense dashboard is rebuilt as Metabase questions and dashboards, so effort scales with widgets, custom calculations and drill paths.	Inventory dashboards first, retire unused ones and rebuild shared logic as reusable saved questions.
ElastiCube models and transformations	ElastiCube transformations must become warehouse tables, views or queries, which is often the largest unplanned task.	Move logic into the warehouse before the rebuild and confirm which cubes feed which dashboards.
Depth of data security rules	Row-level and group-based restrictions in Sisense must map to Metabase permissions, and row-level rules need the Pro or Enterprise plan.	Document each rule, collapse overlapping rules and test a small set of users before scaling.
Identity provider integration	SSO, SAML, SCIM and advanced LDAP group sync require Pro or Enterprise, so the plan choice depends on how users sign in.	Confirm your identity provider setup early and ask the vendor which plan covers your sign-in method.
Application database setup	Metabase ships with H2 for demos and recommends PostgreSQL for production, so a production database and backup routine are a setup cost.	Provision PostgreSQL with backups from the start and avoid migrating a demo H2 file into production.
Validation for parallel runs	Numbers must match Sisense output across a period of parallel use, which requires agreed metrics and stakeholder sign-off.	Pick a fixed set of key reports with agreed expected values and limit parallel runs to those.
Training and adoption	Business users move from Sisense navigation to Metabase's question and dashboard model, which needs guides and hands-on sessions.	Prepare short internal guides and run sessions by team rather than one large training event.
Metabase license tier (one-time setup and recurring)	Open Source is free. Starter is $100 per month or $90 per month billed yearly with the first 5 users included, Pro is $575 per month or $517.50 per month billed yearly with the first 10 users included, and additional users cost $6 (Starter) or $12 (Pro) per month. Enterprise is quoted from $20,000 per year. These figures come from Metabase's pricing page.	Choose the lowest plan that covers your sign-in and row-level needs, and confirm user counts and billing terms in writing.
Infrastructure (recurring)	Hosting the Metabase JAR or container, PostgreSQL, backups and network access. Cost depends on your cloud or data center rates, which vary by organization.	Size for your actual concurrency and reuse existing PostgreSQL and backup services where policy allows.
Implementation and staff time (one-time and ongoing)	Rebuilds, permission mapping, upgrades and support are paid through internal staff time or a fixed-scope implementation partner. Ask partners for a written scope and deliverables.	Agree scope and deliverables before work starts and keep upgrade planning on a recurring schedule.

What usually goes wrong and how to prevent it

Most failed Sisense to Metabase moves do not fail on the database connection. They fail on definitions that drift, access rules that were never mapped, and operating choices made after go-live. The cards below cover the risks we see most often and a concrete check for each.

Numbers that do not match

Sisense ElastiCubes often carry join logic, calculated columns and aggregation rules that never appear in the source warehouse. A Metabase question built directly on the same tables can return a different total for the same filter. Before cutover, pick five to ten key metrics, recompute each in the Metabase model and document every place where the two definitions differ. Agree the authoritative definition with the business owner, not with the person who built the dashboard.

Permissions drifting from Sisense groups

Sisense group membership and data security rules do not transfer on their own, so access can quietly widen or narrow after the rebuild. Map each Sisense group to a Metabase group and each data security rule to a collection or data permission before users are invited. Then run a sample of named users through both systems and compare what each can see. Review the mapping again whenever someone changes roles.

SSO needs an unbudgeted plan

Single sign-on, SAML and SCIM provisioning are not part of the Open Source or Starter plan, and Google sign-in and LDAP are the only directory options on those plans. If your identity provider is Okta, Entra ID or Keycloak, the Pro or Enterprise plan is required from the start. Confirm the plan, the pricing quote and the identity provider setup before the project schedule is fixed, because the cost is recurring and easy to miss.

Row-level rules missing on lower plans

Sisense data security rules that restrict rows by region, business unit or customer are often the reason a dashboard exists. Row and column level permissions are included only in the Pro and Enterprise plans, not in Open Source or Starter. If a deployment on a lower plan shows all rows to all users, data leaks to people who should never see it. Inventory every row-level rule before choosing the plan, and test each one with a restricted account after the rebuild.

Upgrades and migration lock

Metabase runs application database migrations automatically at startup, and the upgrade guide recommends backing up the application database first. For major upgrades, reduce a cluster to a single node because of a migration lock, and upgrade one release at a time from versions older than 40. Schedule these steps as a runbook with a tested restore, not as an ad hoc change. If you start on H2, plan the load-from-h2 move to PostgreSQL before any dashboards depend on the instance.

Low user adoption

Analysts who relied on Sisense dashboards will keep exporting spreadsheets if the Metabase versions are slower, harder to find or missing a filter they used daily. Name a small group of power users to rebuild the top dashboards with the business owners, and retire the Sisense versions on a fixed date. Track which dashboards are opened in each tool during the parallel period, and treat a dashboard with no views as a candidate to drop, not to copy.

How the migration differs by starting point

A small team with a handful of dashboards on one database is the simplest case. The work is mostly rebuilding charts and filters in Metabase against the same tables, which Metabase's question and dashboard builder handles directly. Little of the Sisense model needs to be carried over because the data is often already in a warehouse or a single PostgreSQL or MySQL database.

Connect directly: Add the existing database as a Metabase data source and rebuild each dashboard against the same tables rather than copying data.
Keep permissions simple: Map Sisense groups to a few Metabase groups and set collection permissions for each team.
Start on the Open Source edition: Self-hosting the free edition covers unlimited users and dashboards, so the first phase carries no license cost.
Plan the application database: Replace the embedded H2 database with PostgreSQL before anyone relies on the instance, using the documented load-from-h2 command.
Retire Sisense in one step: With few dashboards, a short parallel run and a dated cutover is usually enough.

Before starting, confirm the database driver and version that Metabase needs for your source, and whether any dashboard depends on a Sisense-only calculation.

Questions buyers ask before moving from Sisense to Metabase

What does a move from Sisense to Metabase cost?

The software cost depends on the Metabase plan, and the larger cost is usually the work. Metabase's Open Source edition is free to self-host with unlimited users and dashboards, while the Starter and Pro plans are published on the pricing page at $100 and $575 per month before the yearly discount. Enterprise is priced by quote starting at $20,000 per year. Your own cost includes infrastructure (a PostgreSQL application database, hosting for the Metabase container or JAR), the rebuild of dashboards, permission mapping, testing, and staff time for operations. Ask any implementation partner for a fixed-scope quote that lists the number of dashboards, data sources, and permission groups in scope, and separate one-time work from recurring hosting and support.

How long does a Sisense to Metabase migration take?

Duration depends on scope, mainly how many dashboards you rebuild, how many source databases sit behind them, and how complex the data security rules are. A small set of internal dashboards on one warehouse is a different project from dozens of dashboards across several databases with group-based row restrictions. Before agreeing a timeline, inventory your Sisense dashboards, ElastiCubes, and data security rules, then rebuild in phases, starting with the dashboards that people use most. DeployOpen agrees timelines in writing as part of a fixed-scope engagement, so ask for a schedule tied to that inventory rather than a general estimate.

What does the migration need from our internal team?

The work needs people who own four things: the source databases and their credentials, the business definitions behind each dashboard, the identity system that will sign users in, and the decision on who can see which rows. Expect the team to validate numbers, since a rebuilt chart must match the Sisense figure before users switch over. You will also need someone to provision the Metabase host, PostgreSQL, backups and network access. Confirm named owners for each of these areas at the start, because most delays come from waiting on approvals or definitions rather than from the tool itself.

Can our own team migrate Sisense to Metabase without a partner?

Yes, a capable internal team can rebuild dashboards in Metabase, since the tool is self-hosted and documented. The harder parts are usually permissions mapping, identity integration, and a reliable cut-over with tested numbers. Metabase's free Open Source edition covers the core dashboard work, but SSO and row and column level permissions require a paid plan, so the team must decide early whether that feature set is needed. A partner is useful when deadlines are tight, when many dashboards depend on row-level rules, or when the team lacks time for testing. Whichever path you take, document the decisions so the next upgrade does not depend on one person.

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

Row and column level permissions, SSO through JWT, OIDC or SAML, and SCIM provisioning all require the Pro or Enterprise plan. According to Metabase's pricing page, the Open Source and Starter plans do not include these features, though Google sign-in and LDAP work on both. Pro is listed at $575 per month or $517.50 per month billed yearly, with the first 10 users included. Enterprise is quoted starting at $20,000 per year and is the only plan that supports air-gapped deployment. Confirm the current plan contents on the pricing page before purchase, and check which identity provider you use, since Metabase documents specific setups for Auth0, Entra ID, Google, Keycloak and Okta.

Do Sisense dashboards export cleanly into Metabase?

Not fully. Sisense dashboards do not move as a direct import, so each dashboard is rebuilt in Metabase using the same underlying databases. The layout, chart types, filters, and sharing settings usually need manual reconstruction, and custom actions have no direct equivalent. Start with an inventory of what each dashboard does, which data it reads, and who sees it. Then rebuild against the same warehouse tables and compare results side by side before retiring the original. Ask any partner to show how they will validate totals, filters and row-level results for each rebuilt dashboard.

How are Metabase upgrades handled after go-live?

Metabase upgrades run database migrations automatically, so the process needs a planned change window. The documentation recommends backing up the application database first, reducing a cluster to a single node for major upgrades because of a migration lock, and upgrading release by release from versions older than 40. Metabase LTS versions are supported for 14 months, while non-LTS versions usually reach end of life after 2 months, so choose a release track that fits your change schedule. Metabase 64 is an LTS release published on 16 September 2026 with end of life on 1 December 2027. Ask for an upgrade runbook and a test environment as part of the scope, and confirm whether ongoing upgrades are covered by a retainer.

How a migration runs with DeployOpen

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted Metabase inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. The first output is an inventory of what Sisense actually does for your organization: which dashboards are in use and by whom, which ElastiCubes feed them, which source databases and warehouse tables they read, and which data security rules limit what each group sees. That inventory decides the rest of the work, so expect it to be the first written deliverable. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts, and the inventory and pilot outcomes are defined in that document rather than discovered along the way.

The pilot rebuilds a small set of representative dashboards in Metabase against the same databases, with the Metabase application database on PostgreSQL rather than the embedded H2 file. The pilot also tests the permission model: Sisense groups and security rules are mapped to Metabase groups, collections and data permissions, and row-level rules are checked against a plan that includes them. Confirm with Metabase which plan covers the SSO protocol and row-level permissions your identity provider requires, because those features sit in the paid tiers. Hardening, backup and upgrade procedures for the application database are documented as part of the handover so your team can run them. The pilot's written output should record which dashboards moved cleanly, which were rebuilt, and which Sisense features have no direct equivalent.

Ongoing support, upgrades and continuous testing are available as a retainer after handover, which suits teams that want Metabase version upgrades and security patches handled on a defined schedule. Ask for the retainer terms in writing, including who performs upgrades, how the application database is backed up before each one, and how new dashboards are reviewed against the permission model. Final cutover and decommissioning of Sisense are separate decisions that should follow a successful pilot and a checked inventory. Ask DeployOpen for a quote based on your written scope, since DeployOpen does not publish a price list.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Sisense to Metabase, we start with a written scope that covers the dashboards in use, the databases they read, and the access rules that must carry over.

How we scope

We inventory which Sisense dashboards are used internally and which databases and ElastiCubes they depend on.
We map Sisense groups and data security rules to Metabase groups, collections and permissions, then agree the mapping in writing.
We confirm which Metabase plan covers the required SSO, LDAP group sync and row-level rules before work starts.

How we build

We deploy Metabase on your infrastructure with PostgreSQL as the application database, following Metabase's production recommendation.
We rebuild priority dashboards against the same source databases and test filters, figures and permissions against Sisense output.
We configure SSO, group sync and row-level permissions, then test access for each role before any user is moved over.

How we hand over

You receive documentation of the deployment, the permission model, the Sisense-to-Metabase dashboard map and the open items.
We document the backup of the application database and the upgrade procedure, including backing up before each Metabase upgrade.
Handover includes a walkthrough with the team that will own dashboards, groups and the Metabase version after go-live.

How we support

Engagements are fixed-scope, so scope, deliverables and timelines are agreed in writing before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Quotes follow from the written scope. Ask us to show which items are one-time work and which would recur under a retainer.

Migrate from Sisense to Metabase