Migrate from Domo to Apache Superset

Migrate from Domo to Apache Superset: what the move involves

Apache Superset replaces the dashboard layer of Domo, but it does not replace everything Domo bundles. If your Domo renewal is driven by consumption credit pressure or a data residency requirement, plan the move as two separate projects: a dashboard migration into Superset, and a replacement for the ingestion, storage and transformation work that Domo currently performs. Superset queries a SQL datastore through a Python DB-API driver and SQLAlchemy dialect, so it needs a warehouse or database you control and a separate pipeline tool to load it. Those two components carry most of the decisions in this migration. In most cases an internal data team does the core work, with an implementation partner supplying the platform build, hardening, and cutover support. The data team knows which Domo datasets, dataflows and cards the business relies on. The partner or platform team typically handles the Superset deployment itself: the metadata database (PostgreSQL or MySQL, not the SQLite default), the caching layer and Celery workers needed for alerts, reports and async queries, SECRET_KEY management, and authentication through LDAP or OAuth groups mapped to roles. Ask any partner to state in writing which of these items sit in scope and who runs them after handover.

Effort depends mostly on how many Domo dataflows you must rebuild and how many Beast Mode calculations carry business logic that has to match finished reports. Moving Magic ETL into a pipeline tool such as Apache Hop is usually the longest task, and Hop's Kettle importer covers only part of Domo's logic, so treat any imported flows as a starting point for review. Build a reconciliation check for each key figure, comparing the old Domo output with the new Superset chart over the same period, before anyone retires a card. The risks are silent metric drift, scheduled refreshes that fail without notice, and users who depend on alerts or subscriptions that behave differently in Superset. When you request a quote, ask for the inventory of Domo datasets, dataflows, cards, pages and users as a fixed-scope deliverable, the list of Beast Mode calculations to be translated, and the test plan for parallel running. Confirm with the vendor and your own environment which Superset version you will pin and how upgrades will be tested, since the upgrade documentation calls for a metadata database backup, superset db upgrade, and a staging run first. Your cost will then be driven by the number of dataflows, the complexity of the calculations, and the scale of the warehouse you choose.

Which Domo capabilities map to Superset, and which need rework

This table maps each Domo capability to its Apache Superset equivalent and marks it as clean, needs rework or gap. Read the rows with your own Domo inventory open, since most rework sits in pipelines and calculations rather than in charts. Superset is Apache-2.0 with no paid edition, but alerts, reports and async queries depend on the caching layer and Celery workers you run yourself.

Domo capability	Apache Superset equivalent	Status
Cards and pages	Charts grouped into dashboards, rebuilt chart by chart in the Superset UI or from exported definitions	Needs rework
Beast Mode calculations	Dataset metrics or calculated columns, or SQL expressions run in SQL Lab against the warehouse	Needs rework
Magic ETL dataflows	No direct equivalent; rebuild in a separate pipeline tool such as Apache Hop, or in SQL and transformation code	Gap
Dataset storage	Superset stores no data; datasets point to tables in your own warehouse or database, so storage must be decided first	Needs rework
Dashboard filters	Native filters on dashboards, with cross-filtering supported for many chart types	Clean
SQL querying	SQL Lab for ad hoc queries against any database with a supported SQLAlchemy dialect	Clean
Scheduled reports and alerts	Alerts and reports need the caching layer and Celery worker and beat processes running	Needs rework
Sharing and access	Roles and permissions, with OAuth, LDAP or database authentication through Flask-AppBuilder	Needs rework

Which datasets, pipelines and connectors move, and how

A Domo migration to Superset is really three moves: where the data lands, how Magic ETL logic is rebuilt, and which connectors need a replacement. Each card below is one of those decisions or checks, and the order matters because dashboards depend on the data layer beneath them.

Choose the warehouse or PostgreSQL target

Superset does not store your business data. It queries a database through a SQLAlchemy dialect, so every Domo dataset needs a home in a warehouse or PostgreSQL instance that Superset can reach. Decide this first, because it sets the query speed, the cost of storage and who operates the database. Confirm which Domo datasets are still in use and how large they are, since that sizing drives the target choice. Superset's metadata database (PostgreSQL or MySQL) is a separate database and should not be confused with this analytics target.

Confirm Domo export paths in your tenant

No documented Domo bulk export is supplied for this migration, so the way to extract dataset contents must be confirmed in your own Domo tenant with your administrator and Domo's current documentation. Ask which export formats your plan and role allow, whether row limits apply, and whether datasets can be exported on a schedule. Test with one large dataset before committing to a method. Record what cannot be exported so it can be re-ingested from source systems instead.

Rebuild Magic ETL as a pipeline tool

Magic ETL dataflows combine ingestion, joins, transforms and scheduled output in one Domo product. In Superset, that logic has to live in a separate pipeline tool, such as dbt, Airflow or Apache Hop. Map each dataflow to its inputs, transforms and outputs, and identify which ones can become SQL views instead of pipelines. Keep the dataflow schedule and failure alerts in the pipeline tool so that data freshness does not depend on someone opening a dashboard.

Use Apache Hop for Kettle-style rebuilds

Apache Hop is an Apache-2.0 data integration tool with a visual canvas. Its Kettle importer converts Pentaho .kjb and .ktr files, but it is not a Domo importer and cannot read Magic ETL flows. Choose it only when your team already has Kettle knowledge or you are rebuilding Pentaho jobs alongside Domo dataflows. Note that the importer keeps one copy of same-named database connections and does not import the metastore, so review connection settings after conversion. Hop Server needs an external scheduler to submit work.

Inventory connectors that need replacement

Each Domo connector is a managed integration that Domo maintains. In a self-hosted stack, every source needs an ingestion method, a credential store and an owner. List every connector in use, the source system, the refresh frequency and the credential type, then mark which ones have an open-source or native database route and which need custom code. SaaS connectors with OAuth flows often need the most work, so confirm each one early with the source system owner.

Plan refresh and freshness parity

Domo refreshes datasets on schedules you may have set years ago and rarely reviewed. Superset charts show whatever the warehouse holds, so a missed load looks like a wrong dashboard. Before cutover, document the refresh time, expected lag and owner for every dataset that feeds a dashboard, and compare outputs from Domo and the new pipeline for the same period. Keep both running until the numbers match for the agreed review cycle. Alerts and reports in Superset also depend on Celery workers and a caching layer.

The migration sequence from inventory to decommission

This sequence moves Domo cards, pages, dataflows and users onto Apache Superset in an order that keeps numbers verifiable at every stage. Each step closes with a named output, so the cutover and the Domo shutdown rest on evidence rather than assumption.

Inventory Domo content, dataflows and users
Export a list of every card, page, dataflow, dataset, scheduled delivery and user from the Domo admin console, and record which business owner depends on each one. Note which Magic ETL dataflows write to Domo-stored datasets and which read from source systems, since that determines where each dataset must live after migration. Ask Domo support or your administrator to confirm which export formats and user reports your tenant can produce. The output is a content register with owner, usage and dependency columns, reviewed and signed off by the business owners who will lose access.
Decide where datasets will live
Choose the warehouse or database that Superset will query, such as PostgreSQL or another SQL store with a Python DB-API driver and SQLAlchemy dialect that your team already operates. Decide which Domo-stored datasets will be landed there and which can be queried at the source. Confirm with the data owners how refresh schedules and retention will work once Domo storage is no longer the system of record. The output is a written data placement decision for each dataset in the register.
Stand up Superset and its metadata database
Deploy Superset in your own infrastructure with a production metadata database, PostgreSQL or MySQL, rather than the SQLite default used by quickstart and PyPI installs. Set a SECRET_KEY explicitly, since Superset requires one to start, and connect your identity provider through Flask-AppBuilder using OAuth, LDAP or database authentication. If you need alerts, reports, async queries or thumbnails, plan for the caching layer and Celery workers as well. Your platform team should confirm the supported metadata database versions against the configuration documentation before choosing a version. The output is a staging environment with working login and a tested metadata database.
Rebuild the pilot dashboard set
Pick a small set of high-value cards and their Domo pages that cover the most common chart types and Beast Mode patterns. Rebuild them in Superset as datasets with dataset metrics, SQL-based calculations, charts and dashboards, and record every calculation that cannot be expressed directly. Rebuild the pipeline logic that feeds these datasets in your chosen pipeline tool, such as Apache Hop, and document how each Magic ETL step maps to a transform or SQL statement. The output is a pilot dashboard set running in staging, with a mapping document for its calculations and pipelines.
Run Domo and Superset in parallel and reconcile
Run the pilot dashboards alongside the original Domo cards for a period agreed with the business owners, refreshing both from the same source data. Compare totals, row counts, filters and date boundaries for each card, and investigate every difference until its cause is known. Where a Domo result depended on behavior that Superset calculates differently, record the rule and the agreed correct figure. The output is a reconciliation log showing each card as matched, explained or open, signed off by the business owners.
Harden, back up and upgrade under change control
Before any production change, back up the Superset metadata database, then run the database upgrade and initialization steps described in the upgrade documentation. Apply every Superset version change in staging first, and read the UPDATING.md file for breaking changes between the versions you are moving across. Confirm that restore from backup has been tested on a copy of the metadata database. If you deploy on Kubernetes, check the current installation guidance, since the Helm chart is marked deprecated for new deployments. The output is a documented change record and a tested restore procedure.
Cut over users and scheduled deliveries
Move users to the Superset dashboards in waves, starting with the groups whose cards reconciled cleanly. Map LDAP or OAuth groups to Superset roles using the role mapping configuration, and confirm that each group sees only the datasets it should. Recreate scheduled reports and alerts in Superset, and switch recipients over after the first successful runs. The output is a cutover record listing each group, its role mapping, and the date its scheduled deliveries moved.
Decommission Domo content and stop credit use
Once each group has used Superset without open reconciliation items, disable Domo schedules and dataflows in the order they were retired, then archive the exported content register and card definitions. Confirm with Domo how your contract and credit consumption will end, and ask whether any remaining data must be exported for retention. Remove remaining Domo user accounts after the owners confirm access is no longer needed. The output is a decommission record showing that no Domo schedules run, that archives are stored under your retention policy, and that the contract end is confirmed in writing.

How the self-hosted Superset stack fits together

Apache Superset has four architecture components that you need to place in your environment: the Flask and React application, a metadata database, an optional caching layer, and optional Celery worker and beat processes. The application serves dashboards and SQL Lab, and the metadata database stores Superset's own state, such as dashboards, charts, datasets and users. The caching layer and workers are optional for a basic install, but the Superset architecture documentation states that alerts and reports, async queries and dashboard thumbnails depend on them, and most installations use Redis and Celery for those features. If your Domo migration relies on scheduled email reports or heavy dashboards, plan for the caching and worker components from the start.

Do not run production on the SQLite default used by Quickstart and PyPI installs. Superset is tested with PostgreSQL and MySQL as the metadata database, and the configuration documentation lists supported versions as PostgreSQL 10 to 17 and MySQL 5.7 and 8.x. Confirm the exact version against the release you deploy, since the list changes between Superset versions. Superset also requires a user-specified SECRET_KEY to start, a requirement added in version 2.1.0, and supports rotating it through PREVIOUS_SECRET_KEY. Store the key in your secrets manager, not in a file in the repository, and record who holds it, because losing it affects access to stored database credentials.

For sign-in, Superset is built on Flask-AppBuilder and supports database accounts, LDAP, and OAuth2 providers such as Google and Azure, along with custom OAuth2 servers that use the code flow. The AUTH_ROLES_MAPPING setting maps LDAP or OAuth groups to Superset roles, so your identity provider groups, rather than manually assigned accounts, can decide who builds datasets and who only views dashboards. Map these groups before you migrate users, and test them in staging with a few accounts from each group. Confirm with your identity team which protocol and claims your provider supplies, and confirm the deployment target (virtual machines, containers or Kubernetes) with your platform team, since the Helm chart is documented as deprecated for new deployments in current development docs.

How the migration differs by starting point

Teams that already load their business data into a warehouse have the smallest migration. Superset queries that warehouse directly, so the work moves from Domo's storage and ingestion layer to a database the organization already operates. The main effort is re-pointing dashboards and confirming that the warehouse tables match what Domo cards were reading.

Scope: Cards that read warehouse tables can be rebuilt against the same tables, usually without copying data.
Pipeline work: Only Domo dataflows that transform data inside Domo need rebuilding. Ingestion that already lands in the warehouse can often stay where it is.
Parallel run: Compare Domo and Superset results for each card against the same warehouse query until totals match.
Credentials: Create read-only database roles for Superset and confirm they cannot write to reporting schemas.

Before you start, confirm with your data team which Domo datasets are copies of warehouse tables and which were built only inside Domo.

What drives cost and duration, and how to keep each down

This table lists the main factors that change the effort and cost of moving Domo content to Apache Superset, who pays for each one, and what to request in a fixed-scope quote. Read it as a checklist: the largest swings usually come from warehouse readiness, Magic ETL rebuild volume and identity integration, while card counts matter less than they appear.

Driver	Who is paid for what	One-time or recurring, and how to keep it down
Number of cards and pages	Your team or a partner rebuilds each card as a Superset chart and each page as a dashboard, and tests it against the same numbers	One-time. Keep it down by retiring unused cards first and grouping near-identical cards into one parameterized chart
Beast Mode complexity	Calculations become SQL expressions or dataset metrics, so an analyst or engineer rewrites and validates each one	One-time. Simple arithmetic is cheap to port; multi-step calculations with nested logic need a reconciliation step against Domo output
Magic ETL dataflow count	Dataflows are rebuilt in a pipeline tool such as Apache Hop, which means someone designs, tests and schedules each pipeline	One-time for the build, recurring for operating the scheduler and pipeline runs. Consolidate flows that share sources before rebuilding
Warehouse readiness	Your data platform team or your cloud provider is paid for the warehouse capacity; a partner may be paid to model tables Superset will query	Mostly one-time setup, with recurring warehouse compute and storage. Ask for a written inventory of which Domo datasets already exist in a queryable database
Identity integration	Whoever configures OAuth2, LDAP or group-to-role mapping through Flask-AppBuilder is paid for that work and for testing access	One-time setup, with recurring review of role mappings. Reuse your existing identity provider rather than building local accounts
Embedded or external users	Work covers embedding setup, tenant isolation and the host application's access checks, which Superset does not handle alone	One-time design, recurring infrastructure. Confirm the number of external users early, since isolation design depends on it
Alert and report requirements	Scheduled reports and alerts need the caching layer and Celery worker and beat components, which someone must install, monitor and patch	Recurring operating cost for Redis, workers and mail or messaging integration. Only enable alerts that business owners actively use
Number of parallel runs and staging environments	Each staging environment, parallel validation run and upgrade rehearsal consumes infrastructure and tester time	Recurring infrastructure for test copies. Limit parallel runs to one staging environment and a defined parity check against Domo outputs
Metadata database and upgrades	Platform operators handle PostgreSQL or MySQL backups, the superset db upgrade and init steps, and reviews of UPDATING.md	Recurring. Confirm supported metadata database versions in the configuration docs before choosing a version of the database

What usually goes wrong in a Domo to Superset move

Most failed BI migrations break at the seams: metric logic that changes meaning, pipelines that lose a step, and operational pieces Domo used to handle silently. The cards below cover the risks that tend to surface after cutover, each paired with a check to run before users notice.

Metric definitions drift from Beast Mode

A Beast Mode calculation is not automatically the same as the SQL or dataset metric you write in Superset. Null handling, integer division, time zones and filter context can all return different totals on the same data. Before cutover, pick a sample of cards, export their Domo results for a fixed date range, and compare them row for row with the Superset chart. Record every metric that does not match and decide which definition the business owns.

Dataflow logic lost in translation

Magic ETL dataflows often contain joins, filters and reshaping steps that teams forget they built. When those steps are rebuilt by hand in a pipeline tool such as Apache Hop, a dropped filter or a changed join type can silently alter the dataset that feeds every chart. List each dataflow's inputs and outputs, then reconcile row counts and key totals at each stage, not only at the final table.

Row-level access rules left behind

Domo governs who sees which rows through its own permission settings, and those rules do not move with the dashboards. A Superset dataset without row-level security will show every customer's data to anyone with dashboard access. Document each Domo rule, implement it as Superset row-level security or as filtered database views, and test it with a non-admin account for each audience before any report is shared.

Scheduled reports stop without workers

Alerts, scheduled reports and dashboard thumbnails depend on the caching layer and the Celery worker and beat processes, not only the web application. A Superset install that serves dashboards correctly can still send no reports at all. Confirm that the worker and beat services are running, that the broker is reachable, and that a test report reaches a real inbox from a production-like environment before retiring the Domo schedules.

SECRET_KEY and metadata database mistakes

Superset will not start without a SECRET_KEY that you set yourself, and changing it later can break access to stored database connections unless you configure PREVIOUS_SECRET_KEY for rotation. The default SQLite database used by quick installs is not suitable for production. Store the key in your secrets manager, use PostgreSQL or MySQL for metadata within the supported versions, and back up that database before every upgrade with superset db upgrade and superset init.

Users expect Domo's bundled connectors

Domo ships with a large catalog of managed connectors, and business users often assume every source they used there will be one click away in Superset. Superset connects to any database that has a Python DB-API driver and SQLAlchemy dialect, but it does not extract data from SaaS applications on its own. Inventory every connector in use, decide which ones a pipeline tool or warehouse loader will cover, and tell users which sources will need a request before the cutover date.

Questions buyers ask before moving off Domo

How much effort and time does a move from Domo to Apache Superset take?

The effort depends mainly on how many cards, pages and dataflows Domo holds, how many Beast Mode calculations they rely on, and how much of the data already sits in a warehouse Superset can query. No supplied figure gives a reliable duration, so ask for one from a written scope after an inventory of your Domo estate. Each card you retire rather than rebuild shortens the work. Each Magic ETL dataflow that must be rewritten in a pipeline tool adds more, because it is a rebuild and a test, not a copy. Ask any implementation partner to size the work by these counts and to state assumptions in writing.

Can an internal team migrate from Domo to Superset on its own?

Often yes, if the team already knows SQL, has administered a Linux server or container platform, and has an owner for the warehouse. Superset itself is Apache-2.0 licensed with no paid edition, so the software is not the constraint. The harder parts are running the production stack (a PostgreSQL or MySQL metadata database, and for alerts, reports and async queries, a caching layer and Celery workers), building the pipeline layer, and testing every chart against Domo's numbers. Teams without that depth usually split the work: internal staff own the data and business logic, and an outside team handles deployment, hardening and cutover.

What does the work need from our internal staff?

Plan on named time from four groups. Business owners must confirm which dashboards are still used and what each metric means. Data engineers must confirm source tables, refresh schedules and the logic inside each Magic ETL flow. Analysts must validate rebuilt charts against Domo output. Platform or security staff must provide hosting, identity integration (OAuth2, LDAP or database accounts mapped through AUTH_ROLES_MAPPING), backups and network access. Ask for a RACI table in the statement of work so each of these responsibilities has a name before work starts.

Can Apache Superset replace Domo ETL and dataflows?

Not by itself. Superset is a query, visualization and dashboard layer. It connects to SQL datastores through Python DB-API drivers and SQLAlchemy dialects, but it does not replace the extract, transform and load jobs that Domo runs in Magic ETL. Those jobs need a separate pipeline tool. Apache Hop is one Apache-2.0 option: its pipelines can run on a local engine, a remote Hop Server, Apache Spark, Apache Flink or Databricks, and it includes an importer for Kettle (.ktr and .kjb) files. Hop Server does not schedule work, so an external scheduler must still submit jobs. Importer output is a starting point that needs review, not a finished pipeline.

Do Domo credits disappear entirely after moving to Superset?

The credits tied to Domo's own ingestion, dataflow execution and storage stop when that work moves off Domo. Your bill then shifts to the components that replace them: warehouse compute and storage, pipeline runtime, the servers or Kubernetes cluster running Superset, backups, and staff time. Superset's license adds no per-user or per-credit charge. Confirm with Domo in writing how contract terms, data export and any remaining subscription obligations work, because export limits and notice periods are contract-specific and no supplied fact covers them.

How does cutover avoid downtime for business users?

Run both platforms in parallel. Load the warehouse tables, point Superset charts at them, and compare each rebuilt dashboard with its Domo counterpart over several refresh cycles before anyone relies on it. Upgrade-safe practice applies here too: back up the metadata database, test in staging, and check UPDATING.md before each Superset version change. Switch users group by group, keep Domo read-only for a fallback window, and set a clear cutoff date for retiring Domo content. Do not use the SQLite default or the Docker Compose PostgreSQL container for production, since the architecture documentation does not recommend them.

What should the Superset architecture include for production?

For production, the architecture documentation describes four components: the Flask and React application, a metadata database, an optional caching layer and optional Celery worker and beat processes. Use PostgreSQL 10 to 17 or MySQL 5.7 or 8.x for metadata, and set a SECRET_KEY, which Superset requires to start. Alerts, reports, async queries and dashboard thumbnails need the caching layer and workers, which most installations run on Redis and Celery. Confirm the Kubernetes approach too: the 6.1.0 docs describe the Helm chart, while current development docs mark it deprecated in favor of the Apache Superset Kubernetes Operator.

How DeployOpen scopes and runs a Domo to Superset migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Domo to Apache Superset move, we start with an inventory of your Domo content and the warehouse or database that will hold your data, then agree the migration in writing before work begins.

How we scope

Inventory Domo datasets, Magic ETL dataflows, cards, pages and Beast Mode calculations, with owners and usage.
Agree in writing where Domo-stored datasets will live, and which database Superset will query directly.
Confirm the pipeline tool, metadata database, authentication model and hosting target before any build starts.

How we build

Deploy Superset with PostgreSQL or MySQL as the metadata database, and configure caching and workers where alerts or reports are needed.
Rebuild dataflows in a pipeline tool such as Apache Hop, and convert Beast Mode logic into SQL or dataset metrics.
Recreate cards as charts and dashboards, then test figures against the Domo originals before sign-off.

How we hand over

Deliver written documentation covering architecture, data lineage, metric definitions, roles and the upgrade procedure.
Walk your team through dashboards, datasets, role mapping and the cutover checklist, with the Domo retirement plan agreed.
Provide a record of test results and open items so your auditors or internal reviewers can trace what was changed.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, separate from the fixed-scope migration.
Retainers can cover staged upgrades that back up the metadata database, test in staging and review breaking changes first.
Ask any quote to state which Superset release, pipeline version and hosting components are included in support.

Migrate from Domo to Apache Superset