Table of Contents
- Why Government Teams Are Switching to Superset
- Scoping the Migration: Inventory and Assessment
- Governance and Compliance in the Public Sector
- Cost Benchmarks and Total Cost of Ownership
- Technical Migration: From Sisense to Superset
- The Cutover Pattern: Go-Live Without Disruption
- Post-Migration Optimisation and Ongoing Management
- How PADISO Accelerates Your Migration
- Summary and Next Steps
Australian government organizations are at an inflection point with business intelligence. Sisense has delivered value, but its per‑seat licensing model and proprietary stack often clash with the public sector’s mandate for fiscal discipline, data sovereignty, and open architecture. Apache Superset, a modern open‑source analytics platform, flips that equation: zero license fees, full control over data residency, and a community that moves fast. At PADISO, we’ve guided multiple government teams through this exact migration, from Canberra’s secure environments to state‑level health and transport dashboards. This playbook distills the scoping, governance, cost benchmarks, and cutover patterns you need to ship Superset without disruption.
Why Government Teams Are Switching to Superset
Government BI is under relentless pressure to do more with less. Every dollar spent on a per‑seat license is a dollar not invested in frontline services. Apache Superset eliminates that line item entirely. It’s Apache‑licensed, free to use, and runs wherever you place it — on‑premises, in a sovereign cloud tenancy, or across AWS, Azure, or Google Cloud. For agencies bound by the Digital Service Standard, Superset aligns with the requirement to choose open, reusable platforms that avoid vendor lock‑in.
Beyond costs, data sovereignty is non‑negotiable. When you host Superset inside your own IRAP‑assessed environment, no data ever leaves Australian borders. That’s a sharp contrast with proprietary SaaS tools where data transit, backup, and processing often traverse offshore nodes. Our platform development practice in Canberra specializes in building sovereign‑grade Superset deployments that satisfy even PROTECTED classification requirements.
Performance and extensibility also drive the move. Superset connects natively to modern analytical databases like ClickHouse, Apache Druid, and Trino, enabling sub‑second queries on billion‑row tables — something Sisense’s in‑memory engine struggles to match at that scale. And because Superset exposes a rich REST API, teams can embed dashboards into internal portals or operational tools, creating a true data platform rather than a standalone reporting silo.
Scoping the Migration: Inventory and Assessment
A disciplined migration starts with a clear inventory. Before writing a single line of SQL, catalog every Sisense artifact:
- Dashboards and their underlying ElastiCubes or live connections
- User roles, groups, and sharing rules
- Scheduled exports, alerts, and embedded widgets
- Data sources — databases, APIs, flat files — with connection strings and credentials
Classify each dashboard by business criticality, usage frequency, and complexity. A simple dashboard pulling from a single SQL view will migrate quickly; a multi‑cube dashboard with complex custom formulas and row‑level security demands more engineering. This grading lets you sequence the work: low‑complexity, high‑visibility dashboards first, to build momentum and user confidence.
For agencies running dozens or hundreds of dashboards, manual cataloging is impractical. We often deploy a lightweight discovery agent that interrogates the Sisense API and exports a structured manifest. AI‑powered migration tooling can then map Sisense constructs — filters, calculated fields, access controls — to their Superset equivalents, accelerating the transformation phase by weeks.
A key scoping decision is whether to lift‑and‑shift or re‑architect. Many government dashboards were built on top of pre‑aggregated cubes that mask underlying data models. Superset encourages a different pattern: model clean, governed datasets directly in the database or semantic layer, then build visuals on top. This often delivers simpler, faster dashboards, but it requires investment in data engineering. Our CTO advisory service in Canberra helps agencies make those architectural trade‑offs early, aligning the migration with a broader data strategy.
Governance and Compliance in the Public Sector
Compliance is the backbone of any government data initiative. When migrating BI, you must carry forward — and often strengthen — controls around access, audit, and data handling.
Access control. Superset supports role‑based access control (RBAC) out of the box, with granular permissions on datasets, dashboards, and even individual rows via SQL‑based row‑level security (RLS). You can mirror your existing Sisense groups and permission sets, but take the opportunity to rationalize: many legacy deployments accumulate redundant roles over years. Design a clean RBAC hierarchy that maps to organizational units, clearance levels, and data classifications.
Data sovereignty and IRAP. For systems handling Australian Government data, you’ll likely need to align with the Information Security Manual (ISM) and potentially undergo an IRAP assessment. Superset’s open‑source nature is an asset here: assessors can review the entire stack, from the web server to the query engine. By deploying on infrastructure you control — whether on‑premises, in a sovereign cloud, or via a Canberra‑based platform engineering team that understands IRAP/PROTECTED requirements — you retain full custody of data. Pair Superset with a data warehouse that supports encryption at rest and column‑level masking, and you can meet PROTECTED requirements without a single byte leaving the jurisdiction.
Auditability. Every Superset query, dashboard view, and configuration change can be logged to a central audit trail. Combined with database audit logging, this satisfies the record‑keeping demands of the Digital Service Standard and internal governance bodies. We typically forward Superset logs to a SIEM like Splunk or Elastic, so security teams have a single pane of glass.
Compliance as code. For agencies moving toward DevSecOps, Superset’s configuration — datasets, charts, dashboards, roles — can be expressed as YAML through tools like superset‑cli or the REST API. This enables versioning, peer review, and automated compliance checks. A change to row‑level security rules becomes a pull request auditable by a security architect before deployment.
Throughout the migration, you’ll want to maintain a parallel compliance track. Early engagement with your IRAP assessor and privacy officer ensures that new patterns — say, moving from a proprietary encrypted cube to a database‑side encryption model — are documented and approved before go‑live.
Cost Benchmarks and Total Cost of Ownership
Let’s talk numbers — without the license sales pitch. The most immediate saving is the elimination of Sisense’s recurring fees. A typical mid‑sized government deployment with 200 viewers and 20 creators might pay AUD 200,000–400,000 annually in Sisense licensing. Superset, being free, removes that entirely. You’ll still pay for infrastructure: compute, storage, and networking. Deploying Superset on Kubernetes with a modest cluster (say, four nodes) plus a managed analytical database like ClickHouse often lands between AUD 3,000–8,000 per month, including backup and monitoring. Even at the high end, that’s a 70–90% reduction in recurring platform costs.
Migration is a one‑time investment. Scoping, engineering, testing, and training for a mid‑sized portfolio typically spans 8–16 weeks, depending on complexity. If handled entirely in‑house, you’re allocating a small team of data engineers and front‑end developers. Engaging a partner like PADISO can compress the timeline and reduce risk, often delivering a fixed‑price migration at a fraction of the annual license cost you’re shedding. Our platform development engagements on the Gold Coast, in Sydney, Melbourne, and Canberra have repeatedly shown that the migration pays for itself within the first fiscal year, after which the savings flow straight to mission delivery.
Beyond direct infrastructure, factor in indirect savings: less vendor negotiation overhead, no true‑up audits, no surprise price hikes at renewal. And because Superset’s open API allows deep integration, you can automate distribution and reduce manual reporting effort. One transport agency we worked with reduced its monthly report‑generation time from 40 hours to just 2 by embedding Superset dashboards into an operational portal.
Technical Migration: From Sisense to Superset
The technical path from Sisense to Superset follows a well‑rehearsed pattern. We break it into seven concrete steps.
1. Export Sisense Assets
Begin by exporting all Sisense dashboards, widgets, and data models. Sisense’s server‑to‑server migration tools can produce a portable package, but they were designed for environment replication rather than cross‑platform migration. Treat this export as a raw reference; you’ll rarely import it directly. Supplement it with a thorough API‑driven extraction of user lists, groups, and security rules.
2. Map and Transform Definitions
Sisense and Superset speak different configuration languages. Sisense relies on ElastiCubes (pre‑aggregated OLAP cubes) and dashboard JSON that embeds visual properties, formulas, and connections. Superset uses datasets (virtual tables) and chart definitions stored in its metadata database. You’ll need a transformation engine — either custom scripts or a migration accelerator — to map:
- ElastiCube tables and fields → Superset datasets and columns
- Calculated fields → Superset metrics and computed columns
- Filters and parameters → Superset filter boxes, dashboard‑level filters, or URL parameters
- Access rules → RBAC roles and RLS policies
For complex dashboards, expect to re‑implement some logic directly in the database as views or materialized tables, which often improves performance and maintainability.
3. Provision the Superset Instance
Deploy Superset on your chosen infrastructure. A Docker‑based setup behind a reverse proxy works for smaller pilots, but production government workloads demand resilience. We recommend a Kubernetes deployment with a dedicated metadata database (PostgreSQL), a results backend (Redis or similar), and a scalable query engine. This architecture is well‑covered in the official Superset documentation. Place the instance inside your protected network boundary, and ensure all database connections use TLS with certificate validation.
4. Connect and Model Data Sources
Superset’s SQLAlchemy dialect support gives you access to nearly any database. For high‑performance analytics, connect directly to your analytical store — ClickHouse, Apache Druid, BigQuery, or even a properly indexed PostgreSQL instance. Model datasets by writing SQL queries that expose clean, governed views of the data. This step is where you eliminate the black‑box ElastiCube layer and build a transparent semantic layer that data stewards can trust.
5. Rebuild Dashboards
Leveraging the mapping from step 2, rebuild your dashboard inventory. Superset’s Explore interface lets you create charts quickly, and the dashboard layout tool is intuitive. Automate repetitive chart creation with the Superset API where possible. A practical migration plan similar to the one used for Power BI to Superset migrations demonstrates how to systematize dataset abstraction and security configuration across dozens of dashboards.
6. Implement Security Controls
Apply the RBAC and RLS policies designed in the governance phase. Test thoroughly: a user in the “Regional Manager” role should see only the rows for their region, while an executive should get the aggregated view. Use Superset’s dataset‑level permissions to ensure sensitive data sources are invisible to unauthorized users, even before RLS is applied.
7. Validate and Tune
Parallel‑run the old Sisense dashboard and the new Superset dashboard side‑by‑side. Compare outputs for a representative sample of queries, paying special attention to edge cases in calculated fields and date boundaries. Performance‑tune any slow charts by adjusting database indexes, materializing common aggregations, or adding caching layers.
The Cutover Pattern: Go‑Live Without Disruption
A migration is only as good as its cutover. Government agencies cannot afford a day of broken dashboards. We use a phased, dual‑run pattern that keeps Sisense alive while users transition to Superset.
Week 1–2: Parallel run for power users. Invite a small group of savvy analysts and report consumers to use both platforms. Provide clear feedback channels — a shared channel, office hours, a scoring rubric — and iterate on the Superset dashboards based on their input. This surfaces bugs and UX friction while the stakes are low.
Week 3–4: Department‑by‑department rollout. Move low‑risk departments or dashboards first. Each cutover is a binary switch: redirect reports, bookmarks, and embedded analytics to Superset URLs. Keep Sisense running in read‑only mode so anyone who hits an old link can still access historical data while being nudged toward the new platform. Teams like ours specializing in platform engineering in Sydney and Melbourne have honed this pattern to near‑zero disruption.
Technology for the cutover: Use a reverse proxy (nginx, HAProxy) to route requests based on headers or paths. For embedded analytics, deploy a lightweight wrapper that detects the requesting application and serves the appropriate embed. Automate user provisioning so that as soon as a department is scheduled to cut over, their Superset accounts are active and populated with the correct permissions.
Training and change management. Even a perfect technical migration fails if users abandon the tool. Run 30‑minute live demos tailored to each department’s dashboards. Produce concise “get‑started” guides that highlight the three things a viewer needs to know: logging in, filtering data, and exporting. Over‑communicate the timeline and the benefits — faster load times, no more license‑induced seat restrictions, and the ability to request new dashboards without a procurement cycle.
Fallback plan. For the first month post‑cutover, keep Sisense in a warm standby. If a critical defect surfaces in a Superset dashboard, you can flip back that single dashboard’s URL to the Sisense equivalent in minutes. This safety net gives stakeholders the confidence to proceed.
Post‑Migration Optimisation and Ongoing Management
Once the last dashboard is live on Superset, the real work begins: turning the platform into a strategic asset.
Performance tuning. As user concurrency grows, you may need to scale out the Superset web layer, introduce a read‑replica for the metadata database, or add a caching layer (Redis, memcached). Use Superset’s built‑in query‑result caching and consider a dedicated query engine like ClickHouse that can handle thousands of analytical queries per second. The Superset community guide offers extensive performance recommendations.
Embedding analytics. One of Superset’s superpowers is its ability to embed dashboards directly into other web applications — your agency portal, an operational tool, or a public‑facing transparency site. This transforms BI from a siloed destination to a pervasive capability. Leverage Superset’s JavaScript SDK and REST API to build a governed embedding strategy.
Automated lifecycle management. With Superset’s API, you can treat dashboards as code. Store chart and dashboard definitions in Git, run automated deployment pipelines, and even spin up temporary review instances for every pull request. This is a quantum leap from the manual, point‑and‑click administration most Sisense deployments endure.
Continuous improvement cycle. Establish a lightweight governance board with representatives from analytics, security, and the business. Meet monthly to review usage telemetry, prioritize new dashboard requests, and plan upgrades. Because Superset is open source, you can align your upgrade cadence with the community release cycle or pin to a stable LTS version.
And if you ever need to migrate your Superset instance to a new cloud environment, the pattern is well‑understood: backup the metadata database, restore it in the target environment, and sync file‑based artifacts.
How PADISO Accelerates Your Migration
PADISO isn’t a generalist consultancy. We’re a founder‑led venture studio that partners with government and mid‑market organizations to ship high‑stakes technology transformations. Our practice areas directly map to every phase of a Sisense‑to‑Superset migration.
- CTO as a Service — For agencies that need hands‑on technical leadership to define the migration strategy, negotiate with vendors, and align the work with broader digital transformation goals. Our fractional CTOs have led multiple government BI modernisations and bring a battle‑tested playbook.
- Venture Architecture & Transformation — Before a single server is provisioned, we design the target architecture: Superset deployment topology, data mesh principles, security zoning, and the migration sequencing plan. We don’t produce slide decks; we produce executable blueprints.
- Platform Design & Engineering — From Canberra to the Gold Coast, we build and operate the platform layer that Superset runs on: Kubernetes clusters, CI/CD pipelines, monitoring stacks, and tight integration with your data warehouse. Our sovereign‑cloud expertise ensures IRAP alignment from day one.
- AI & Agents Automation — We deploy proprietary AI‑assisted migration tooling that dramatically reduces the manual effort of translating Sisense dashboards into Superset definitions. Models like Claude Opus 4.8 and Haiku 4.5 help us parse ElastiCube schemas, generate dataset definitions, and validate security rules faster than any manual approach.
- Security & Compliance Readiness — Using Vanta, we harden your Superset instance for SOC 2 and ISO 27001 audit‑readiness, ensuring your governance posture is defensible from the first day of operations.
Unlike large systems integrators, we embed with your team, transfer knowledge, and leave you with an internal capability — not a dependency.
Summary and Next Steps
Migrating from Sisense to Apache Superset is a high‑return initiative for Australian government organizations. It slashes recurring BI costs, strengthens data sovereignty, and gives you full control over your analytics future. The migration itself is a structured engineering exercise — scoped, governed, and executed in phases — that can be completed without interrupting business operations.
The most successful migrations start with a single 30‑minute discovery call. If you’re a government CTO, data leader, or program director in Australia, book a call with our Canberra team or reach out through our main site. We’ll review your Sisense environment, sketch a preliminary migration timeline, and give you a fixed‑price proposal that turns your BI licensing drain into a platform investment.