Migrate from ThoughtSpot to Apache Superset

Migrate from ThoughtSpot to Apache Superset: what moves and what does not

Moving from ThoughtSpot to Apache Superset is a rebuild of your semantic model and dashboards on Superset datasets and charts, not a file import. Your TML exports are the specification for that rebuild: they describe Models, joins, formulas, columns and Liveboards, but Superset does not read them as an installable package, so each object is recreated by hand or with scripts you write. Renewal or pricing pressure usually triggers the decision, but the work is driven by how much of your business logic lives in ThoughtSpot Models and how many Liveboards depend on them. The BI lead owns scope and acceptance criteria. Data engineers set up the Superset deployment, the metadata database, the caching and worker components if you need alerts, reports or async queries, and the database connections, using the supported PostgreSQL or MySQL versions in the configuration documentation. A few power users who know the Liveboards best should validate each recreated chart against the numbers ThoughtSpot returns today. An implementation partner is worth considering if the Model count is high, SSO and role mapping must be in place at go-live, or the team has no one who has run Flask-AppBuilder-based software in production before. Effort and risk concentrate in two places. The first is semantic logic: ThoughtSpot formulas and joins must be reproduced as Superset datasets, metrics and calculated columns, and any difference in aggregation or null handling will change numbers, so reconcile every key dashboard before retiring it. The second, and the largest change for users, is the habit of typing a search-style question and getting a chart back. Superset is built around explorable datasets and charts rather than natural-language search, so business users should be told early which questions they will now answer through a saved chart or the chart builder, and training should start before cutover.

Which ThoughtSpot capabilities map to Superset, and which need rework

This table compares the main ThoughtSpot capabilities with their closest Apache Superset equivalents and marks each as clean, needs rework or gap. Read the status column as a planning signal, then confirm each item against the Superset release you intend to deploy. The main takeaway is that data modeling and dashboards move with moderate effort, while search-style questions do not have a direct replacement.

Capability	ThoughtSpot object or feature	Superset equivalent and status
Models and joins	Worksheets and Models with joins, exported as TML	Datasets over physical tables or virtual datasets written in SQL. Needs rework: joins are re-expressed in SQL, and each join must be checked against the source.
Formulas	Formulas defined on Models and Answers	Calculated columns and metrics in the dataset definition using SQL expressions. Needs rework: rewrite each formula and validate results against known ThoughtSpot values.
Liveboards	Liveboards with tiles and filters	Dashboards built from charts with native filters. Needs rework: layout, filter behavior and cross-filtering must be rebuilt by hand.
Answers	Saved search answers and their visualizations	Saved charts on a dataset. Needs rework: each Answer becomes a chart with an explicit query, so search terms do not carry over.
Row-level security	Row-level security rules on Models and groups	Row-level security filters applied to roles on datasets. Needs rework: rules must be re-authored and tested with each role.
Role-based access	Groups, privileges and object sharing	Roles and permissions managed through Flask-AppBuilder, with LDAP or OAuth group mapping through AUTH_ROLES_MAPPING. Needs rework: map groups to roles and review permissions.
Scheduled alerts and reports	Scheduled Liveboard and Answer delivery	Alerts and reports, which need the caching layer and Celery worker components. Needs rework: schedules, recipients and worker infrastructure must be set up.
Embedding	Embedded analytics with ThoughtSpot embed SDK	Embedding through the Superset embedding options. Needs rework: confirm the embedding method and authentication flow in the release you plan to use.
Search-style natural language questions	Search bar with AI-driven question answering	No direct equivalent. Gap: users must build charts or use SQL Lab. Confirm current capability in the Superset release before promising it.

Exporting ThoughtSpot content and rebuilding its integrations

A ThoughtSpot migration has two halves: the content that users see and the connections that feed it. The TML export gives you a written specification for the first half, while the second half, database access, identity and delivery, has to be rebuilt in Superset's own configuration. Work through both before any dashboard is recreated.

TML export as the specification

Export Models, Liveboards, Answers and alerts as TML before you change anything, and keep those files under version control as the record of what the migration must reproduce. Each file describes joins, formulas, column definitions and layout in text, which makes it the most reliable starting point for building Superset datasets and charts. Confirm the export scope for your release in ThoughtSpot's documentation, because object types and export options can vary by version and by how your instance is configured.

TML describes structure, not data

TML files record the shape of your semantic layer and content, but they contain none of the warehouse rows behind it. Superset reads data directly from your databases, so the migration needs working connections to the same sources, with the same grants and the same filtering rules. Plan a reconciliation step where row counts and key metrics from a Liveboard are compared with the rebuilt Superset chart before users are moved over.

Source connections through SQLAlchemy

Superset connects to any SQL datastore that has a Python DB-API driver and a SQLAlchemy dialect, so each warehouse ThoughtSpot queried needs a matching driver installed in the Superset image. Store connection credentials in Superset's database connection settings with a dedicated read-only service account, and confirm that the driver versions are pinned in your build. Test every connection from a staging instance, since a missing driver usually surfaces only when a user opens a chart.

Identity through LDAP or OAuth

Superset supports database, LDAP and OAuth authentication through Flask-AppBuilder, and it can map directory groups to Superset roles with AUTH_ROLES_MAPPING. Translate the ThoughtSpot groups and privileges you exported into role mappings in advance, so that row-level and object-level access is not granted by hand after go-live. Check which permissions your users need on datasets and charts, because a broad Admin mapping is the most common shortcut and the hardest to audit later.

Secret keys and configuration

Superset requires a user-specified SECRET_KEY before it will start, a requirement that dates from version 2.1.0, and it supports rotating that key with PREVIOUS_SECRET_KEY. Store the key and all connection secrets in your secrets manager rather than in the configuration file, and document the rotation procedure before the first production run. Mismatched keys between replicas are a frequent cause of failed logins after a deployment change.

Scheduled delivery and embedding

Alerts, scheduled reports and dashboard thumbnails depend on the caching layer and Celery worker and beat processes, and these have to be deployed and monitored separately from the web application. Inventory every ThoughtSpot alert and every embedded Liveboard in your applications, since embedded views need their own authentication and URLs in Superset. Decide early which scheduled deliveries must run on time, because the worker components become part of your availability plan.

How to run the migration in five steps

This sequence moves ThoughtSpot content to Apache Superset in an order that keeps business users working throughout, with each step closing on a written output that gates the next one.

Inventory TML objects and actual usage
Export Models, Tables, Views, Answers and Liveboards as TML, then pull usage data from ThoughtSpot to see which Liveboards and Answers people open. Map each object to its upstream tables, joins, formulas and filters, and mark the ones nobody has used in a long period as retirement candidates. The output is a dependency list and an inventory that names an owner for every Liveboard in scope. Confirm with your ThoughtSpot administrator which export and usage reports your edition provides.
Build the semantic layer in Superset
Connect Superset to the same warehouse or database, then create datasets for the tables and views the inventory requires. Recreate joins as virtual datasets where needed, and move formulas into dataset calculated columns or saved metrics, checking each result against a ThoughtSpot Answer with the same filters. Because Superset has no built-in search-style question engine, document which business questions will map to saved charts and which will need a new chart. The output is a reviewed set of datasets with a metric definition sheet.
Pilot one Liveboard and get sign-off
Choose one Liveboard that represents a typical workload, rebuild it as Superset charts on a dashboard, and set up access through the authentication method your organization uses, such as database, LDAP or OAuth with AUTH_ROLES_MAPPING. Have the business owner compare figures, filters and drill paths against the ThoughtSpot original for an agreed set of test questions. The output is a signed pilot record listing differences and how each was resolved.
Run both tools in parallel
Rebuild the remaining in-scope Liveboards and run the same questions through ThoughtSpot and Superset for a defined period agreed with the business. Log every mismatch in a reconciliation report, classify it as a data, definition or presentation difference, and fix the source of each one. Track which users still rely on search-style questions and give them a documented path, such as a saved chart or a dataset they can filter. The output is a reconciliation report with zero open data differences before cutover.
Cut over with a tested rollback plan
Write a cutover runbook that covers the Superset production install, the metadata database backup, the upgrade and init steps your version requires, access provisioning, user communication and the named owner for each action. Rehearse it in staging first, as the Superset upgrade documentation advises, and define the rollback trigger and the steps to return users to ThoughtSpot. The output is a rehearsed runbook and a go or no-go record approved by the business owner.
Decommission ThoughtSpot after retention
After cutover, keep the TML exports, the reconciliation report and the runbook in controlled storage, and keep ThoughtSpot read-only for a retention period set by your records and compliance policy. Revoke user access, remove connections and service accounts, then confirm that data held in ThoughtSpot is deleted or retained as your policy requires. The output is a decommissioning certificate listing what was removed, where archives are kept and who approved the closure.

How the Superset platform is built and what it needs to run

Apache Superset is built from four components, and the plan should size and secure each one separately. The core is the Flask and React application that serves dashboards, charts and the SQL Lab editor. Next is the metadata database, which stores Superset's own objects: users, roles, dashboards, charts, datasets and saved queries. The architecture documentation lists a caching layer as optional, and Celery worker and beat processes as optional too. In a ThoughtSpot migration, the metadata database is the one that matters most to protect, because it holds the rebuilt Liveboard equivalents and the access model. It is not the same thing as the analytical warehouse that Superset queries, and the two should be kept apart in the design.

The caching layer and the Celery workers are needed for specific features, not for basic viewing. According to the architecture documentation, alerts and reports, async queries and dashboard thumbnails depend on them, and most installations use Redis and Celery for this. If users in the ThoughtSpot environment rely on scheduled delivery of Liveboards, or on long-running queries, plan for these components from the start. The documentation does not treat SQLite as acceptable for production. The default used by Quickstart and PyPI installs, and the PostgreSQL container in the Docker Compose setup, are not recommended for production use. Choose PostgreSQL or MySQL for the metadata database, and confirm the exact supported versions in the configuration documentation before you provision them. The configuration documentation lists PostgreSQL 10 to 17 and MySQL 5.7 and 8.x.

Superset refuses to start without a user-specified SECRET_KEY, a requirement added in version 2.1.0, so the key must be generated, stored and injected through your secrets management process rather than kept in a config file in source control. Document who holds the key, how it is rotated using PREVIOUS_SECRET_KEY, and how database credentials for the metadata store and every analytical source are supplied to the containers. Authentication decisions belong in the same plan: Superset supports database, LDAP and OAuth login through Flask-AppBuilder, and AUTH_ROLES_MAPPING maps identity-provider groups to Superset roles. Ask your identity team which groups will map to which roles before cutover, because ThoughtSpot's group and object permissions will not carry over automatically.

How the migration changes by team size and starting point

A small team with a handful of Liveboards usually has one or two people who know the data model and few stakeholders to coordinate. The work is mostly manual rebuilding, so the main planning decision is whether to rebuild everything at once or to move the most-used dashboards first and retire the rest. Because the library is small, the TML export can serve as a short checklist rather than a large inventory.

Export first: Pull the Models and Liveboards as TML so every join, formula and column definition is written down before anything is rebuilt.
Pick the core set: Move only the dashboards people open each week, and confirm with users which others can be archived.
Stand up a single Superset instance: A small deployment on PostgreSQL for metadata is enough to start, and it can be upgraded later under the upgrade steps in the Superset documentation.
Rebuild datasets once: Define each dataset and its metrics in Superset so several charts can reuse them.
Run a short parallel period: Keep ThoughtSpot available until the chosen dashboards match the numbers users already trust.

Before you start, confirm with your ThoughtSpot contract when access ends and how long exports remain available to your team.

What drives migration cost and duration

This table lists the main drivers of effort in a ThoughtSpot to Apache Superset migration, why each one moves cost or time, and how to keep it down. Read it as a checklist for scoping: the largest drivers are usually the number of Liveboards and Answers that depend on search-style questions, the join and formula complexity inside Models, and identity and alerting requirements. Cost components are staff time, infrastructure, support, upgrades and any fixed-scope partner work, and only the ones your organization pays for recur.

Driver	Why it moves effort	How to keep it down
Number of Liveboards and Answers	Each Liveboard must be rebuilt as a Superset dashboard of charts on datasets, and each Answer needs a chart or saved SQL, so the count sets the rebuild and test load.	Inventory the TML exports first, retire unused Liveboards, and consolidate near-duplicates before rebuilding.
Join and formula complexity in Models	Joins, formulas and column definitions must be restated as Superset datasets, virtual SQL and metrics, and differences in aggregation behavior need validation against known totals.	Document each Model's joins and formulas from the TML, rebuild shared logic once as reusable datasets or metrics, and set reconciliation checks for key figures.
Number and type of data sources	Each source needs a connection in Superset through a SQLAlchemy dialect and a Python DB-API driver installed in the Superset image, plus network and credential setup for each.	Confirm that every source has a supported driver before scoping, and group sources by platform so drivers and connection tests are handled together.
Identity integration	Mapping users to roles through database, LDAP or OAuth2 login and AUTH_ROLES_MAPPING requires configuration and testing against each identity provider, and row-level access must be rebuilt.	Decide the role model early, reuse existing groups in your identity provider, and test one login path per provider before migrating users.
Alerts, reports and scheduled delivery	Scheduled reports and alerts rely on the caching layer and Celery worker and beat components, which must be deployed, monitored and tested, not only the dashboards.	List every ThoughtSpot alert and schedule, decide which ones must continue, and deploy the worker components only for those.
Embedded use	Embedded Liveboards in other applications need a separate integration, authentication flow and testing, which is usually larger than the internal dashboard rebuild.	Identify embedded content in the inventory and scope it as its own workstream with its own acceptance tests.
User training and expectation setting	Users who ask search-style questions must learn to build charts on datasets, which lowers adoption if not planned, and this work recurs for each new group of users.	Publish example questions mapped to Superset charts, run short hands-on sessions, and state clearly which search-based answers will not be replicated.
Parallel-run length	Running ThoughtSpot and Superset side by side keeps both platforms' costs active and requires reconciling outputs until users accept the results.	Agree exit criteria for each dashboard in advance and retire ThoughtSpot content in batches as each one is accepted.
Partner fees under a fixed scope	If an implementation partner is used, fees follow the written scope of deliverables, so unclear scope or added requirements increase the quote.	Ask for a quote that lists Liveboards, Models, sources, identity and alerting items separately, with change control for additions.

Questions buyers ask before moving from ThoughtSpot to Superset

How long does a ThoughtSpot to Superset migration take?

No duration can be stated from the researched facts, so treat any number you hear as a guess until your own content has been inventoried. The main drivers are how many Liveboards and Answers are in active use, how many Worksheets, Models and Views sit underneath them, how many joins and custom formulas must be rebuilt by hand, and how many users depend on each dashboard. Ask for a written scope that lists these counts and the acceptance tests for each item. Superset itself is a stable starting point: the current release, 6.1.0, was published on May 13, 2026, according to PyPI, and you should confirm which version your environment will pin.

Can our own team migrate from ThoughtSpot to Superset without outside help?

Yes, a team with SQL skills, access to the source warehouse and someone who understands the ThoughtSpot data model can do much of the work in house. The harder parts are rebuilding joins and formulas consistently, setting up the metadata database, the caching layer and Celery workers for alerts and reports, and wiring authentication through OAuth2, LDAP or database login with role mapping. Outside help is most useful for a fixed-scope engagement covering the architecture, the rebuild of a defined set of dashboards and the hardening and handover. Compare internal hours against that written scope rather than against the license fee you are avoiding.

What do business users need to do during the move?

Business users need to review the rebuilt dashboards against the ThoughtSpot originals, confirm that filters, definitions and date logic produce the same numbers, and agree on what changes in how they navigate. They also need time to learn charts, filters and SQL Lab in Superset, which works differently from a search bar. Plan a parallel-run period in which both tools show the same figures, and name a business owner for each dashboard who signs off on it. Without that sign-off, discrepancies surface after cutover, when they are harder to explain.

Can search-style questions in ThoughtSpot be replaced in Superset?

Not one for one. ThoughtSpot's natural-language search answers ad hoc questions typed into a search box, while Superset is built around dashboards, charts and a SQL-based explorer. Users who relied on search will need predefined charts, filtered dashboards and governed datasets for the questions they ask most often, and they will need SQL Lab or a separate tool for truly open-ended questions. Inventory the Answers your users actually run, group them into recurring questions, and decide which become Superset charts. Be explicit with stakeholders about questions that will no longer be self-serve, and ask your vendor or implementer to confirm what Superset's current release supports in any AI-assisted feature before you promise it.

How do we keep ThoughtSpot exports as the specification for the migration?

Export the Models, Worksheets, Views, Answers and Liveboards as TML before your subscription changes, and store them in version control so they cannot be lost or edited silently. Treat each TML file as the specification for its Superset counterpart: record the joins, formulas, column names, filters and default parameters, then map each to a Superset dataset, metric or chart. Keep a short reconciliation table per dashboard that compares row counts and key totals between the two tools. Check the exports with your ThoughtSpot administrator, because the export scope depends on object types and permissions in your deployment.

What do Superset upgrades cost in ongoing effort?

Upgrades recur, and they are the main ongoing effort after launch. The Superset upgrade documentation says to back up the metadata database, run superset db upgrade and superset init, test in staging first, and read UPDATING.md for breaking changes between versions. Effort depends on how many customizations, custom database drivers and plugins you run, how many environments you maintain, and how often you move forward. Ask for a retainer scope that covers staging tests, upgrade runs and documented rollback steps, and confirm the upgrade cadence with your own security and change teams.

Which parts of the Superset stack should we confirm before committing?

Confirm five things in your environment. First, the metadata database: Superset is tested with PostgreSQL and MySQL, and the SQLite default is not recommended for production. Second, supported versions: the configuration documentation lists PostgreSQL 10 to 17 and MySQL 5.7 and 8.x. Third, the caching layer and workers, which alerts, reports and async queries need, usually Redis and Celery. Fourth, the SECRET_KEY, which must be set explicitly and can be rotated with PREVIOUS_SECRET_KEY. Fifth, how your identity provider maps to Superset roles through AUTH_ROLES_MAPPING. Check each item against the architecture and configuration documentation before the scope is signed.

What usually goes wrong and how to prevent it

Most failed ThoughtSpot to Superset moves do not fail on dashboards. They fail on assumptions about what the export contains, who depends on search, and how Superset itself is secured, backed up and upgraded. The cards below pair each risk with one prevention step to take before cutover.

Assuming TML holds warehouse data

TML files describe Models, Liveboards and Answers, including joins, formulas and column definitions. They do not contain the underlying warehouse rows, so the export is a specification, not a data copy. Teams that expect to lift data out of TML find the gap only when Superset datasets return nothing. Confirm that each Superset dataset points to a live connection to the source warehouse, and verify row counts against ThoughtSpot for a sample of key objects.

Underestimating search-driven users

Users who ask questions in ThoughtSpot search do not map one to one onto Superset charts. Superset is built around datasets, charts and dashboards, so ad hoc questions require an analyst to build or extend a chart, or an SQL Lab query. Without warning, these users will feel the change as a loss of capability. Survey the top search users before cutover, list their most common questions, and agree in writing which ones Superset will answer directly and which will need a prebuilt chart.

Unmanaged SECRET_KEY and metadata backups

Superset will not start without a user-specified SECRET_KEY, and the metadata database holds dashboards, charts, datasets, users and connection settings. Losing either the key or a recent metadata backup means rebuilding content by hand or re-entering credentials. Store SECRET_KEY in a secrets manager with a documented rotation process that uses PREVIOUS_SECRET_KEY, and schedule tested backups of the PostgreSQL or MySQL metadata database. Restore a backup into a scratch environment at least once before go-live.

Skipping staging for Superset upgrades

Superset upgrades run database migrations, and breaking changes are listed in UPDATING.md. Applying a new release directly to production can break charts, permissions or custom plugins without warning. Before any upgrade, back up the metadata database, run superset db upgrade and superset init in a staging copy, read UPDATING.md for every version between current and target, and only then promote the change. Record the version you run so later upgrades start from a known state.

Metric definitions drifting during parallel run

During the parallel run, ThoughtSpot and Superset will often show different totals for the same KPI because of differing filters, time zones, null handling or rounding in formulas. Business users then distrust both tools. Choose a single owner for each core metric, write its definition once in SQL or in the dataset, and reconcile the two outputs for an agreed period. Do not sign off a cutover until the reconciled variances are explained and accepted by the metric owners.

Permissions drift after LDAP or OAuth mapping

Superset maps LDAP or OAuth groups to roles through AUTH_ROLES_MAPPING, and access to datasets and dashboards follows those roles. If group names change in the identity provider, or users keep roles granted by hand, access quietly broadens or narrows. Document the mapping as code, review it on a fixed schedule, and test access for a set of named users in each role after every change. Confirm that row-level restrictions from ThoughtSpot are reproduced in Superset before the parallel run begins.

How DeployOpen scopes and runs the migration

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted Apache Superset inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. For a ThoughtSpot move, the work usually spans more than installing Superset. It includes deciding where the *metadata database* lives (PostgreSQL or MySQL, both tested by the project), wiring the optional caching layer and Celery workers if you need alerts, reports or async queries, setting up OAuth2 or LDAP with role mapping through AUTH_ROLES_MAPPING, and confirming that the SECRET_KEY handling, backups and staging environment are in place before any dashboard is rebuilt. Each of these is a decision your security and data teams should take early, not after the first Liveboard is recreated. Most engagements are fixed-scope. Before work starts, the scope, the deliverables and the timeline are agreed in writing. For this migration, a useful written scope names the ThoughtSpot objects in scope (from the TML export inventory), the target datasets and charts, the authentication and role model, the upgrade policy for future Superset releases, and the acceptance tests each dashboard must pass. DeployOpen does not publish a price list. A quote follows from that written scope, so the more precisely you define the inventory and the user groups, the more precisely the quote can reflect the work. Ask for the cost components to be itemized: infrastructure and environment setup, data modeling, dashboard rebuilding, identity integration, documentation and knowledge transfer. Ongoing support, upgrades and continuous testing are available as retainers. This matters because Superset releases move quickly: the project's upgrade documentation asks operators to back up the metadata database, run superset db upgrade and superset init, test in staging, and check UPDATING.md for breaking changes. A retainer can carry that cycle for you after go-live. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications; independent auditors do that work. Confirm with your own assessor which records they will expect from the migration.

Migrate from ThoughtSpot to Apache Superset