Migrating from Looker to Apache Superset: The D23.io Playbook

Table of Contents

• Why Companies Are Moving Away from Looker
• Why Apache Superset Is a Compelling Alternative
• Introducing D23.io: A Managed Superset Solution from PADISO
• Pre-Migration Planning and Assessment
• Step-by-Step Migration Process
  • Phase 1: Data Source Remapping
  • Phase 2: Dashboard Rebuilds
  • Phase 3: Semantic Layer Translation
  • Phase 4: User Migration and Training
  • Phase 5: Cutover and Production Rollout
• Advanced Topics and Best Practices
• PADISO’s Expertise in Migration and Platform Engineering
• Measuring Success and Ensuring ROI
• Common Pitfalls to Avoid
• Summary and Next Steps

Mid-market companies and private-equity portfolio firms are increasingly questioning the escalating costs of Looker. What began as a modern BI solution often turns into an annual seven-figure line item once per-seat licensing, embedded analytics premiums, and Google Cloud’s enterprise pricing kick in. For organizations driving EBITDA lift through operational efficiency, that math no longer works. Migrating from Looker to Apache Superset slashes licensing to zero, puts control back in the hands of engineering and data teams, and opens the door to deep customization — especially when you bring in D23.io, PADISO’s managed Superset platform.

This playbook walks through a proven migration framework. We’ve executed it for platform development in New York, Chicago, and Toronto — environments where data latency, compliance, and dashboard reliability are non-negotiable. Whether you’re a scale-up CTO or a PE operating partner consolidating tech stacks across a roll-up, you’ll find actionable steps, architecture decisions, and a clear cutover timeline.

Why Companies Are Moving Away from Looker

Looker’s value proposition — a semantic layer with LookML and a browser-based explorer — made it a darling of data teams for years. But the landscape shifted. Three trends are pushing organizations to look elsewhere:

1. Cost explosion: Per-seat pricing becomes punitive at scale. A 500-user deployment can easily cross $1 million annually. For mid-market brands and PE-backed companies where every dollar hits EBITDA, that’s a non-starter. When we guide platform development in the United States, we often uncover that BI licensing alone consumes 10–15% of the total data stack budget.
2. Vendor lock-in: LookML is proprietary. While powerful, it ties your metric definitions and exploration logic to Google’s ecosystem. If you want to leave, you’re effectively rebuilding your semantic layer from scratch. Open formats like SQL and YAML-based configuration give you portability — a critical consideration for any venture architecture and transformation engagement.
3. Limited embedding and customization: Embedding Looker into customer-facing apps or partner portals is expensive and licensing-restrictive. Apache Superset offers a truly embeddable, white-label capable architecture without additional fees. For ISVs and SaaS platforms, this alone can fund a migration in months.

Add Google’s acquisition to the mix. Many data leaders feel the product roadmap now favors Google Cloud integrations over open, heterogeneous data stacks. If you’re running on AWS or Azure, that’s a friction point. We’ve helped firms in platform development in Dallas re-platform their analytics to cloud-agnostic solutions, preserving flexibility without sacrificing speed.

Why Apache Superset Is a Compelling Alternative

Superset started at Airbnb and graduated to the Apache Software Foundation. It’s now the go-to open-source BI layer for modern data teams. Here’s what makes it stick:

• Zero licensing costs: No per-seat fees, no embedded-analytics surcharges. You pay only for the infrastructure you run it on. When we run the numbers for platform development in Australia projects, the TCO reduction typically ranges from 60% to 80% versus a fully loaded Looker contract.
• Rich visualization library: Out-of-the-box chart types rival any commercial tool. Plus, you can author custom plugins via the Superset plugin framework.
• SQL-first and semantic layer friendly: Superset’s SQL Lab is a power user’s dream. For governed, self-service analytics, it supports virtual datasets, saved queries, and — critically — a semantic layer that maps nicely from LookML concepts.
• Massive community and enterprise adoption: Companies like Lyft, Confluent, and countless others run Superset at scale. The community moves fast; contributions in 2025 have already added native dbt integration and improved performance with ClickHouse.
• Compliance-ready architecture: When paired with Vanta, Superset deployments meet SOC 2 and ISO 27001 audit-readiness requirements — a non-negotiable for the private equity portfolio companies we serve through our security audit practice.

Introducing D23.io: A Managed Superset Solution from PADISO

Open-source power meets enterprise reliability. D23.io is PADISO’s managed Superset platform, purpose-built for organizations that want the cost savings of Superset without the operational burden. It’s not just a hosted version — it’s a migration accelerator.

With D23.io, you get:

• One-click deployment on AWS, Azure, or Google Cloud — choose your hyperscaler, we handle the heavy lifting.
• Pre-configured high availability with auto-scaling and database connection pooling tuned for high-concurrency dashboard usage.
• Semantic layer migration tooling: our proprietary adapters translate LookML views and explores into Superset virtual datasets and Jinja templates, cutting rebuild time by up to 70%.
• Embedded analytics in hours: need customer-facing dashboards? D23.io’s embedding mode works with your auth system and respects row-level security without additional license fees.
• Compliance by default: every D23.io instance ships with audit logging, RBAC, and Vanta integration hooks. This accelerates SOC 2 and ISO 27001 readiness — a frequent ask in our platform development in Washington, D.C. and Ottawa engagements where FedRAMP and ITSG-33 considerations loom.

When you’re ready to migrate, PADISO pairs D23.io with fractional CTO services to own the end-to-end cutover. That includes architecture design, data source remapping, dashboard rebuilds, and user training — all mapped to a tight 8–12 week timeline.

Pre-Migration Planning and Assessment

Before touching a single SQL query, invest in a thorough inventory and success definition. Rushing this phase is the number one cause of blown timelines. Here’s what to cover:

Inventory Your Looker Stack

Catalog every asset that matters:

• Dashboards: list by business function, user group, and criticality (tier-1 executive vs. ad-hoc). Note the underlying explores and looks.
• Explores and views: document all LookML files, persisted derived tables, and custom measures. Identify any that rely on Looker-specific functions like liquid parameters or complex native_derived_table patterns.
• Data connections: map each connection string, database dialect (BigQuery, Snowflake, Redshift, Postgres, etc.), and the associated service account or credentials.
• User roles and permissions: export Looker’s group structure and model sets. You’ll need to recreate equivalent RBAC in Superset.
• Schedules and alerts: capture all existing Looks-based schedules, webhooks, and Slack integrations.

This exercise often reveals 20–30% of dashboards that are unused — an opportunity to streamline your analytics estate and boost ROI before the migration even starts.

Define Success Criteria

Agree on measurable outcomes with your stakeholders:

• Time to insight: should dashboard load times stay the same, improve, or accept a slight regression during transition?
• User adoption: what percentage of active Looker users must be successfully migrated within the cutover window?
• Cost reduction: what’s the target annual savings in licensing and infrastructure?
• Data fidelity: define acceptable variance between old and new dashboard numbers (typically <1% for aggregated metrics).

For private equity roll-ups, we often add an EBITDA impact dashboard that tracks realized savings against the cost of the migration itself. That’s standard practice in our CTO as a Service engagements for portfolio companies.

Step-by-Step Migration Process

This is the core playbook. We’ll follow five phases, each with concrete deliverables.

Phase 1: Data Source Remapping

The first technical step is to connect Superset (or D23.io) to the same data sources that powered Looker. Superset supports a wide range of databases — essentially any SQLAlchemy-compatible engine.

Actions:

• Register each database connection in Superset using the database configuration UI. For cloud data warehouses, use service accounts with read-only permissions during development.
• For BigQuery, Snowflake, and Redshift, pay attention to region affinity. When we build platform development in Sydney solutions, we co-locate Superset and the data warehouse in the same AWS / GCP region to minimize latency.
• Test every connection with a simple SELECT 1 or equivalent.
• Bring connections under configuration-as-code: use environment variables or Kubernetes secrets to store credentials, never hard-coded in the UI. This aligns with SOC 2 readiness and repeatable platform engineering patterns.

Deliverable: a connection matrix with verified latency and throughput metrics.

Phase 2: Dashboard Rebuilds

This is the most visible work. The goal is not to replicate Looker dashboards pixel-for-pixel, but to deliver equivalent or better decision support.

Approach:

• Prioritize tier-1 dashboards first (executive, board reporting) and build them natively in Superset using the chart builder.
• For each Looker dashboard, decompose it into the underlying explores. Recreate those as Superset virtual datasets or SQL Lab saved queries.
• Take advantage of Superset’s dashboard filter box and cross-filtering — often you can simplify the user experience compared to Looker’s “explore from here” paradigm.
• Leverage D23.io’s LookML translator: feed it your LookML files, and it generates Jinja-templated SQL and semantic layer YAML, cutting manual translation by half.
• Add Apache ECharts visualizations for richer interactivity.

Comparison check: run old and new dashboards side-by-side for a sample period (e.g., last 30 days) and validate numbers. Use a lightweight dbt test suite to automatically flag discrepancies.

Pro tip: For platform development in Austin where we worked with a semiconductor analytics platform, we rebuilt 47 Looker dashboards in 6 weeks by reusing underlying dbt models as Superset’s semantic layer — no redundant SQL.

Phase 3: Semantic Layer Translation

Looker’s semantic layer is its crown jewel. Superset’s equivalent isn’t identical, but can be made functionally similar.

Key concepts mapping:

• LookML views → Superset virtual datasets or physical views in the database.
• Explores → Superset datasets with a defined main table and join relationships.
• Measures and dimensions → Superset’s metrics and columns, with custom SQL for non-trivial aggregations.
• Persisted derived tables → Materialized views or incremental dbt models.

Our recommended stack: Use dbt as the source of truth for transformations, then expose the resulting tables as Superset datasets. The dbt-superset integration (available since dbt v1.8) automates column-level lineage and metric definitions. This approach future-proofs your migration: you own the transformation logic in Git, not in a BI tool.

For teams that want to preserve a LookML-like authoring experience, we adopt the Preset (managed Superset) semantic layer, or build Jinja templates that mimic Looker’s parameterized explores. Our CTO as a Service clients in Melbourne have successfully migrated 400+ explores in under a month using this pattern.

Phase 4: User Migration and Training

A tool change without user adoption is a failed migration. Treat this as a change management initiative, not a training session.

Plan:

• Map user roles: translate Looker’s Developer, Admin, and Viewer roles into Superset’s Five built-in roles plus custom roles if needed. Connect to your identity provider (Okta, Azure AD, Google Workspace) via OAuth or SAML.
• Create a “Sandbox” Superset environment with the top 5 dashboards for each business unit. Invite champions to explore and give feedback before broad rollout.
• Deliver hands-on workshop: one 90-minute session covering exploration, dashboard creation, and sharing. Record it and publish internally. Emphasize SQL Lab for power users.
• Provide a migration cheat sheet: a one-pager mapping common Looker actions to Superset equivalents (e.g., “Create a Look” → “Save a query as chart”, “Explore from here” → “Drill to detail by” + “Cross-filter”).
• Set up a Slack/Teams support channel for the first month post-cutover.

For platform development in Wellington where we assisted a government department, we ran weekly office hours for 6 weeks. User satisfaction scores ticked up by week 3.

Phase 5: Cutover and Production Rollout

Now it’s go time. Avoid a big-bang cutover — use a phased, data-driven approach.

Timeline:

• Week 1–2: Deploy D23.io production cluster, enable monitoring via Prometheus/Grafana, and run parallel validation of all tier-1 dashboards.
• Week 3: Invite business champions and pilot groups to use Superset exclusively for their daily workflows. Capture bugs and UX gaps.
• Week 4: Publish a “transition complete” communication. Freeze new content creation in Looker; set the old environment to read-only.
• Week 4–6: Sunset Looker dashboards one department at a time. Maintain Looker in read-only for historical access for 30 days post-cutover.
• Post-cutover: Decommission the Looker instance and wipe data per your retention policy.

Rollback plan: Keep the Looker read-only instance online for 30 days. If a critical discrepancy emerges, users can fall back to the old dashboard temporarily. In our experience, rollbacks are needed less than 5% of the time when the validation phase is rigorous.

Advanced Topics and Best Practices

Performance and Scaling

Superset’s query performance is largely determined by the underlying database. However, you can optimize:

• Use Superset’s caching layer with Redis to store query results and chart data.
• For large dashboards, enable asynchronous query execution (Celery workers) to avoid request timeouts.
• Materialize commonly joined tables with ClickHouse-backed materialized columns when you need sub-second response on billions of rows. This is a pattern we leverage in platform development on the Gold Coast for high-frequency tourism dashboards.
• For cloud deployments, autoscale worker pods based on queue depth.

Embedding Analytics

Superset’s embedding capabilities are a game-changer for ISVs. With D23.io, you can generate embed tokens that enforce row-level security without requiring end users to have Superset accounts. That means you can offer white-labeled analytics inside your SaaS product at zero marginal license cost. We’ve seen e-commerce and logistics platforms in Chicago add 7-figure revenue streams by monetizing embedded analytics built on Superset.

Security and Compliance

For SOC 2 and ISO 27001, Superset’s audit logging and RBAC provide a solid foundation. Pair with Vanta for continuous monitoring. Our security audit offering includes pre-configured policies for D23.io that map to SOC 2 controls — reducing audit preparation from months to weeks.

PADISO’s Expertise in Migration and Platform Engineering

A migration of this scale needs more than a tool — it needs operator-grade leadership. PADISO, led by Keyvan Kasaei, steps in as your fractional CTO to run the entire program: discovery, architecture, execution, and outcome measurement. We’ve done this for mid-market companies, private equity portfolios, and venture-backed startups across North America and Australia.

Our platform engineering practice builds the bedrock that Superset sits on. Whether you need low-latency data platforms in New York, multi-tenant SaaS architecture in Austin, or sovereign cloud deployments in Canberra, we bring battle-tested patterns and a ruthless focus on ROI. And because we’re deeply versed in AI strategy and readiness, we can ensure your new analytics stack is ready to serve agentic AI and automation workloads — not just static dashboards.

When private equity firms call us about a roll-up, we often start with a Superset migration as the first visible win: consolidate 3–4 BI tools into one, cut total licensing costs by 70%+, and unify data views for the portfolio. That’s a 6-month EBITDA play that funds further AI-driven value creation. Interested? Book a call.

Measuring Success and Ensuring ROI

After cutover, track metrics that matter to the business:

• Adoption rate: % of active Looker users who logged into Superset in the first 30 days. Target >85%.
• Dashboard freshness: time from data generation to dashboard update. This often improves because you control the pipeline end-to-end.
• Cost per dashboard: calculate fully-loaded infrastructure cost per dashboard per month. We’ve seen numbers drop from $200+ on Looker to under $20 on Superset.
• Time saved: survey analysts on time spent recreating reports. A typical enterprise saves 500+ hours/year in BI maintenance.

For PE-backed companies, we roll these into a quarterly value-creation scorecard — the same kind we use across our venture architecture and transformation mandates.

Common Pitfalls to Avoid

Even with a playbook, things go wrong. Here’s what we see most often — and how to sidestep.

• Underestimating the semantic layer: LookML is deceptively complex. Don’t attempt a manual, one-to-one recreation. Use D23.io’s translator or a dbt-based rebuild. Skipping this leads to metric inconsistencies that erode trust.
• Ignoring user workflows: if you drop a new tool without mapping existing workflows, adoption will tank. Invest in champions and cheat sheets.
• Boiling the ocean: migrate the 20 dashboards that 80% of users rely on first. You can always bring over the long tail later.
• Neglecting compliance from day one: retrofitting SOC 2 controls is painful. Start with Vanta integration and RBAC during the design phase.
• Forgetting about embedding: if your product team was embedding Looker, replicate that in Superset before cutover. D23.io’s embed API makes it straightforward, but it needs lead time.

Summary and Next Steps

Migrating from Looker to Apache Superset is a strategic move that pays back in weeks, not quarters. With zero licensing fees, open standards, and the embedding freedom to monetize analytics, the business case writes itself. But execution is everything. A haphazard migration creates data distrust and delays value realization.

Use this playbook as your North Star. Start with a thorough inventory, move through the five phases methodically, and lean on a managed platform like D23.io to collapse the timeline. If you need an operator who’s done this a dozen times — from the trading floors of Chicago to the government corridors of Ottawa — PADISO’s fractional CTO service is your force multiplier.

Ready to cut your BI spend by 60% or more and build a foundation for AI-driven insight? Get in touch for a migration scoping call. We’ll walk your data environment, identify quick wins, and deliver a fixed-price, fixed-timeline plan. Let’s ship it.