How to export your ThoughtSpot content with TML before you leave
A renewal, a pricing change or a data residency requirement has forced a review of ThoughtSpot, and the first practical step is to get your content out in a form you can read and version. TML, ThoughtSpot Modeling Language, is the vendor-documented way to export ThoughtSpot objects as text files. TML describes the objects themselves, such as their joins, columns, formulas, visualizations and layout, but it does not carry the underlying warehouse data and does not capture every runtime behavior, such as search-token interpretation, caching or permissions applied at query time.
Start by inventorying what you have. The objects typically discussed in ThoughtSpot migrations include Models, Views, SQL views, Tables, Answers and Liveboards, plus alerts. Each exports as a file that records its definition, so the export can be checked against the live system and kept in your repository. Confirm the current object list, the export options and any limits on bulk export in ThoughtSpot's own documentation, and ask your ThoughtSpot administrator which content your organization can export with its current roles. Note anything that does not come through cleanly, because those items will need manual work.
Treat the TML files as the specification for the rebuild, not as a finished migration. Use them to document each join, calculated column, filter and chart that a business user relies on, and map each to its counterpart in your target tool, such as a dataset and metric in Apache Superset or a model and question in Metabase. Anything that depended on search behavior, such as free-text questions or auto-generated charts, will have no direct file equivalent and should be listed separately so that users can agree on what replaces it. Store the exported files under version control with a dated tag, so the baseline you signed off on remains available after the source system is switched off.
Which ThoughtSpot objects export as TML, and in what format
This table lists each ThoughtSpot object type named for the migration, how to pull its TML, and what to confirm before relying on the file. Read it as a checklist: the export method and limits are for you to verify in your own tenant and release, because the facts supplied for this page do not cover ThoughtSpot's TML behavior. The main takeaway is that TML files describe content, but they do not replace testing each object in the target tool.
| Object type | Export method | File format | Known limits to confirm with ThoughtSpot |
|---|---|---|---|
| Models | TML export from the UI or the vendor's API, as confirmed for your release | TML text file describing the model | Confirm which joins, formulas, column definitions and security rules are included in the file |
| Views | TML export from the UI or the vendor's API, as confirmed for your release | TML text file describing the view | Confirm how views that depend on other objects are referenced in the file |
| SQL views | TML export from the UI or the vendor's API, as confirmed for your release | TML text file with the SQL definition | Confirm whether the SQL text is complete and how it behaves on the target database dialect |
| Tables | TML export from the UI or the vendor's API, as confirmed for your release | TML text file describing the table mapping | Confirm that connection details and credentials are excluded from the file |
| Answers | TML export from the UI or the vendor's API, as confirmed for your release | TML text file describing the search query and chart | Confirm whether search tokens map to a query you can rebuild as SQL or a dataset |
| Liveboards | TML export from the UI or the vendor's API, as confirmed for your release | TML text file describing tiles and layout | Confirm how tile layout, filters and parameters are represented for rebuilding |
| Alerts | Confirm whether alerts export as TML or must be documented manually | Confirm the file format, if any, for alert definitions | Confirm recipients, schedules and thresholds are captured, since they may not be in standard TML |
What each TML file describes and why it matters for the rebuild
A ThoughtSpot export gives you a written record of how each object is built, but each object family carries a different share of logic that a target tool must reproduce. Read the cards in order from data definitions to delivery, and check each file against the live objects in your own tenant before you sign off on the migration scope.
Data models and views
Models and Views describe the semantic layer that business users search against: which tables are joined, which columns are exposed, how they are named, and which formulas and filters sit on top. This is usually the most valuable file family because it holds the logic your metrics depend on. In the target tool, joins and calculated fields will likely be recreated as datasets, metrics or a semantic layer, so compare each join condition and formula line by line against the export. Confirm which fields are described in the files by opening a sample in your own environment.
Table definitions
Table files record the connection to the underlying warehouse object, the database and schema references, and the columns that the platform has imported. They tell you what physical sources a migration must still reach. The table files do not hold the business meaning of those columns, so descriptions, data types and any renamed fields need checking against the warehouse. Confirm the connection details and access rights with your data team before the target tool is pointed at the same objects.
SQL views
SQL views carry hand-written query logic, which means the export preserves the exact statement the platform runs. This logic is portable only when the target database dialect and functions match, so review each statement for vendor-specific functions and date handling. Expect that some views will be better rebuilt as warehouse views owned by the data team rather than as BI objects. Confirm the dialect with your database administrator before you move any statement.
Answers
Answers are saved search questions, and their files record the search tokens, the chosen visualization and the filters that produced a result. Because the tokens are written for ThoughtSpot search, they do not translate directly into SQL or chart configuration in another tool. Treat each Answer as a specification for the chart a user expects to see, then rebuild it from the underlying dataset. Sort the Answers by business use so the rebuild effort goes first to the questions people ask most.
Liveboards
Liveboard files describe the dashboard layout, the visualizations placed on it, the filters that apply across tiles and the order of the tiles. They are the closest match to a dashboard in the target tool, yet grid positions, tile sizes and interactive filter behavior will need manual adjustment. Compare each rebuilt dashboard with the exported layout and filter list, and check that filter defaults match what users saw. Confirm with your stakeholders which Liveboards are still in use before you rebuild them.
Alerts and schedules
Alert and schedule definitions record what condition triggers a notification, who receives it and how often it runs. These settings carry operational risk because a missed alert can go unnoticed after cutover. Most target tools handle scheduled delivery and thresholds differently, so each alert must be rebuilt, tested against known data and assigned an owner. Confirm the recipient list and the delivery channel in your own environment, and keep the old schedule active until the new one has run successfully.
The export sequence and how to verify each stage
This sequence turns ThoughtSpot content into a versioned, checked set of TML files that serves as the specification for the migration. Each stage ends with a verification the team can repeat before any object is rebuilt in another tool.
Inventory every object and its owner
Before exporting anything, list every table, view, model, answer, liveboard and alert in the ThoughtSpot instance that the business still uses, with the named owner of each. The effort here depends mainly on the number of liveboards and the number of owners who must confirm that their content is still needed, so ask owners to mark items as keep, retire or unknown. The step is done when every object has one owner and one disposition, and the inventory has been signed off by the business sponsor for the BI migration.
Export objects in dependency order
Export tables and SQL views first, then models, then answers and liveboards, because each higher-level object refers to the ones below it. Keep the export output in a folder structure that mirrors that order so a reviewer can see which file depends on which. The check is that every exported file opens as valid TML and that no object appears in a later file without its dependency appearing in an earlier one.
Store the TML under version control with a dated tag
Commit the exported TML files to a Git repository that the migration team controls, with one commit per export run and a tag that records the date and the ThoughtSpot instance name. Store alert definitions alongside the rest so they are not forgotten later. The check is that a fresh clone of the tag contains the same file count and the same checksums as the export folder, which confirms that nothing was lost in transfer.
Reconcile object counts against the inventory
Compare the number of files for each object type with the inventory from the first step. Each count should match, except for objects that owners marked as retire, which should be listed separately with a reason. Any object that is in the inventory but missing from the export must be exported again or explained in writing. The step is done when the reconciliation sheet shows zero unexplained differences for each object type.
Open a sample of files and compare them with ThoughtSpot
Choose a sample of models and liveboards that represent the common patterns, such as joins across several tables, calculated columns, and filters that users apply by default. Read the TML for each one and compare the joins, formulas and filters with what the owner sees in ThoughtSpot, recording the result for each object. The check is a written sign-off from the owner that the definition in the file matches the live object, because the TML describes the logic that must be rebuilt in Superset or Metabase.
Record the gaps that must be rebuilt by hand
Log everything the TML does not carry over into a new tool, including search-style question behavior, user-level permissions, row-level security rules and any visual layout that the owner depends on. Assign each gap to an owner and mark it as a rebuild item for the target tool. The check is that every gap has an owner, a target object in the new tool and a test case, so the gap list becomes the acceptance criteria for the migration rather than a surprise at cutover.
Keeping the TML export as the specification for the migration
Treat the TML export as the agreed specification, and freeze it before any rebuild starts. Record a snapshot date, store the files in version control and get the business owners of each Liveboard, Answer, Model and alert to sign off on the set. A ThoughtSpot environment keeps changing while a migration runs, so without a fixed baseline the team cannot tell whether a difference in Superset or Metabase is a migration defect or an edit someone made after the export. Keep the export in a dedicated repository with one commit per export run, and label each run with the ThoughtSpot instance, the date and the person who ran it. Do not assume the export is complete until you have reconciled it against the object inventory you pulled from the platform, and list anything that was skipped or failed to export so it appears on the decision log.
Next to each exported object, keep a decision record with one of three outcomes: kept (rebuilt with the same logic and meaning), simplified (rebuilt with a narrower scope, such as dropping a search-only feature) or retired (not rebuilt, with the reason and the business owner who accepted it). Write the decisions in the same repository as the TML files so reviewers see the object definition and its disposition together. Any object changed in ThoughtSpot after the snapshot date needs a deliberate choice: either re-export it under a new version and record the change, or freeze the old version and state that later edits are out of scope. Check the export's change history with the platform owner before you decide, because a silent edit to a join or formula is the most common reason a rebuilt chart disagrees with the original.
The frozen, versioned archive also serves as evidence. When a stakeholder, internal auditor or external assessor asks what the old system contained, the repository answers with the exact definitions, owners, access context and the recorded decisions, rather than with recollection. Confirm with your compliance lead which retention period and access controls apply to the archive, since the TML files may describe sensitive table names, filters and row-level logic. Keep the archive read-only after cutover, and note in its README which assumptions were confirmed by the business and which remain open, so the record shows what was verified and what was not.
What does not come out in a TML export and how to cover each gap
A TML export describes the metadata of your ThoughtSpot content, not everything that makes it work. The gaps below sit outside the files, so each one needs its own inventory before you cut over. Confirm each item against the ThoughtSpot documentation for your release before you rely on it.
Warehouse data and cached results
TML describes the models, tables and joins that point at your warehouse, but it does not carry the rows behind them or any cached results. Every dashboard in the new tool will show nothing until its source is connected and loaded. Extract the data your content needs directly from the warehouse, using the warehouse's own export tools, and load it into the database that Superset or Metabase will query. Before you archive the export, list which tables, schemas and connections each Liveboard depends on.
User accounts and group membership
Account records, group membership and role assignments belong to your identity setup more than to the content. Do not assume the export includes them: confirm before you assume, and ask ThoughtSpot which records appear in the TML files and which need a separate export. Ask your administrator for a written inventory of users, groups, roles and the service accounts used by embedded apps. Then map each group to a role in the target tool, such as the role mapping Superset supports through AUTH_ROLES_MAPPING.
Row-level security and sharing grants
Sharing settings and row-level rules decide who sees which records in a Liveboard, and they can sit outside the object definitions you export. Check whether the export covers sharing and data security rules for each object, and record every rule it leaves out. Where a rule is missing, write it again as a filter in the target tool and test it with a user from each group. Metabase limits row and column level permissions to its paid Pro and Enterprise plans, so confirm that cost before you depend on them.
Search usage and natural-language queries
The questions business users type into search are not content objects, so they do not appear in a TML file. The history of which questions people asked is a separate record that you need to request from the administrator. Collect a written list of search-style questions that matter most, grouped by team, with the answer each should return. Recreate each one as a Superset chart or a Metabase question, and check the results against the same source figures. Tell users early that free-text search does not carry over automatically.
Runtime embedding configuration
Embedded Liveboards and Answers depend on settings in the host application, such as the allowed embed domains, the authentication method and the logic that signs users in. These settings typically live in the host app's code and configuration, not in the content definitions you export. Document each embed point, the host page it sits on and the identity it uses, then rebuild the same flow against the target's embedding model. Compare the target's embedding options with your current setup before you commit to a design.
Content outside the export scope
Some items attached to your content may fall outside the objects you export, such as schedules, delivery recipients, comments, favorites, tags and ownership. Confirm the full list with ThoughtSpot for your release, then record each item in the inventory with its owner. Check alert thresholds and delivery channels against the export, since alerts need their own review. Superset runs alerts and reports on a caching layer with Celery workers, so plan that infrastructure before you move any scheduled delivery.
What still has to be rebuilt by hand in Apache Superset or Metabase
In Superset, TML Models map most closely to datasets, which hold the physical table or SQL definition, column metadata and saved metrics. TML Answers become charts and Liveboards become dashboards. The export describes what each object contains, but it does not describe the layout you want, so joins, calculated logic and security still need deliberate design.
- Datasets from Models: Recreate each Model's tables and columns as Superset datasets on a database connection. Use the TML joins as a checklist, and confirm that the relationships produce the same row counts in the warehouse.
- Calculated fields: Rewrite ThoughtSpot formulas as SQL expressions in the dataset or as saved metrics. Test each one against the warehouse, because function behavior can differ between SQL dialects.
- Charts and dashboards: Rebuild Answers as charts and Liveboards as dashboards by hand, including tile sizes, filters and ordering. Use the exported names so reviewers can trace each chart back to its source.
- Row-level rules: Translate the security rules in the export into Superset's row-level security, and map LDAP or OAuth groups to roles with AUTH_ROLES_MAPPING. Test with one account per group before sharing content.
- Prerequisites: Choose PostgreSQL or MySQL as the metadata database for production, set a SECRET_KEY, and decide on the authentication method before building. Your identity team should approve the group-to-role plan first.
Before work starts, confirm which metadata database version your platform team will support and who owns the authentication configuration.
In Metabase, TML Models map to Metabase models, which are saved queries that other questions can build on, and metrics are defined on those models. Answers become saved questions and Liveboards become dashboards with filters. Metabase's query builder covers many common questions without SQL, but complex formulas and some joins are easier to keep in native SQL.
- Models and metrics: Recreate each TML Model as a Metabase model and define its metrics there. Check joins for fan-out, because a join that duplicates rows will inflate totals in a metric.
- Saved questions and dashboards: Rebuild Answers as saved questions and Liveboards as dashboards, mapping filters to dashboard parameters. Arrange tiles by hand, since the export does not carry your intended layout.
- Calculated logic: Move formulas into custom expressions where the query builder can express them, or into SQL-backed models where it cannot. Store SQL models in version control so changes are reviewed.
- Permissions and SSO: Row and column level permissions and SSO require the Pro or Enterprise plan, and the Open Source and Starter plans do not include them. Choose the plan before you build secured content, since group sync through JWT, OIDC or SAML also requires Pro or Enterprise.
- Application database: Use PostgreSQL or MySQL for production instead of the embedded H2 database, which is meant for demos. If a test instance already holds data in H2, migrate it with the load-from-h2 command using the Metabase version that last wrote the file.
Before migration, confirm with Metabase which plan includes the permissions your data owners require and document it in your rollout plan.
ThoughtSpot's search lets users type a business phrase and receive a generated answer. The TML export carries the objects behind those answers but not the habit of asking questions this way, so neither Superset nor Metabase will reproduce search from the export alone. Plan a replacement for the questions users depend on, and treat the change as a user-facing project rather than a data task.
- Inventory the questions: Use the exported Answers and your own review of ThoughtSpot usage to list the questions people ask most often, grouped by business purpose. Each group becomes a dashboard, a saved question or a self-service path.
- Pre-built dashboards: Replace frequent lookups with dashboards that have filters for the fields users typed into search. Keep filter names identical to the business terms they used before.
- Self-service paths: Point analysts to Superset's chart builder and SQL Lab, and point business users to Metabase's query builder if that is your target. Confirm which tool your users can operate without help.
- Shared vocabulary: Align the names of metrics and fields with the terms users already use, and publish a short guide that maps old phrases to new locations.
- Pilot and expectations: Run a pilot with a small group of business users, and tell everyone which behaviors change during the first weeks of cutover.
Before cutover, ask each business owner to sign off on the replacement list so no common question is left without an answer.
What to plan before the ThoughtSpot contract renews or ends
The TML export is only useful if it is finished, owned and archived before access ends. The cards below cover the decisions that determine whether the export becomes a reliable specification for the migration or a rushed file dump.
Set the export deadline from the contract
Work backward from the date your ThoughtSpot access ends, not from the date you plan to switch tools. Confirm in your contract and order form what notice period applies to renewal or termination, and whether read access to Liveboards and Answers continues after the subscription lapses. Treat the contract end date as the hard deadline and schedule the full export, review and archive steps well before it.
Assign one owner and one sign-off
Name a single person accountable for running the TML export and a separate reviewer who signs off that it is complete. Without a named owner, exports tend to cover the objects an analyst remembers and miss alerts, Views or Liveboards owned by former staff. The sign-off should compare the export inventory against a list of Liveboards and Answers that business owners have confirmed in writing.
Decide whether a parallel run is needed
Decide early whether Liveboards and Answers must run side by side with the replacement for a period. A parallel run lets finance, operations or regulatory reporting teams compare numbers from the TML-derived rebuild with what ThoughtSpot returns for the same questions. Confirm with those teams which reports must match exactly and which only need to be directionally consistent, because that choice drives how long ThoughtSpot access must stay open.
Control residency and retention of the archive
TML files describe your data model, joins, formulas and sharing structure, so they are sensitive even though they hold no table rows. Decide where the exported archive is stored, who can read it and how long it is kept, and align that with your data residency and records policies. Store the archive in your own repository or object storage, and confirm that copies on laptops or shared drives are removed once the migration is signed off.
Tell the vendor which terms affect export access
Identify the contract terms that govern your ability to export, such as whether API access, the metadata export feature or the read-only period is included in your subscription tier. Send these questions to your ThoughtSpot account contact in writing and keep the answers with the contract file. Ask specifically whether export access changes after the end date and whether any export feature is restricted by edition, so the migration plan does not rely on assumptions.
Put the exit questions to ThoughtSpot in writing
Before termination, send a written list covering the points your team cannot verify on its own. Include: the last date of full access, whether TML export is available for every object type in use, how Models and Liveboards owned by deactivated users are handled, whether data is deleted on termination and on what schedule, and how deletion is confirmed. Keep a dated record of each answer, because it becomes the evidence that the exit was controlled.
Questions buyers ask before exporting ThoughtSpot content
How much effort does a full ThoughtSpot export and rebuild take?
The effort depends mostly on the number of objects to rebuild, not on the export itself, which is a file-level step. Count your Models, Views, SQL views, Tables, Answers, Liveboards and alerts first, then note how many of them carry custom formulas, parameters, or row-level logic. Each of those needs a manual translation into Superset datasets and charts or Metabase models and metrics, and each alert and schedule needs to be recreated and tested. Ask any partner to base the estimate on that inventory rather than on a headline number.
Can our own team run the TML export without outside help?
Yes, the export itself is a file-level task that an administrator or content owner with the right access can perform. Someone needs to list the objects in scope, export their TML, and store the files in version control with a clear record of what was exported and when. The harder part is judging whether each file is complete and correct, because TML describes the object definitions but not every downstream dependency. Teams without anyone who knows both ThoughtSpot and the target tool usually benefit from an outside review of the inventory before rebuilding begins.
What do business owners and data engineers need to contribute?
Business owners decide which Liveboards and Answers still matter, confirm the metric definitions, and approve how each dashboard should behave for their users. Data engineers confirm the source tables, joins, data types, refresh schedules and permissions that the exported Models depend on. Without these two inputs, a rebuilt dashboard can look correct and still answer a different question. Schedule their time before the rebuild starts, because waiting for sign-off is a common cause of delay.
Do we need a consultant for the rebuild, and what should a written scope include?
A consultant is optional, but a rebuild across many owners and data sources usually benefits from someone who has done similar moves. DeployOpen plans, implements and documents self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. A quote should list the exported object types in scope, the target tool and version, the number of dashboards and alerts to rebuild, data source connections, user access mapping, testing and handover. Ask for exclusions in writing as well, such as objects you plan to retire.
What should we do when a TML export is incomplete for an object?
First, record which object and which fields are missing, then check whether the gap comes from the export scope, the object type, or the permissions of the account that ran the export. Rebuild the missing part from the live ThoughtSpot object with a named owner, and mark the decision in your migration log. Do not assume the target tool will infer a formula or join that the file does not state. Where a feature has no equivalent in the target tool, record the gap as a known difference and agree how users will be told before cutover.
Can the TML export serve as evidence for an audit or a migration record?
The export can serve as a dated record of how dashboards, models and alerts were defined at the point you left the platform, which is useful for change records and for reviewing what changed during migration. Store the files in version control with access controls, a hash or commit reference, and a note of the ThoughtSpot environment and export date. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors decide whether that evidence meets your requirements. Confirm retention periods and format expectations with your auditor and your own compliance team before you rely on it.
How DeployOpen scopes and delivers a ThoughtSpot export and exit
DeployOpen treats the TML export as the specification for the exit, then plans, implements and documents the move to self-hosted open-source BI inside your own infrastructure. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory which Models, Views, Tables, Answers, Liveboards and alerts are in scope for the export
- Agree in writing which TML files will be exported, stored and treated as the migration specification
- Identify which objects must be rebuilt by hand in Superset or Metabase and record them as deliverables
- Confirm the target platform, hosting location and who in your organization owns sign-off
How we build
- Run TML exports and check each file for joins, formulas, column definitions and filters
- Stand up the chosen self-hosted platform with a PostgreSQL or MySQL metadata database in your environment
- Recreate datasets, charts or dashboards from the exported specification and test them against source data
- Configure authentication and role mapping to match the access rules your users have today
How we hand over
- Deliver a mapping document linking each ThoughtSpot object to its replacement or to a documented gap
- Provide runbooks for deployment, backup of the metadata database and the upgrade procedure
- Store exported TML files in a version-controlled location you control, with a retention note
- Walk your team through the gaps, such as search-style questions, so expectations are set before cutover
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainer scope, response expectations and upgrade cadence are agreed in writing, not assumed
- Upgrade work follows your staging tests and the platform's documented upgrade steps
- Quotes follow from the written scope, so ask for line items covering export, rebuild, testing and handover
