Migrate from Sisense to Apache Superset

Migrate from Sisense to Apache Superset: what the move involves

The move from Sisense to Apache Superset is a rebuild of dashboards and data logic, not a file conversion. A Sisense .dash export carries layouts and widget definitions, but the data model behind them lives in ElastiCubes, and the sharing rules, BloX custom actions and data security settings sit largely outside that file. If your renewal, pricing change, hosting requirement or residency concern is driving the decision, plan the work as a platform build plus a data and dashboard rebuild, with the export used as an inventory aid rather than as the migration itself. Usually an internal platform or BI team owns the program and brings in an implementation partner for the Superset deployment, the warehouse connections and the rebuild of the highest-value dashboards.

Superset is licensed under Apache-2.0 and the project has no paid edition, so the cost you are replacing is the Sisense subscription, while the cost you take on is platform, data and rebuild effort. Confirm with your own team how much of the effort sits in the platform (hosting, the metadata database, caching and workers, upgrades), how much in the data layer (replacing ElastiCube logic with warehouse tables, views or a query engine), and how much in rebuilding charts, filters and permissions. Those three components, not a license line, drive the timeline. Ask any partner for a written scope that names each dashboard, each data source and each permission group before work starts, because the effort is mostly determined by how many ElastiCube transformations need to be re-expressed in SQL.

The main risk is that the parts of Sisense you forget to inventory are the parts users notice first: sharing settings, scheduled reports, row-level data security and custom actions. Before committing dates, run a full inventory of dashboards, ElastiCubes and data security rules, then run a pilot with two or three representative dashboards in a staging Superset instance that uses a restored copy of your metadata database. Check the Superset upgrade documentation for the backup and staging practice you will need once the platform is live, and confirm with the release notes which version you will pin, since the current release line moves quickly.

Which Sisense capabilities map to Apache Superset, and what needs rework

This table compares the main Sisense capabilities with their Apache Superset equivalents and marks each as clean, needs rework or gap. A gap means Superset does not reproduce the feature, so confirm the specifics for your own dashboards, filters and sharing setup before you commit to a migration plan. The main takeaway is that dashboards, models and permissions must be rebuilt and tested one by one.

Sisense capability	Apache Superset equivalent	Status
Dashboards, charts and layout	Re-created in Superset's dashboard editor from exported definitions or by hand. Confirm chart types against your inventory.	Needs rework
Widgets and filters	Native filters must be rebuilt per dashboard. Confirm each Sisense filter type has a Superset equivalent.	Needs rework
ElastiCube models	No direct import. Model logic moves to SQL views, dbt models or a query engine such as Trino.	Gap
BloX custom actions	No direct equivalent. Plan for links, drill-through or a custom plugin, and confirm the behavior you need.	Gap
Sharing and permissions	Superset roles govern datasets, charts and dashboards. Owners and shares must be re-created by hand.	Needs rework
Data security rules	Row-level security is defined per dataset and assigned to roles. Map each Sisense rule and test it.	Needs rework
Scheduled reports and alerts	Needs the caching layer plus Celery worker and beat processes, usually Redis and Celery. Budget for the extra services.	Needs rework
Embedding	Superset offers an embedded SDK. Confirm the guest token flow and tenant isolation fit your product.	Needs rework
Authentication	Database, LDAP and OAuth through Flask-AppBuilder, with AUTH_ROLES_MAPPING for group-to-role mapping. Confirm any other SSO protocol you use.	Clean

What a .dash export carries into the new tool

A Sisense .dash export is documentation for the rebuild, not a file that Apache Superset can import. The file records each dashboard's widgets, filters and layout, and that inventory is the starting point for recreating the same views as Superset charts and dashboards that query your warehouse tables directly. Plan the work as a rebuild from the export's contents. Treat the export as a specification you read, and expect each widget to be re-created with its query, chart type and filter behavior checked against the source dashboard. For the export mechanics, including single-dashboard and batch exports from the Analytics page, follow the Sisense export guide linked from the migration sequence.

Sharing settings and BloX custom actions are not part of the export, so they must be inventoried by hand before anyone starts rebuilding. Record which groups and users can see each dashboard, which dashboards are shared outside the company, and any scheduled delivery or alerts. For BloX actions, list every custom action, the trigger it responds to and the outcome it produces, such as a link, a filter change or a call to an external service. Each action then needs an explicit decision: rebuild it with a Superset feature, replace it with a different workflow, or retire it after confirming with the business owner that nobody depends on it.

Ask Sisense administrators to confirm the complete list of dashboards and their owners before you accept an export as the inventory, because the file only covers what was exported. Compare that list against the Sisense data security rules and ElastiCube dependencies, since a dashboard that appears correct in the export may still rely on a row-level restriction defined elsewhere. Record the gaps in a tracking sheet with an owner for each item, and make the cutover decision for each dashboard only after its sharing and action inventory is closed.

Data, identities and integrations to move or rebuild

Dashboards are the visible part of a Sisense estate, but the data models, access rules, identities, scheduled deliveries and embedded consumers sit underneath them and do not move with a .dash file. Each item below needs a named owner and a test in Superset before any dashboard is declared migrated.

ElastiCube models to warehouse tables

ElastiCubes hold extracted, joined and calculated data inside Sisense. Superset does not import that model. It queries a SQL source at request time, so each cube needs a decision: point the dashboard at existing warehouse tables, build a view or dbt-style model in the warehouse that reproduces the joins and calculated measures, or add a query engine such as Trino in front of mixed sources. Check each connector against your own warehouse, since Superset connects to any SQL datastore with a Python DB-API driver and SQLAlchemy dialect, and confirm the driver version and dialect support for every source.

Data security rules as row-level controls

Sisense data security rules limit which rows and columns a user sees, and they must be rebuilt, not exported. In Superset, decide which rules map to row-level security filters on datasets and which map to role-based dataset and dashboard access. Write each rule as a short table (rule, source field, roles affected, test user) before building anything. Ask whether any rule depends on values stored in the ElastiCube that the warehouse does not hold, because those rules will fail silently if left unmapped.

Identities through LDAP or OAuth

Superset authenticates through Flask-AppBuilder with database, LDAP or OAuth2 options, including Google, Azure and custom OAuth2 servers using the code flow. Group membership can drive roles through AUTH_ROLES_MAPPING, so the group-to-role table becomes the central access document. Confirm which identity source holds the groups your Sisense roles use today, and test that a user removed from a group loses access on their next login, since Superset will not reflect group changes that your directory never sends.

Alerts and scheduled reports

Sisense schedules and alerts run inside the platform. In Superset, alerts and reports, async queries and dashboard thumbnails depend on the caching layer and Celery worker and beat processes, and most installations use Redis and Celery for them. Plan this as a separate component with its own sizing, monitoring and failure alerts. Inventory every Sisense schedule with its recipients, format and frequency, then confirm which ones a self-hosted Superset worker can reproduce before turning off the originals.

Embedded and iframe consumers

Any product or portal that embeds Sisense through iframes or the Compose SDK will break at cutover unless its embedding path is replaced. Superset offers its own embedded SDK with guest tokens, which requires the host application to issue tokens and enforce tenant boundaries. List every embedding location, the user population it serves and the filters it passes, then decide whether each one is an internal portal (simpler) or a customer-facing product (requires tenant isolation and theming work). Treat this as a separate workstream with its own testing.

The migration sequence, step by step

This sequence moves Sisense content to Apache Superset in controlled stages, so every dashboard is inventoried, proven on a pilot, reconciled against Sisense output and cut over with a signed record before Sisense is retired.

Inventory dashboards, models and access rules
The BI owner and a Sisense administrator list every dashboard, ElastiCube, data security rule, shared link, scheduled report, embed and BloX custom action in a dashboard register. Each row records the source tables, the owner, the users or groups with access, and whether the item is used. Record scheduled reports and embedded pages separately, because a .dash export does not carry them. The register is done when the owners of the top business dashboards have confirmed their rows in writing.
Stand up the Superset environment
The platform team deploys Apache Superset in your own infrastructure with a PostgreSQL or MySQL metadata database, a user-defined SECRET_KEY and, if alerts, reports or async queries are needed, the caching layer and Celery workers. Connect the warehouse drivers, configure SSO through Flask-AppBuilder and map identity groups to roles. The output is a staging instance and a short configuration record that lists versions, database drivers and authentication settings. Confirm the Superset release and Kubernetes installation method against current project documentation before you commit to a build.
Pilot a small set of dashboards
Choose a few dashboards that cover different ElastiCube patterns, such as a simple table, a joined model and a dashboard with row-level filtering. Rebuild each one in Superset as datasets, charts and filters, using warehouse tables or a query layer in place of the ElastiCube. Business owners review the pilot against the Sisense originals for layout, filters and definitions. The pilot is complete when owners sign off each dashboard and the team has a written list of gaps, such as widgets or BloX behavior with no direct equivalent.
Recreate permissions and schedules
Translate each data security rule into Superset roles, dataset permissions and row-level security filters, then test them with accounts from each group. Rebuild scheduled reports and alerts on the worker components, and confirm that delivery addresses and recipients match the register. Record every permission test in an access test log showing the account, the expected result and the actual result. This step ends when no tested account sees data it should not see.
Run in parallel and reconcile numbers
Keep Sisense and Superset live for the same dashboards and compare outputs for the same filters and date ranges. Finance or the metric owners check totals, dimensions and definitions, and any variance is logged with its cause. The reconciliation report lists each dashboard, the metrics compared, the variances found and the decision on each. Do not cut over a dashboard until its report is accepted by the business owner.
Cut over by business group
Move one business group at a time, starting with the group that has the fewest dependencies. Communicate new URLs, update embeds and bookmarks, and keep Sisense read-only for the moved content during an agreed fallback period. A signed-off cutover checklist for each group records the users notified, the links changed, the open issues and the approver. Move to the next group only after the previous checklist is closed.
Archive exports and decommission Sisense
Once every group has cut over and the fallback period has closed, export the remaining .dash files, model definitions, user lists and permission records and store them in an archive that your records policy allows. Confirm the archive can be read by the people who will need it. Then disable Sisense logins, revoke its service accounts, remove its database connections and shut down the deployment. The decommissioning record lists the archive location, the retained data and the approver who signed off.

How the move changes by starting point

When Sisense serves mainly internal teams reading dashboards from one data warehouse, the migration is usually the most contained. The main work is rebuilding charts, filters and layouts against the same tables, then moving the people who view them. Because the data already sits in a warehouse, the question is less about modeling and more about which tables, views and definitions each dashboard relies on.

Warehouse inventory: List every table and view each dashboard reads, and confirm which ones already exist as governed views.
Filter behavior: Note which dashboard filters are cascading, default-valued or tied to a user, since these need explicit rebuilding in Superset.
Sharing scope: Record who sees which dashboard today, because the .dash export does not carry sharing settings.
Refresh expectations: Confirm how often data must be current and whether caching or scheduled reports are needed.
Owner assignment: Name a business owner for each dashboard so that rebuilt content is checked against a real requirement.

Before starting, decide which dashboards are still used, since retiring unused content often shrinks the rebuild more than any technical step.

What drives cost and duration in this migration

This table lists the main drivers of effort in a Sisense to Apache Superset move and the cost components a quote should separate. Read the driver rows to see what enlarges the job, and the cost rows to see who is paid for each line and whether it is one-time or recurring. No fees or durations are given because none were supplied; ask for them in writing against your own inventory.

Driver or cost line	Why it changes effort or cost	How to keep it down or what to request
Number of dashboards and widgets	Each .dash export must be rebuilt as Superset charts, datasets and dashboards, and widget-level filters need manual mapping.	Inventory and retire unused dashboards first. Ask the vendor to quote per dashboard or per batch.
ElastiCube complexity and data volume	Joins, calculated columns and aggregations inside ElastiCubes must be re-expressed as warehouse views or SQL, and large cubes may need new query tuning.	Move cube logic into the warehouse before the cutover. Request a line for SQL modeling separate from dashboard rebuilds.
Data security rules	Sisense row-level and group rules do not transfer through the .dash export, so each rule must be recreated and tested for every role.	Document rules in a table before work starts. Ask for a separate line for permission design and testing.
BloX actions and custom widgets	Custom BloX actions and front-end customizations have no direct equivalent in the export and typically need redesign.	Count them early and decide which to drop. Request a fixed line for each custom component to be rebuilt.
Embedded consumers	Applications that embed Sisense content need their embedding flow, tokens and tenant logic changed for Superset's embedding model.	Keep embedded migration in a separate phase. Ask whether embedding work is in scope or a later change order.
Identity integration	SSO, LDAP or OAuth group mapping to Superset roles, including AUTH_ROLES_MAPPING, requires coordination with your identity team.	Confirm the identity provider and group model early. Request identity work as its own line item.
Caching and worker infrastructure	Alerts, reports, async queries and thumbnails need a caching layer and Celery workers, which add components to build, patch and monitor.	Decide early whether scheduled reports are needed. Ask for hosting lines for Redis and worker nodes separately.
Validation depth and staff availability	Side-by-side checks of numbers, filters and permissions take time, and delays occur when business owners or data engineers are unavailable.	Agree acceptance criteria per dashboard in writing. Name the internal owners and their time commitment in the scope.
Platform hosting (recurring)	Servers or Kubernetes capacity, metadata database and storage for your own infrastructure are paid to your cloud or data center provider.	Size from the architecture docs and ask your infrastructure team for the monthly run cost. Note that Superset itself has no license fee.
Implementation and migration fees (one-time)	The vendor is paid for inventory, rebuild, permission work, testing and documentation, usually under a fixed-scope agreement.	Request the written scope, deliverables and timeline, with each dashboard, cube and rule listed separately.
Support and upgrades (recurring)	Upgrades require backing up the metadata database, running database migrations, staging tests and reviewing UPDATING.md for breaking changes.	Ask whether support is an optional retainer and what it covers, such as patching and upgrade testing.

What usually goes wrong and how to prevent it

Most failed Sisense to Superset migrations fail quietly: the export looks complete, the numbers drift, and access is wrong in ways nobody notices until a user does. The cards below cover the risks that tend to surface late, each with a check to run before cutover.

Exports treated as complete

A .dash file carries dashboard layout and widgets, but it leaves out sharing settings and BloX custom actions. Teams that count exported dashboards as the full inventory discover missing links, buttons and shared views after users have already moved. Build a separate list of sharing settings and BloX actions for every dashboard, and sign off that list before the rebuild starts.

Numbers that do not reconcile

Figures can differ between Sisense and Superset because of ElastiCube aggregation, filter defaults, time zone handling or a different query path to the same warehouse. A chart that looks right in Superset may still disagree with the old figure by a margin that matters to finance or clinical reporting. Pick a set of key metrics, record the Sisense values, and reconcile each one in Superset before any user sees the new dashboard.

Permissions recreated too loosely or tightly

Sisense group and data security rules do not transfer as a file, so permissions are rebuilt by hand or mapped from LDAP or OAuth groups. Too loose a mapping exposes restricted data to users who never had it, and too tight a mapping breaks dashboards for people who need them every day. Map each Sisense group to a Superset role on paper, use AUTH_ROLES_MAPPING for group-driven access, and test with a sample account from each group.

Underestimated ElastiCube logic

ElastiCube models often hold joins, calculated columns, cleansing steps and aggregations that users never see but every chart depends on. In Superset these must move into warehouse tables, views or a query engine, and that work is easy to underestimate. Inventory each ElastiCube, list its transformations, and decide for each one whether it becomes a SQL view, a dbt model or a dataset definition before rebuilding any chart.

Unplanned Superset upgrades

Superset releases can contain breaking changes, and the upgrade path runs superset db upgrade and superset init against the metadata database. Upgrading a production instance without a backup, a staging run and a read of UPDATING.md can break dashboards or logins at the moment users need them. Back up the metadata database, test each version in staging, and schedule upgrades as a planned change with a rollback path.

Helm chart or Operator choice

The official Helm chart is documented for Kubernetes installs in the 6.1.0 docs, while current development documentation marks that chart as deprecated and points new deployments to the Apache Superset Kubernetes Operator. Choosing the older path without checking its status can leave the team with a deployment method that will need replacing during the first year. Confirm the current recommendation with the project before writing deployment code, and record the choice in the migration plan.

Running Superset safely after cutover

Once dashboards are rebuilt and users have moved over, the team takes on routine operation of Superset, and the first control is the metadata database. Superset stores dashboards, charts, datasets, users and roles in it, so a verified backup must exist before every upgrade. Superset is tested with PostgreSQL and MySQL for this role, and the supported metadata database versions are PostgreSQL 10 to 17 and MySQL 5.7 and 8.x, according to the configuration documentation. Confirm the version you run against that list before cutover, and record who owns the backup schedule and restore test.

Each upgrade follows the same documented sequence: back up the metadata database, run superset db upgrade and then superset init, and test in staging first. Check UPDATING.md in the repository for breaking changes between your current version and the target, and read the release notes for the specific version before you start. Build the staging environment from the same configuration file, the same metadata database engine and the same database connections used in production, so that dashboards, datasets and role mappings are exercised rather than assumed. Keep the rollback path written down: restoring the backup is the only documented way to return the metadata to its earlier state.

Two configuration decisions carry long-term risk. Superset requires a user-specified SECRET_KEY to start, and it supports rotation through PREVIOUS_SECRET_KEY, so store the key in your secrets manager, not in a file in the repository, and plan rotation as a change with a defined window. Do not run production on the SQLite default used by Quickstart and PyPI installs, and do not use the Docker Compose PostgreSQL container as the production metadata database, because the architecture documentation does not recommend either. Confirm with the current installation and architecture pages, and the release notes for your version, whether the caching, Celery worker and beat components are needed for your alerts, reports and async queries.

Questions buyers ask before moving from Sisense to Superset

How much effort and cost does moving from Sisense to Superset involve?

The move cost is driven by how much Sisense content you have and how much of it depends on Sisense-specific features. Superset itself carries no license fee under Apache-2.0, so your spend shifts to infrastructure, implementation, migration and ongoing operations. The main cost drivers are the number of dashboards and widgets to rebuild, the number of ElastiCube models that must be replaced with warehouse tables or a query engine, the number of BloX custom actions and sharing or data security rules to recreate, and whether you need caching and Celery workers for alerts, reports and async queries. Ask each vendor for a fixed-scope quote with a written inventory of dashboards, data models, users and integrations. Quotes should separate one-time work (migration, testing, hardening) from recurring work (hosting, upgrades, support).

How long does a Sisense to Superset migration take, and why does it vary?

Duration depends mainly on inventory size and how much logic lives inside Sisense rather than in your warehouse. Dashboards that sit on clean warehouse tables are usually faster to rebuild than those that depend on ElastiCube joins, calculated fields and custom actions. Other factors include how many data sources must be connected, how many roles and data security rules need mapping, whether you run a staging environment, and how many stakeholders must sign off on each dashboard. Superset's upgrade guidance recommends testing in staging and checking the project's UPDATING.md file for breaking changes, so allow time for that. Request a timeline in the written scope rather than relying on a general estimate.

What does our internal team need to provide during the move?

Your team needs to supply knowledge and access that only your organization holds. Expect to provide an inventory of Sisense dashboards and .dash exports, a list of ElastiCubes and the source systems behind them, the warehouse credentials and network access Superset will use, and the business definitions for every metric being rebuilt. You will also need named owners who can approve dashboards, confirm numbers against the old reports, and decide which obsolete content to retire. On the platform side, someone must own identity integration through OAuth2 or LDAP, the metadata database, secret handling and the Kubernetes or VM environment. Without these owners, rebuilt dashboards often stall in review.

Can our own engineers do the migration without an implementation partner?

Yes, a capable internal team can migrate, provided it has the skills and time. Superset is built on Flask-AppBuilder and connects to any SQL datastore through a Python DB-API driver and SQLAlchemy dialect, so the technical work is familiar to data and platform engineers. The harder parts are rebuilding ElastiCube logic in SQL or a query engine, recreating permissions, operating PostgreSQL or MySQL for metadata, and maintaining upgrades. Ask whether your team can cover these areas for the full migration period and afterwards. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with agreed deliverables in writing before work starts. Ongoing support and upgrades are also available as retainers.

Can everything in Sisense be reproduced in Superset?

Most dashboard content can be reproduced, but some Sisense features need a different approach. A .dash export captures dashboard structure, widgets and filters, but it leaves out sharing settings and BloX custom actions, and ElastiCube models are not rebuilt automatically. Superset works from queries against your warehouse, so calculated logic must move into SQL, dbt models or a query engine. Data security rules, row-level access and group permissions must be recreated through Superset roles and mapping settings such as AUTH_ROLES_MAPPING. Embedding and alerting also need separate design work, since alerts, reports and async queries depend on the caching layer and Celery workers. Build a feature-by-feature gap list before committing to a scope.

How does Sisense licensing compare with Superset's no-fee model?

Sisense is sold as SaaS, dedicated cloud or on-premises software with prices quoted by sales, so its cost is a recurring contract that depends on your deployment and terms. Apache Superset is licensed under Apache-2.0 and maintained by the Apache Software Foundation, and the project has no paid edition, so there is no license fee to remove at renewal. Your recurring costs become infrastructure, staff time, support and upgrade work. Ask Sisense for the renewal terms, what the subscription includes and what exit obligations apply, and compare those with your own hosting and operating estimates. The licensing comparison does not include the migration cost, which is one-time.

When Superset is the right target, and when to look elsewhere

Superset fits best when your team wants a SQL-first BI layer on top of a warehouse or query engine that it already trusts. Superset connects to any SQL datastore with a Python DB-API driver and SQLAlchemy dialect, so dashboards are built from tables you control rather than from a proprietary model. Before committing, confirm that your warehouse or query engine has a supported driver, that your team is comfortable writing or reviewing SQL for datasets and charts, and that you can run the components Superset needs in production: a PostgreSQL or MySQL metadata database in a supported version, a caching layer and Celery workers if you rely on alerts, reports, async queries or dashboard thumbnails, and a secret key managed as part of your configuration. If those prerequisites are not in place, the migration will also require building platform capacity, not only rebuilding dashboards.

If your Sisense estate depends heavily on ElastiCube modeling, a Superset migration changes where that logic lives. ElastiCube joins, calculated fields and data security rules do not carry over as a block. Each one must be moved into warehouse views, Superset datasets or Superset's own role and permission settings, and the owners of those rules need to sign off on the result. Superset authentication can map LDAP or OAuth groups to roles through AUTH_ROLES_MAPPING, which helps with access control, but row-level restrictions need to be designed and tested explicitly. Metabase may be a better fit for smaller internal dashboard sets that need a lighter footprint and a simpler point-and-click experience, and the sibling pages Sisense vs Apache Superset and Sisense vs Metabase compare those trade-offs in detail. Review them before you decide, and treat this choice as a documented decision rather than a default.

How DeployOpen scopes and runs the Sisense to Superset migration

DeployOpen plans and runs the move from Sisense to Apache Superset inside your own cloud account, data center or air-gapped network. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

Inventory every Sisense dashboard, ElastiCube, data security rule and BloX action before estimating the rebuild
Confirm which warehouse tables, query engine or sources each dashboard depends on in Superset
Agree in writing which dashboards, filters, embedded views and permissions are in the migration
Record the Superset hosting target, including the metadata database and whether caching and workers are needed

How we build

Stand up Superset with a PostgreSQL or MySQL metadata database, a user-specified SECRET_KEY and staging first
Rebuild dashboards and charts against the agreed data sources, checking results against the Sisense originals
Configure authentication through database, LDAP or OAuth providers and map groups to Superset roles
Test access rules, query results and scheduled reports in staging before any production cut-over

How we hand over

Document the Superset deployment, configuration keys, data source connections and role mappings
Provide a rebuild register that maps each Sisense asset to its Superset equivalent, including gaps
Walk your team through dashboard ownership, upgrade steps and the backup and restore procedure
Record open items, such as features with no direct Superset equivalent, for your decision

How we support

Support upgrades by backing up the metadata database and reviewing UPDATING.md before each version change
Available as a retainer for ongoing operations, upgrades, hardening and continuous testing
Confirm with your team which support hours, response expectations and channels the retainer covers
Plan Superset version upgrades in staging before production, since releases change between versions

Migrate from Sisense to Apache Superset