How to export your dashboards from Sisense starts with an inventory, not a download
A renewal, a pricing change, a residency requirement or lock-in is forcing the move off Sisense, and the first instinct is to export dashboards from the Analytics page and start rebuilding. Dashboards can be exported as .dash files, but that file is only one part of what must be rebuilt in another tool. Before you export anything, treat the migration as an inventory project: list every dashboard, every data model and every access rule the deployment depends on, then decide what each item becomes in the target platform.
The .dash file is a starting point for widgets, filters and layout, but the supplied facts do not describe its full contents, so confirm exactly what your Sisense version writes into it. Two areas are commonly outside the file and need separate records: sharing settings, which determine who sees each dashboard, and BloX custom actions, which carry behavior you will have to re-specify by hand. Document both for every dashboard before you start the rebuild, and note which dashboards use them.
ElastiCube data models and data security rules are the most consequential gap, because dashboards are only as useful as the data and permissions behind them. Record each ElastiCube, its source tables, refresh schedule and calculated fields, and record every data security rule that filters rows or columns by user or group. Ask your Sisense administrator or check the Sisense documentation for your version to confirm the export and backup options for each of these, then map the results to warehouse tables and the target platform's permissions. Treat the inventory as the deliverable that tells you what the rebuild must cover.
What Sisense lets you export, and in which format
This table lists each item a Sisense administrator may need to carry into a new BI tool, how Sisense exports it, and the limits to confirm before you start. Rows marked as not included belong on your manual inventory list. Widget and filter definitions travel inside the .dash file, while sharing settings, BloX custom actions and the data model need separate records.
| Data type | Export method | Format | Limits |
|---|---|---|---|
| Single dashboard | Analytics page, export one dashboard | .dash file | Confirm the maximum file size for your Sisense version with support |
| Batch of dashboards | Analytics page, select several dashboards and export together | One .dash file per dashboard, to be confirmed in a test export | Confirm any batch count or size cap with Sisense support |
| Widget and filter definitions | Included inside each dashboard's .dash file | Definitions stored within the .dash file | Run a test export and check every widget and filter type appears |
| BloX custom actions | Not included in the .dash export | Document separately, such as screenshots and code copies | Ask Sisense support whether any export path exists for your version |
| Sharing and dashboard permissions | Not included in the .dash export | Record from the admin areas | List every share before migrating, since the export omits it |
| ElastiCube models | Inventory from the admin areas, export path to confirm | Confirm the supported export format with Sisense | Record source tables, joins, transformations and refresh settings |
| Data security rules | Listed or downloaded from the admin areas, to confirm | Confirm the format with Sisense support | Record each row-level rule and the groups it applies to |
| Users, groups and roles | Listed or downloaded from the admin areas, to confirm | Confirm the format and whether group membership is included | Compare the list with your identity provider before import |
| Data source connections | Listed from the admin areas | Record connection type and host only | Stored credentials are not part of the export, so plan re-entry |
What a .dash export leaves out, and how to recover each part
A .dash file carries dashboard layout, widgets and filters, but several things that make a Sisense deployment work sit outside it. Each card below names one gap, the place you must capture it from, and a recovery path that relies only on documented exports or manual rebuilding.
Sharing settings and access
Who can see or edit a dashboard is held in the Sisense admin and sharing configuration, not in the dashboard file itself. Before you export, record every dashboard's owner, shared users and groups, and whether it is shared publicly or through a link. Capture this from the admin console or by screenshot, then map each entry to a group or role in the target tool. Expect the list to be longer than you remember, especially for dashboards shared with a single team.
BloX custom actions
BloX widgets and the custom actions attached to them contain front-end code and configuration that a .dash export does not reproduce as working behavior in another product. Locate every dashboard that uses BloX, read the code from your source repository or the Sisense project files, and list each action with its trigger and the outcome it produces. Plan to rebuild these in Superset or Metabase as native filters, drill-downs or links, and test each one with the same data.
ElastiCube models and build logic
An ElastiCube is a data model with its own tables, joins, calculated columns and build schedule, and a dashboard depends on it rather than on the warehouse directly. Inventory each cube from the Sisense admin console: source connections, table relationships, calculated fields, and refresh settings. Then decide which logic moves into SQL views or warehouse tables that Superset or Metabase queries, because the cube itself does not transfer.
Data security rules
Row-level and column-level restrictions that Sisense applies through data security rules control what each user sees, and a plain dashboard export drops them. Export the rule list from the admin console, record the user or group, the table, the filter condition and the columns hidden. In the target tool, enforce the same restrictions in the database or through row-level permissions where your plan supports them, and verify with test accounts before cutover.
Scheduled reports and alerts
Scheduled email reports and threshold alerts run on the Sisense server and are configured separately from each dashboard. Export nothing automatically for these: list each schedule with its recipients, frequency, format and condition from the admin console, and note which ones your business still depends on. Recreate them in the target tool and run both systems in parallel for a reporting cycle so recipients can confirm the output matches.
Embedded dashboards and host tokens
Dashboards embedded in another application authenticate through tokens or iframe settings issued by the host app, which means the host code, not the dashboard file, controls access. Locate each embedding point in your application source, record how tokens are generated and which user attributes they carry, and document the iframe or SDK parameters. Rebuilding the embed requires new token logic in the host, so treat it as application work with its own testing.
The sequence for a complete Sisense export
This sequence turns a live Sisense estate into a frozen, checksummed set of dashboard files plus an inventory of the data sources, sharing rules and security settings that the files do not carry. Each step ends with a check you can repeat, so the rebuild in another tool starts from a verified baseline.
Freeze the dashboard inventory
The BI owner or a delegated analyst lists every dashboard in scope, with its folder, business owner, last-modified date and status, and marks any dashboards that are retired or duplicated. Agree the list in writing with the business owners and set a cut-off date after which edits are logged. The step is done when the list is signed off and a second person can reproduce it from the Sisense content listing. Changes after the cut-off go into a change log so the rebuild can account for them.
Confirm version and admin access
The Sisense administrator records the exact product version and deployment type (SaaS, dedicated cloud or on-premises Kubernetes), then confirms that the export account can reach the Analytics page and the admin areas that hold sharing and security settings. Check the export options in the documentation for that version, since behavior can differ between releases. Run one test export on a low-risk dashboard. The step is done when that test file is produced and the version details are saved with the project record.
Export dashboards in batches
Using the documented export path on the Analytics page, the administrator exports single dashboards or small batches as .dash files. Name each file with the dashboard identifier and export date so it can be matched to the inventory. Keep the export log that Sisense produces or a manual log of what was exported and when. The step is done when every dashboard on the frozen list has a file or a recorded reason for exclusion. Gaps go back to the inventory before moving on.
Store files with checksums
The team copies the .dash files into a controlled, access-logged location and generates SHA-256 checksums with a tool such as sha256sum. It writes a manifest that lists each file name, dashboard identifier, size, checksum, exporter and date. The step is done when a second person recomputes the checksums from the stored copies and every value matches the manifest. Any mismatch means the file is re-exported and the old copy is retained for the record.
Record ElastiCubes and data connections
For each dashboard, the analyst records which ElastiCubes, live data connections and source tables it depends on, along with refresh schedules and any calculated fields that reference them. The .dash file references these models, but the inventory must describe what each one contains so the warehouse tables or query sources can be identified in the new tool. The step is done when every data source named in the exported dashboards maps to an inventory row and the data owner has confirmed the source.
Capture sharing and data security settings
The administrator documents what the .dash export leaves out: sharing settings, user and group permissions, data security rules and BloX custom actions. Record these from the admin areas, and export or screenshot anything the interface can provide. For each dashboard, write down which groups see which data. The step is done when a sample of at least three representative users has been checked in Sisense and their visible dashboards and rows are written down for comparison later.
Run a test rebuild in staging
The team rebuilds one or two representative dashboards in a staging instance of the target tool, such as Apache Superset or Metabase, against the same data sources. It compares widget count, filters, calculated fields and layout against the .dash file and the live Sisense dashboard, then records each difference. The step is done when the side-by-side checklist is signed by the business owner and every mismatch has a logged ticket with a decision on whether to rebuild, change or retire it.
How to inventory ElastiCubes and data security rules so nothing is missed
An ElastiCube is Sisense's data model, built from one or more source tables with joins, calculated fields and a build schedule. Each cube tells you which source data your dashboards depend on, so record it table by table before you decide what to rebuild. Capture the following for every cube.
- Tables and sources: each table in the cube, the connection or file it reads, and the schema and table name in the source database.
- Joins: the join type, the keys and the relationship between each pair of tables.
- Calculated fields: the formula, the input columns and whether it works per row or as an aggregate.
- Build schedule: the frequency, whether the build is full or incremental, and the person who maintains it.
Mapping: source tables usually become warehouse tables or views, joins become dataset SQL or a semantic layer, and calculated fields move to the database where possible. Migration pages cover those decisions. Confirm each field against your Sisense version in the data model and build settings, because menu names and available details vary between releases.
Data security rules limit which rows or columns a user or group can see. They are often the least documented part of a deployment because they sit alongside cubes and dashboards rather than in one place. Record the full rule set for each cube and each dashboard, including rules that apply only to a single widget.
- Rule definition: the table or cube, the column, the operator and the value or expression.
- Scope: whether the rule applies to a cube, a dashboard or a widget, and which rule wins when several overlap.
- Principals: each user, group or role the rule targets, and any rule that matches users by attribute.
- Hidden columns: columns withheld from particular roles, which need a column-level control in the target tool.
Mapping: row filters usually become database views or dataset-level filters, with the enforcement method confirmed for the tool you choose. Metabase's row and column level permissions require the Pro or Enterprise plan, according to its pricing page, so check that cost early. Confirm where rules live in your version's security and admin screens, and test each rule with a non-administrator account before you retire the Sisense copy.
Sharing settings are not part of the .dash export, so the access model must be recorded by hand or through the admin tools. This inventory answers who can open each dashboard, who owns it and whether any content is reachable without a named login. Without it, the rebuilt environment can be complete but expose the wrong people.
- Dashboard shares: the users, groups or links with access to each dashboard, and whether each grant is view or edit.
- Group membership: group names, their members and whether the groups come from LDAP, SAML or local accounts.
- Owners: the owner of each dashboard and whether that account is still active.
- Public or embedded access: any public link, iframe or token-based embed that serves content outside normal logins.
Mapping: groups usually become Superset roles, where LDAP or OAuth groups can map to roles through configuration, or Metabase permission groups. Metabase's Open Source and Starter plans support Google sign-in and LDAP, while SSO setups such as SAML or OIDC require Pro or Enterprise, according to its documentation and pricing page. Confirm the sharing model in the admin and dashboard share dialogs for your Sisense version, and list any embedded instance separately because it has its own identity path.
BloX items are Sisense's custom actions and components on dashboards, and the .dash export leaves them out. Each one can carry behavior that users depend on, such as navigation, filtering or external calls, so treat every BloX item as a feature to reproduce or retire. Start by listing where they appear, then record what each one does.
- Placement: each BloX widget or action, the dashboard it sits on and the event that triggers it.
- Logic and assets: any script, markup or stylesheet it uses and where that code is stored.
- External dependencies: APIs or services it calls, plus the credentials and network paths it needs.
- Expected behavior: what a user sees or gets from the action, written in plain terms so a rebuild can be tested against it.
Mapping: depending on what the item does, the behavior may become a native chart or filter in Superset, a Metabase feature, or a separate service that the dashboard links to. Some items will need a decision to retire them. Confirm the full BloX inventory inside the dashboard editor for your version, because exports do not show it and you should not assume the list is complete until each dashboard is reviewed.
How to verify the export is complete before the contract ends
Verify the export against an inventory you build yourself, before the subscription ends. Start by listing every dashboard in the Sisense Analytics page, then match that list one to one against the files you exported. Any dashboard without a matching .dash file is a gap to close while you still have access. Open each file in a test environment, confirm it loads, and compare its widgets and filters with the live dashboard, recording differences by name. Do the same inventory for the ElastiCube models and data security rules that the dashboards depend on, since a dashboard file alone does not describe them.
Next, sign off a checklist for everything the .dash file leaves out, including sharing settings, user and group access, and BloX custom actions. For each item, record the current state in Sisense, where you captured it, and who confirmed it. Keep the exported files, screenshots, the inventory and the checklist in storage that your own team controls, not only in the Sisense environment. Access to the source system can end at renewal, and an evidence set you cannot reopen is of little use during a rebuild or an audit.
The strongest evidence is a target-side test: a rebuilt dashboard in Apache Superset or Metabase that reads the same warehouse table as the original and returns the same totals for an agreed set of filters and date ranges. Agree that test, its pass criteria and the sample dashboards in the written scope before work starts, because it takes access to both systems and to the source data. Ask any implementation partner to confirm in writing which checks they will run and which ones you will need to run yourself.
What does it cost and take to export Sisense dashboards yourself?
Can an internal team export Sisense dashboards without outside help?
Yes, many internal teams can export dashboards themselves, especially when the estate is small and one or two people know both the Sisense Analytics page and the target tool. The work is mostly inventory and rebuilding, not a single technical step. The main risk is incomplete work: a .dash file does not carry everything you need, so someone must document sharing settings, BloX custom actions, ElastiCube models and data security rules separately. Confirm with Sisense which export and admin options your version and deployment type support, and check whether your administrators have the rights to run them.
What drives the time an export takes?
The biggest drivers are the number of dashboards, how many widgets and filters each one uses, and how many ElastiCubes sit behind them. Data security rules add work because each one must be mapped to a permission model in the new tool. BloX custom actions add work because they usually need to be redesigned rather than copied. A simple internal estate with few cubes and no BloX can be inventoried quickly, while a large embedded estate needs careful testing. Ask any provider or your own team to size the work from a dashboard inventory rather than from a general estimate.
What access and resources does an export need from our side?
You need administrator access to the Sisense instance to export dashboards and read ElastiCube and security configuration, plus read access to the underlying data sources so the rebuilt dashboards can query the same tables. You also need a staging target, such as a separate Apache Superset or Metabase environment with its own metadata database, so rebuilt content can be tested without touching production users. Name one owner who signs off on each dashboard's behavior, filters and access rules. Without that owner, sign-off stalls and the work drags on.
What does an export cost in staff time, and does a consultant change the result?
The main cost is staff time: analysts who confirm what each dashboard shows, engineers who model the data, and an administrator who handles access. These costs recur only if you keep maintaining the content. A consultant does not change the underlying data or the business logic, but an experienced implementer usually produces a more complete inventory, catches undocumented sharing and BloX behavior sooner, and reduces rework during testing. Ask for the inventory method, the list of items excluded from the export, and who validates the rebuilt dashboards.
What does a fixed-scope export engagement from DeployOpen include?
DeployOpen works from a written scope that defines which dashboards, ElastiCubes and security rules are covered, the target platform, the deliverables and the timeline. Typical deliverables are an inventory of dashboards and data models, a record of sharing settings and BloX actions that the .dash export does not carry, a mapping of data security rules, and rebuilt content in your staging environment for your owner to approve. DeployOpen does not publish a price list, so a quote follows from the agreed scope. Ask for the exclusions in writing, including anything that depends on Sisense licensing or vendor support.
What should we confirm with Sisense before we start?
Confirm which export methods your Sisense version and deployment support, whether a .dash export includes the ElastiCube models you depend on, and what sharing settings, user groups and BloX configurations sit outside the export. Ask how your licence terms affect exporting content and whether the vendor offers migration guidance for your deployment. Also confirm which Sisense administrator actions can be logged, so you can produce an audit trail of the export. Record the answers before you choose a target tool, because they change the inventory.
How do we know the exported dashboards are complete?
Completeness means every dashboard, filter, ElastiCube dependency, security rule and BloX behavior is either rebuilt or formally retired. Build a checklist from the inventory and compare each dashboard's rendered output in Sisense with the rebuilt version, using the same data and filters. Have the named owner sign off each item in writing. Gaps usually appear in access rules and custom actions, so test those with users from each group, not only with administrators.
What to plan before the Sisense contract renews or ends
A Sisense export is only as complete as the time you give it. The decisions below set the dates, the storage, the people and the fallback that the export and rebuild depend on. Work through them before the renewal notice window closes, not after access has changed.
Confirm the subscription terms and access end date
Read your current Sisense order form or renewal notice and record the term end date, the notice period and what happens to logins, dashboards and scheduled reports when the term lapses. Ask your account contact to confirm this in writing, including whether admin access is kept for a defined period after expiry. Everything else in this plan is scheduled backward from that date.
Schedule the full export early
Run the full inventory and export while admin rights are still active, because a .dash file is created from the Analytics page and some objects need an administrator to reach them. Export a second time after your last content change so the archive matches what users saw. Keep the export date and the Sisense version in the export log so the copy can be checked later.
Decide where exported files live
Choose a storage location for .dash files, ElastiCube inventories and data security rule exports before you start, and keep it inside your own environment. Apply the same access controls you use for the source data, since dashboard files can reveal table names, filters and sometimes sensitive values. Name an owner for the archive and set how long it is retained after cutover.
Request documented export support in writing
Ask Sisense in writing which export, data return and migration assistance its current documentation and your contract cover, including any limits on exporting ElastiCube data. Confirm whether support is included in the subscription or billed separately. Get the answer in the same thread as your renewal discussion so the commitment is on record before the term ends.
Price the target's identity and row rules
Apache Superset has no paid edition, so its licence cost is zero, but identity integration and row-level controls still need design and testing. Metabase's free Open Source edition lacks SSO and row-level permissions, which sit in the Pro and Enterprise plans. If your Sisense users rely on SSO or data security rules, include the Metabase plan cost or the Superset configuration work in the plan.
Run a parallel window and freeze changes
Freeze new dashboard and data model changes in Sisense for the export period, so the archive and the rebuild target the same version. Then run Sisense and the target tool side by side long enough for users to compare figures, scheduled reports and filters. Agree on who signs off each dashboard before Sisense access is removed, and keep the frozen export until that sign-off is complete.
How DeployOpen works on this
DeployOpen approaches a Sisense export as a fixed-scope piece of work inside your own infrastructure, starting with an inventory of dashboards, ElastiCubes and data security rules. The output is a written record of what moves, what must be rebuilt and what stays with Sisense until cutover.
How we scope
- Inventory of .dash exports, dashboards, widgets, filters and BloX custom actions in scope
- Map of ElastiCubes to the source tables or queries they depend on
- Written list of sharing settings, groups and data security rules to recreate manually
How we build
- Export scripts or manual steps for single dashboards and batches from the Analytics page
- Rebuild plan for target dashboards in Apache Superset or Metabase against the same databases
- Test checks comparing row counts, filter behavior and key figures between Sisense and the new tool
How we hand over
- Documentation of export steps, object inventory and the mapping from each Sisense object to its replacement
- Permission matrix showing how Sisense groups and data security rules map to target roles
- Runbook for cutover, rollback and retiring the Sisense exports once users confirm results
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Support can cover target platform upgrades, such as checking release notes before each move
- Confirm with DeployOpen in the written scope which post-handover activities are included
