Export QuickSight dashboards and datasets

How to export your dashboards and datasets from Amazon QuickSight in one pass

If a renewal, a pricing change or an exit decision has you moving off Amazon QuickSight, start by confirming what the export can and cannot give you. Asset bundle export jobs produce definitions of dashboards, analyses and datasets, in either Quick Sight JSON or CloudFormation form, but they do not carry the underlying data. The bundle describes what each visual queries, how calculated fields are written, how filters and parameters are set and how sheets are laid out. It is a record of the design, which is the part you would otherwise rebuild by hand. Plan for a second inventory alongside it, because the data source connection details that the APIs skip must be captured by someone who knows the accounts, warehouses and owners behind them.

The bundle works as a rebuild specification for Apache Superset or Metabase, and it will not import directly into either. Each target has its own model for datasets, charts, filters and permissions, so the exported definitions become a checklist. For each dataset, record the physical table or SQL it reads and the joins it depends on. For each analysis, record the fields, aggregations and filters it uses. Sharing settings and user or group assignments do not map one to one, so document who can see each dashboard before you export. SPICE contents are not in the bundle, so the target must query the source database directly or use its own caching layer. Confirm the current asset types, export formats and limits in AWS documentation, and test one dashboard export in your own account before you commit to a timeline.

Before you start, assign ownership. An administrator with access to the QuickSight account runs the export jobs, and a data owner confirms which datasets still matter, since a bundle built from stale assets carries stale logic into the new stack. Decide early which dashboards are retired, which are rebuilt in Superset and which are rebuilt in Metabase. That choice matters because Metabase's SSO and row-level permissions depend on the plan tier you buy, so the access model you need should drive the platform decision. Store each exported bundle in version control with dated copies, so the specification survives account changes and you can compare the rebuilt dashboards against the original after each step.

What the Amazon QuickSight export job gives you

This table lists the QuickSight asset types an asset bundle export can carry, the method and format for each, and what to check before you rely on the bundle. Treat it as a rebuild specification, not a backup of the data, and confirm the exact asset list and quotas in AWS documentation for your account and Region.

Asset type	Export method	Format	What to check
Dashboards	Asset bundle export job, started from the console or the API	QuickSight JSON or CloudFormation definitions	Confirm that each published dashboard version you need is included, and note which sheets, filters and parameters the definition captures
Analyses	Asset bundle export job, started from the console or the API	QuickSight JSON or CloudFormation definitions	Check whether unpublished analyses are included, since a dashboard definition may not reproduce draft work
Datasets	Asset bundle export job, started from the console or the API	QuickSight JSON or CloudFormation definitions	Review the logical table definitions, joins, calculated fields and any SQL or custom queries, because the bundle describes these but does not carry the rows
Data sources and connection details	Confirm with AWS whether the bundle includes them, and record connection settings separately	Definitions in the bundle, with credentials handled separately	Credentials and secrets are not something you should expect the bundle to hand over, so plan to recreate connections in your new tool
Themes, folders and other definitions	Asset bundle export job, started from the console or the API	QuickSight JSON or CloudFormation definitions	Confirm the exact list of included asset types in AWS documentation, and check how permissions and sharing are represented
Row-level security and permission rules	Review the dataset and permission definitions in the bundle	QuickSight JSON or CloudFormation definitions	Verify each rule against the source data, because the rule logic must be rebuilt in the target tool
Underlying data and SPICE contents	Not exported by the bundle; extract from the source systems instead	Not applicable in the bundle	Plan a separate data extract or direct connection, and confirm any export limits for your account and bundle size with AWS
Quotas and bundle size	Check your account settings and AWS documentation before planning the export	Not applicable	Confirm quotas for your account and bundle size, and test a full export in a non-production account first

What the bundle leaves out and how to recover each item

An asset bundle describes the design of your QuickSight content, but it leaves out the data, connection credentials, SPICE copies and access rules around that design. Each item needs its own inventory, owner and recovery step before a dashboard in another tool shows the same numbers.

The data itself

The bundle describes dashboards, analyses and datasets, but it does not copy the rows behind them. Rebuild the data in the target tool by pointing it at the same source databases or warehouses, using the dataset definitions in the bundle as a guide. Confirm with each data owner which system is authoritative and whether historical snapshots matter, because a fresh query returns only what the source holds today. Compare row counts and key totals against QuickSight before you retire anything.

Data source connections and credentials

The export APIs skip data source connection details, including hosts, ports, database names, schemas, the roles each connection runs as and the places where passwords are stored. Build a separate inventory before cutover and record where each secret lives. Store credentials in a secrets manager, not in dashboard exports, and set Superset's SECRET_KEY as a deployment secret so it stays out of code. Confirm that each service account has read-only access before the target tool connects.

SPICE contents

SPICE holds imported copies of data inside QuickSight, and those copies and their refresh schedules are not part of the bundle. A dataset that depended on SPICE will not produce its numbers until the target tool reads the source tables directly or through its own cache. Reload every dataset from source in the target tool, then compare results with the QuickSight figures. Export any calculated fields and refresh timing from the dataset definitions so the logic moves with the data.

Users, groups and reader permissions

Reader groups, folder sharing and per-user permissions live in QuickSight and in your identity provider, and the bundle does not give you a usable access map. Export group membership from the identity provider or the QuickSight admin console, and list which groups can see which dashboards. In Superset, map identity provider groups to roles with AUTH_ROLES_MAPPING. In Metabase, SSO and row-level permissions require the Pro or Enterprise plan, so confirm that licensing before you design access.

Export sequence and verification for a complete handoff

This sequence turns a QuickSight estate into a controlled export package: a complete inventory, versioned asset bundles, documented connections and access, and checks that prove nothing was missed. Each step names the artifact it produces so the package can be signed off before any rebuild starts.

Inventory dashboards, analyses and datasets
Start by listing every dashboard, analysis and dataset in each QuickSight account and region in scope, recording the asset ID, display name, business owner and technical owner. Ask the business owner to confirm which dashboards are still in use, because unused assets are cheaper to retire than to rebuild. The output is a single inventory file that becomes the baseline for every later count. The step is done when each asset has exactly one named owner and the inventory has been reviewed by the people who requested the migration.
Run asset bundle export jobs and version them
Run an asset bundle export job for each scope you defined, choosing the option that includes the dashboards, analyses, datasets and themes you need. Store each resulting bundle in a Git repository with branch protection and access limited to the migration team, so changes are tracked and the bundles are not copied to personal drives. The platform engineer who runs the job records the job ID and the date in the inventory. The step is done when every bundle is committed to version control and the job IDs match the scopes in the inventory.
Record connections, refresh schedules and SPICE usage
Document each data source connection, including its type, host or endpoint, the database or warehouse it reads, and the credential owner, but never store secret values in the repository. Capture the refresh schedules for SPICE datasets and the current SPICE capacity in use, since the bundle does not carry the underlying rows. The data platform owner should confirm which sources the bundle skips and how each will be reconnected from the new BI tool. The step is done when every dataset in the inventory maps to a documented connection and a refresh schedule or a note that it is queried live.
Export or document user and group mappings
Export the list of QuickSight users, groups and their dashboard permissions through the administration console or the APIs, and record which group grants access to which asset. Identity owners should map each QuickSight group to the group the new tool will use, whether that comes from an identity provider or a local directory. Row-level security rules and their dataset attachments also need to be listed here, because they are part of the access model. The step is done when every group has a target group and every row-level rule has a documented equivalent or an open question assigned to a named person.
Verify bundles against the inventory
Open each bundle file and confirm it is readable, then count the dashboards, analyses and datasets it contains and compare those counts with the inventory. The security or data engineering owner should check that every dataset references a data source already recorded in the connections document, and flag any reference to an unknown source. Any mismatch goes back to the export owner for a re-run with the same scope. The step is done when each count matches the inventory and every dataset resolves to a documented source, with the verifier's name and date recorded beside each scope.
Sign off and store the export package
Assemble the inventory, bundles, connection record, group mappings and verification log into one export package, then store it in a restricted repository or archive that matches your data classification policy. The accountable owner for the BI program reviews the package and signs off on the scope, listing any assets intentionally retired and the reason. Retain the package until the migration is closed, because it is the reference used to answer questions about what the old system did. The step is done when the signed-off package is stored and the sign-off record names each owner.

Why the data itself is not exported and what that means for the rebuild

An asset bundle carries definitions, not rows, so the source system of record stays the only trusted copy of your data after the move. The bundle describes dashboards, analyses and datasets: their fields, calculated columns, filters, visual settings and the parameters that connect them. It does not contain the query results or the data that backs them. That means every rebuilt dashboard in Superset or Metabase has to read from the warehouse, database or file store that already holds the authoritative figures. Before you start, record which system owns each metric, confirm that your reconciliation queries return the same totals in the new tool, and treat the QuickSight numbers as a comparison check rather than as a source to copy from.

Datasets that use SPICE need a different plan. SPICE is QuickSight's in-memory store, and its contents are not part of the export, so each SPICE-backed dataset must be reloaded from its original sources in the new tool. Map each one to its upstream table or query, decide whether it will be queried live or cached, and set a refresh schedule that matches the freshness your readers expect. Datasets built on direct queries are simpler to move, but they still depend on the connection details behind them: the host, port, database name, schema, service account and network path. Those details are not secrets that the bundle hands over, so you must re-enter them, create new credentials in the target tool, and confirm that the target can reach the source through your firewall and VPC rules. Confirm current behavior before you plan the cutover. Export, refresh and caching behavior for SPICE and related features can change, so check the current AWS documentation for QuickSight asset bundles and SPICE rather than relying on what this page describes. Ask your AWS account team or review the service documentation for the exact export scope, and test one representative dataset end to end in staging. Record the results, including refresh duration and any differences in calculated fields, so the cutover decision rests on evidence from your own environment.

Choosing between JSON and CloudFormation output by team

Platform engineers usually treat the export as source material for a repository. They commit the JSON or CloudFormation output to Git, review changes as diffs and keep a history of each dashboard definition. For this team the question is whether the files are stable enough to diff and whether they hold enough structure to drive a rebuild.

Diff stability: Export an unchanged dashboard twice and confirm the files match, so later diffs reflect edits and not reordering or regenerated identifiers.
Dataset references: Record which dataset identifiers each analysis points to, because those links determine which tables or queries must exist in Superset or Metabase first.
Calculated field expressions: Keep each expression with its dataset scope so the team can translate it into SQL, a Superset metric or a Metabase custom expression.
Filter scopes: Note which controls apply to which sheets and visuals, since a filter scoped to one sheet behaves differently once it is rebuilt as a dashboard-wide filter.
Credential exposure: Confirm that data source credentials are absent from the files before anything is committed to shared version control.

Before relying on the files, validate them with your own tooling and confirm with AWS documentation or your account team exactly which asset types the bundle contains, because the data itself is not exported.

Using the bundle as a rebuild specification for Superset or Metabase

Treat the bundle as a specification, not as an import file. Each dataset definition tells you the source, the columns, any joins or custom SQL, and the calculated fields and filters applied to it. Record these in a mapping sheet before anyone builds anything. In Apache Superset, a dataset sits on a database connection, and calculated fields usually become metrics or calculated columns. In Metabase, a reusable base query is saved as a model, and each visual becomes a question built on that model. Read each visual type in the bundle and note its nearest equivalent in the target tool. Where no equivalent exists, write that gap down so the team can decide whether to redesign the view or drop it. Confirm the exact field names in your own bundle files, since they vary with how the assets were created.

Neither tool inherits connections or credentials from QuickSight, so the team must recreate them. Superset reaches SQL sources through a Python DB-API driver and a SQLAlchemy dialect, which means the driver for your warehouse must be installed in the Superset environment and the connection string rebuilt with the new service account. Metabase has its own database connection setup, with its own choices for authentication, SSL and sync behavior. For each source, document the network path, the account, the secret store location and the TLS settings, and test them in a non-production instance first. Connection work is often the longest single item in the rebuild, so schedule it before dashboard layout work begins.

Row-level rules are the highest-risk part of the rebuild, and they must be rebuilt rather than copied. Identify which dataset carries each rule and which users or groups it binds to, then express the same logic in the target tool. The mechanism depends on the identity setup you choose: Superset maps OAuth or LDAP groups to roles, and its row-level security rules attach to those roles, while Metabase's row-level permissions depend on the plan you buy, as described on the Metabase pricing page. Test each rule with accounts from every group and compare the rows returned against the QuickSight result for the same user. For the step-by-step rebuild, follow the sibling migration pages for Superset and Metabase.

What to plan before the Amazon QuickSight contract ends

Exporting QuickSight content is a planning task that starts well before the contract ends. The four items below cover the work that depends on time, access and documentation, and they all feed into the asset bundle export described on this page. Ending dates and notice periods come from your own agreement, so confirm them with AWS or your reseller before setting any of these dates.

Start the export inventory early

List every dashboard, analysis, dataset and theme you rely on, then run an asset bundle export of a representative set well before the decision date. Test the bundle by importing it into a scratch account or reviewing its JSON, and record which items export cleanly and which need manual rebuilding. Plan for at least one full renewal cycle so that a failed export does not coincide with the cutoff. Ask your AWS account team which export options apply to your edition and region.

Document source connections outside QuickSight

Asset bundles describe datasets and their SQL, but they do not carry the working connection details, credentials or network paths your sources need. Write down each data source, its host, database name, schema, driver, authentication method and the VPC or network route used to reach it. Store this record in your own configuration repository and secrets manager, not inside QuickSight. This record becomes the first input when you reconnect Apache Superset or Metabase directly to the same warehouses.

Confirm AWS access and offboarding

Identify which IAM roles and users can run exports, read QuickSight assets and manage data sources, and confirm which of them are tied to named individuals. Export jobs and API calls depend on these permissions, so check them before access is reduced. Remove access for people leaving the project and record who holds the root and administrative credentials. Keep the export and migration work under a named owner until the last bundle is archived.

Set a read-only comparison period

Freeze new dashboard edits in QuickSight for a defined window while the rebuilt dashboards run in parallel. During this period, have business owners compare figures, filters, row-level results and scheduled outputs side by side, and log every difference. Treat differences in row-level access and date handling as the highest priority, since they affect who sees what. Keep the QuickSight content available until both sides agree and the exported bundles are archived.

Questions teams ask before exporting from Amazon QuickSight

How much effort does a complete QuickSight export take?

Effort depends on the size and complexity of the estate, not on a single fixed amount. The main drivers are the number of dashboards, analyses and datasets, how many custom calculated fields and parameters each one uses, how many datasets are SPICE datasets that need separate handling, how many data sources sit behind them, and how complicated the permissions are across folders, users and groups. A small estate with a few dashboards on one warehouse is a short exercise. A large estate with shared datasets, many row-level rules and undocumented calculations takes longer, mostly in reading and checking the output rather than in running the export job itself. Ask any provider for an inventory of assets before agreeing a price, because the inventory is what sizes the work.

Can one person in our team run the export internally?

Yes, for a small estate where each dashboard has a clear owner and the source databases are documented. The export itself uses AWS asset bundle jobs, which can be started from the console or the AWS CLI. The harder part is interpreting the output: someone needs to read the JSON or CloudFormation definitions, match datasets to their SQL or physical tables, and understand each calculated field. That calls for AWS console or CLI experience, comfort reading JSON, and enough SQL to confirm what each dataset returns. Larger estates usually benefit from two people, one who knows the AWS side and one who knows the business logic and the warehouse.

What do we need to provide for an export engagement?

The work depends on access and on knowledge the bundle does not contain. Expect to provide read access to the QuickSight account and the relevant AWS accounts, and the ability to run asset bundle jobs. Source database documentation matters because the bundle describes datasets but not the data behind them. Each dashboard needs a named business owner who can confirm what it is for and who uses it. Finally, the inventory of assets should be reviewed and signed off by your team before rebuild work starts, so that nothing is missed and nothing out of scope is migrated.

Can we import the QuickSight bundle directly into Superset or Metabase?

No. The asset bundle is a specification of QuickSight objects, written in QuickSight's own JSON or CloudFormation format. Apache Superset and Metabase do not read it, and the bundle does not contain the underlying data. Its value is as a rebuild specification: it documents each dataset's source and joins, each calculated field, each visual and each filter, so the team can recreate them in the target tool. The data stays where it is, and Superset or Metabase connect to the same SQL sources directly. Plan for manual rebuilding of charts, dashboards and row-level rules in the target tool.

How long does verification take, and what drives it?

Verification time depends on how many outputs must match the original and how strict the acceptance criteria are. Each rebuilt dashboard should be compared with the QuickSight version on the same data, using agreed filters and date ranges, and each calculated field should be checked against its original expression. Time grows with the number of dashboards, the number of distinct calculations, the number of users who rely on exact figures, and how many row-level rules must be proven to restrict data correctly. Ask for the verification method and acceptance criteria in writing, so that you know what counts as a match before the work begins.

What should a consultant quote include for an export?

A useful quote follows from a written scope and does not stand alone as a single number. It should list the scope with the AWS accounts, QuickSight objects and data sources covered, and state what is out of scope. It should include an inventory of assets with each dashboard, analysis and dataset, its owner and its source, so you can see what the price covers. Deliverables should be named, such as the exported bundles, the asset register, the rebuild specification and the verification report. It should also state who is responsible for access, sign-off and acceptance, and the assumptions behind the timeline. DeployOpen works from a written scope and agreed deliverables, and does not publish a price list, so a quote follows from that scope.

How DeployOpen scopes and delivers a QuickSight export and exit

DeployOpen approaches a QuickSight export as a fixed-scope engagement inside your own AWS accounts or chosen environment. The work starts with an inventory of what the bundle can and cannot carry, then turns the exported definitions into a rebuild specification for a self-hosted tool such as Apache Superset or Metabase.

How we scope

Inventory of dashboards, analyses, datasets, themes and data sources in the QuickSight accounts in scope
Written list of what asset bundle exports cover and which sources, permissions and SPICE contents fall outside them
Agreed deliverables, timeline and handling of data access, written down before any work starts
Confirmation of target tool, hosting location and which readers, groups and row-level rules must be reproduced

How we build

Run bundle export jobs and store the JSON or CloudFormation definitions under version control in your environment
Map each dataset to a direct SQL connection in the target tool and document where caching replaces SPICE
Rebuild dashboards from the definitions and test results against the source queries in a staging instance
Check permission mappings and row-level rules against the original access model before any cutover

How we hand over

Written rebuild specification covering each asset, its source query, filters and calculated fields
Gap register listing items the bundle did not carry, with the manual steps needed to recreate them
Runbooks for the target platform, including backup of its metadata database and upgrade steps
Training for the owners who will maintain dashboards, data connections and user access after handover

How we support

Engagements are fixed-scope, so scope changes are agreed in writing before additional work begins
Ongoing support, platform upgrades and continuous testing are available as a retainer after handover
Compliance evidence for access controls and data handling can be prepared, though independent auditors issue any attestation
Ask in any quote which environments, data volumes and user groups are included in the written scope

How to export your dashboards and datasets from Amazon QuickSight