Migrating from Looker to Superset for Mid-Market Organisations

Table of Contents

1. Why Mid-Market Teams Are Moving Away from Looker
2. Understanding the Looker-to-Superset Decision
3. Scoping Your Migration
4. Cost Benchmarks and Financial Planning
5. Governance and Security Considerations
6. The Technical Migration Playbook
7. Cutover Patterns and Phased Rollout
8. Managing Stakeholders Through the Transition
9. Post-Migration Optimisation
10. Common Pitfalls and How to Avoid Them

---

Why Mid-Market Teams Are Moving Away from Looker

Looker has been the gold standard for enterprise business intelligence for over a decade. But mid-market organisations—companies with 100–1,000 employees and $10–100M in annual revenue—are increasingly hitting the ceiling of its licensing model and operational overhead.

The core problem is simple: Looker’s per-user seat licensing makes scaling analytics expensive. A mid-market finance team that needs 50 analysts, 30 executives, and 100+ operational users faces licence costs of $50,000–$150,000 annually before any implementation or support. When you add the cost of maintaining a dedicated BI engineer and the learning curve for LookML, the total cost of ownership becomes difficult to justify, especially when open-source alternatives have matured significantly.

Apache Superset has emerged as a credible alternative. It’s free to self-host, requires no per-user licensing, and can be embedded directly into product dashboards or internal tools. For mid-market teams that have already invested in data warehousing (Snowflake, BigQuery, Redshift, ClickHouse), Superset offers a lightweight, cost-effective way to deliver analytics without the Looker premium.

However, the migration itself is not trivial. Looker’s strength lies in its semantic layer and governance model—features that Superset handles differently. A successful migration requires careful planning, realistic scoping, and a phased approach that keeps stakeholders aligned throughout the transition.

---

Understanding the Looker-to-Superset Decision

Why Superset Makes Sense for Mid-Market

Apache Superset is a modern, open-source business intelligence and data visualisation platform that runs on Python and React. Unlike Looker, which is a proprietary SaaS product owned by Google Cloud, Superset can be deployed on your own infrastructure, giving you control over data, compute, and cost.

For mid-market organisations, the value proposition is clear:

• No per-user licensing: Superset charges nothing for seats. You pay only for infrastructure (cloud compute, storage, and optionally managed hosting).
• Embedded analytics: Superset dashboards can be embedded into your product or internal tools without triggering additional licensing.
• Semantic layer flexibility: While Superset doesn’t have LookML, it integrates well with semantic layer tools like Cube, allowing you to rebuild governance logic in a more modular way.
• Lower operational overhead: Superset requires less specialist knowledge than Looker. A mid-size data team can manage it without hiring a dedicated LookML expert.
• Active open-source community: Superset is backed by the Apache Software Foundation and has a growing ecosystem of contributors and vendors.

The catch: you’re trading Looker’s polish and out-of-the-box governance for flexibility and cost savings. That trade-off makes sense for mid-market teams with strong data engineering practices but limited BI budgets.

When Looker Might Still Be the Right Choice

Before committing to a migration, be honest about whether Looker is actually the problem:

• Heavily embedded LookML: If your analytics layer is deeply baked into LookML with complex derived tables and explores, the cost of rewriting that logic in Superset may exceed the licensing savings for 3–5 years.
• Distributed user base: If you have thousands of casual users across the organisation, Looker’s governance and user management may still be worth the cost.
• Regulatory requirements: Some highly regulated industries (financial services, healthcare) have specific requirements around data governance that Looker’s certified architecture handles out of the box. Superset requires more custom work to meet those standards.
• Need for advanced scheduling and alerts: Looker’s scheduling and alerting capabilities are more mature. Superset’s alerting has improved but is still less feature-rich.

If any of these apply to your organisation, a migration may not be cost-effective. Instead, focus on optimising your Looker deployment—reducing seat count, consolidating dashboards, or moving non-strategic users to read-only access.

The Real Cost of Migration

Before diving into the playbook, understand what you’re actually paying for:

• Engineering time: Rebuilding dashboards, migrating data models, and testing. For a mid-market organisation with 50–100 dashboards, budget 3–6 months of engineering effort.
• Downtime risk: If you migrate poorly, you’ll lose visibility into key metrics during the cutover. This is expensive in terms of decision-making and stakeholder trust.
• Retraining: Your analytics team and end users will need to learn Superset’s interface and workflows. Looker and Superset have different mental models for building charts and dashboards.
• Custom development: You may need to build custom plugins, integrate with your existing tools, or develop automation that Looker provided out of the box.

For a typical mid-market organisation, expect total migration costs (engineering, infrastructure, and retraining) of $150,000–$400,000, with payback in 18–36 months depending on your current Looker spend.

---

Scoping Your Migration

Inventory Your Looker Assets

The first step is to know exactly what you’re moving. Create a comprehensive inventory of:

Dashboards: Count total dashboards, categorise by business function (finance, sales, operations, product), and identify which are actively used versus legacy.

Explores and Views: Document all LookML explores, views, and derived tables. This is your semantic layer—understanding its complexity is critical to scoping effort.

Users and Roles: Map user counts by role (viewer, editor, developer, admin). This determines your licensing savings and infrastructure requirements.

Integrations: List all downstream systems consuming Looker data—embedded dashboards, BI tools, alerts, scheduled reports, and APIs.

Custom Code: Identify any custom Looker extensions, JavaScript, or custom visualisations that won’t translate directly to Superset.

A mid-market organisation typically has:

• 50–150 active dashboards
• 20–50 explores
• 100–500 total users (but only 10–30 active editors)
• 5–15 critical integrations

Create a spreadsheet with this data. You’ll use it to prioritise which assets to migrate first and which to retire.

Prioritise by Business Impact

Not all dashboards are equal. Prioritise based on:

• Usage frequency: Focus on dashboards viewed daily or weekly. Retire those viewed less than monthly.
• Critical decision-making: Prioritise dashboards used for revenue, cash flow, customer health, and operational metrics.
• Downstream dependencies: If a dashboard feeds into an automated report or embedded product, it’s higher priority.
• Stakeholder visibility: Executive dashboards and board-level reporting should be in the first wave.

Aim to migrate 60–70% of your dashboard volume in the first phase. The remaining 30–40% can be retired, rebuilt on-demand, or migrated later as time permits.

Define Your Target Architecture

Before you start building in Superset, decide on your architecture:

Self-hosted vs. Managed: Will you run Superset on your own Kubernetes cluster, or use a managed provider like Preset? Self-hosted gives you control and lower costs; managed reduces operational overhead.

Semantic Layer Strategy: Will you use Superset’s native SQL abstraction, or layer in a semantic tool like Cube? A semantic layer gives you governance similar to LookML but requires additional infrastructure.

Data Warehouse: Confirm which warehouse(s) Superset will connect to. If you’re using Snowflake, BigQuery, Redshift, or ClickHouse, Superset has native connectors. If you’re on a less common platform, you may need custom drivers.

Embedding Strategy: If you embed dashboards in your product, decide whether to use Superset’s native embedding or a third-party tool. This affects your infrastructure and licensing choices.

For most mid-market organisations, the target architecture looks like this:

• Superset deployed on a shared Kubernetes cluster or managed Superset service
• Native SQL abstraction for simple dashboards, with a semantic layer (like Cube) for complex metrics
• Direct connections to your existing data warehouse
• Embedded dashboards in product using Superset’s guest token or iframe approach

---

Cost Benchmarks and Financial Planning

Looker Licensing Costs

Understanding your current Looker spend is the baseline for your business case.

Looker pricing is per-user, with tiers for Viewer, Editor, and Developer roles:

• Viewer: ~$4/user/month (read-only access)
• Editor: ~$8/user/month (can create and edit dashboards)
• Developer: ~$15/user/month (full LookML access)

For a mid-market organisation with 200 total users (150 viewers, 40 editors, 10 developers), annual Looker licensing runs approximately:

(150 × $4 × 12) + (40 × $8 × 12) + (10 × $15 × 12) = $7,200 + $3,840 + $1,800 = $12,840 annually

But most mid-market organisations also pay for:

• Professional services: $20,000–$50,000 for implementation and ongoing support
• Consulting: $15,000–$30,000 for LookML development and optimisation
• Infrastructure: If Looker is on-premises, add cloud compute and storage costs

Total annual Looker cost for a typical mid-market organisation: $50,000–$150,000

Superset Infrastructure Costs

Superset has no licensing fees, but you pay for infrastructure:

Self-hosted on Kubernetes:

• Kubernetes cluster: $2,000–$5,000/month (shared across other workloads)
• Superset pods (compute): $500–$1,500/month
• Database (PostgreSQL or similar for Superset metadata): $300–$800/month
• Monitoring and logging: $200–$500/month
• Total: $3,000–$8,000/month or $36,000–$96,000 annually

Managed Superset (Preset or similar):

• Preset standard tier: ~$1,000–$3,000/month depending on usage
• Total: $12,000–$36,000 annually

Data warehouse costs (not incremental, but relevant):

• Snowflake, BigQuery, or Redshift charges are typically based on query volume and compute. A migration to Superset may increase query volume slightly (10–20%) due to different query patterns, but this is usually offset by better caching and optimisation.

Migration Costs

Engineering effort: Budget 3–6 months of mid-level data engineer time:

• Senior data engineer: $150–$200/hour
• Mid-level data engineer: $100–$150/hour
• Junior data engineer: $60–$100/hour

For a typical mid-market migration (50–100 dashboards), expect 500–1,000 hours of engineering effort. At an average loaded cost of $120/hour, that’s $60,000–$120,000.

Infrastructure setup: $10,000–$30,000 for initial Kubernetes setup, security hardening, and integrations.

Testing and validation: $10,000–$20,000 for QA, user acceptance testing, and cutover validation.

Training and change management: $5,000–$15,000 for user training and documentation.

Total migration cost: $85,000–$185,000

Payback Period

For a mid-market organisation currently spending $100,000/year on Looker:

• Year 1: Migration cost ($150,000) + Superset infrastructure ($50,000) = $200,000. Looker savings: $100,000. Net cost: $100,000.
• Year 2: Superset infrastructure ($50,000). Looker savings: $100,000. Net savings: $50,000.
• Year 3+: Superset infrastructure ($50,000). Looker savings: $100,000. Annual savings: $50,000.

Payback period: 18–24 months

If your Looker spend is higher (e.g., $150,000+) or your engineering costs are lower (e.g., offshore team), payback accelerates to 12–18 months.

---

Governance and Security Considerations

Rebuilding Governance Without LookML

Looker’s governance model is baked into LookML. Every metric, dimension, and measure is defined once and reused across dashboards. This prevents metric sprawl and ensures consistency.

Superset doesn’t have a built-in semantic layer like LookML. Instead, you have options:

Option 1: SQL Abstraction at the Database Level Create views and materialized tables in your data warehouse. Superset queries these directly. This is simple but puts governance burden on your data engineering team.

Option 2: Semantic Layer Tool Use Cube or a similar semantic layer to define metrics and dimensions. Superset connects to Cube via its native API. This gives you LookML-like governance with more flexibility.

Option 3: Superset Datasets and Metrics Superset has a native dataset and metric system. You define datasets (which are SQL queries or tables) and metrics (aggregations) in Superset itself. This is less powerful than LookML but simpler to manage for mid-market teams.

For most mid-market organisations, Option 2 (Semantic Layer) is the sweet spot. It provides governance without the complexity of LookML, and it’s portable—if you ever switch BI tools again, your semantic layer goes with you.

Access Control and Row-Level Security

Looker has built-in row-level security (RLS) via user attributes and filters. Superset’s RLS is less mature but improving.

Superset RLS approaches:

• Database-level RLS: Define row filters at the warehouse level (e.g., BigQuery row policies, Snowflake dynamic data masking). Superset respects these automatically.
• Superset native RLS: Use Superset’s row-level security rules to filter data based on user attributes. This requires more configuration but works across all databases.
• Embed-time filtering: For embedded dashboards, pass user context at embed time to filter data dynamically.

For highly regulated data (financial, health, PII), database-level RLS is more secure and easier to audit. Superset’s role-based access control (RBAC) for dashboards and datasets works similarly to Looker’s.

Compliance and Audit Trail

If you’re pursuing SOC 2 or ISO 27001 compliance, Superset requires more custom work than Looker:

• Audit logging: Superset logs user actions (dashboard views, query execution, etc.) to its metadata database. You can export these to a SIEM for compliance reporting.
• Data lineage: Superset doesn’t track data lineage as well as Looker. You’ll need to document lineage separately or use a data cataloguing tool.
• Access control: Implement RBAC in Superset and sync with your identity provider (Okta, Azure AD) for consistent access management.

Many mid-market organisations use Vanta to automate compliance evidence collection. Superset integrates with Vanta’s API, making it easier to track access controls and audit logs for SOC 2 and ISO 27001 compliance.

For teams pursuing SOC 2 or ISO 27001, budget an additional 2–4 weeks of effort to harden Superset’s security posture and integrate with your compliance tooling.

---

The Technical Migration Playbook

Phase 1: Preparation and Infrastructure (Weeks 1–4)

Set up Superset infrastructure:

1. Provision a Kubernetes cluster or sign up for managed Superset.
2. Deploy Superset with production-grade security: TLS, authentication (OAuth2 or SAML), and network isolation.
3. Configure your data warehouse connections. Test connectivity and query performance.
4. Set up monitoring, logging, and alerting for Superset itself.

Prepare your data warehouse:

1. Audit your existing Looker explores and identify the underlying SQL.
2. Create views or semantic layer definitions for the most-used metrics and dimensions.
3. Optimise warehouse performance: add indexes, partition tables, and materialise frequently-queried aggregations.

Establish migration governance:

1. Create a dashboard inventory spreadsheet with status tracking.
2. Assign owners for each dashboard (usually the business stakeholder who uses it).
3. Define testing criteria: what does it mean for a migrated dashboard to be “ready”?
4. Set up a migration calendar with target dates for each wave.

Phase 2: Pilot Migration (Weeks 5–8)

Select 5–10 pilot dashboards: Choose dashboards that are:

• Actively used but not mission-critical (so failures don’t break the business)
• Representative of your dashboard diversity (simple charts, complex explores, embedded dashboards)
• Owned by engaged stakeholders who will provide feedback

Rebuild dashboards in Superset:

1. For each Looker dashboard, extract the underlying SQL or LookML.
2. Rebuild the dashboard in Superset using native SQL or semantic layer definitions.
3. Match the visual design as closely as possible (colours, layout, drill-downs).
4. Test with real data and validate numbers against Looker.

User acceptance testing (UAT):

1. Share pilot dashboards with business owners.
2. Gather feedback on usability, performance, and accuracy.
3. Iterate based on feedback (usually 1–2 rounds).
4. Document any gaps or missing functionality.

Lessons learned:

1. After the pilot, hold a retrospective with your team.
2. Document what worked, what didn’t, and what you’d do differently.
3. Update your migration playbook based on learnings.

Phase 3: Full Migration (Weeks 9–24)

Wave-based rollout: Migrate dashboards in waves based on priority:

• Wave 1 (Weeks 9–12): 15–20 high-priority dashboards (executive, finance, sales)
• Wave 2 (Weeks 13–16): 20–30 medium-priority dashboards (operations, product)
• Wave 3 (Weeks 17–20): 15–20 lower-priority dashboards (legacy, departmental)
• Wave 4+ (Weeks 21–24): Remaining dashboards, custom development, edge cases

For each wave:

1. Assign dashboards to engineers based on complexity and domain knowledge.
2. Set a target completion date (usually 2 weeks per 10 dashboards).
3. Conduct internal QA before handing off to business owners.
4. Run parallel testing: keep the Looker dashboard live while the Superset version is being tested.

Parallel testing pattern:

• Week 1: Superset dashboard is built and internally validated.
• Week 2: Business owner tests Superset dashboard in parallel with Looker. Feedback is collected.
• Week 3: Issues are fixed, final sign-off is obtained.
• Week 4: Looker dashboard is deprecated, users are directed to Superset.

This pattern reduces risk because users always have a working dashboard to fall back to.

Phase 4: Cutover and Decommissioning (Weeks 25–26)

Final cutover:

1. Set a cutover date (ideally a Friday so you have the weekend for troubleshooting).
2. Notify all users 2 weeks in advance.
3. On cutover day:
   • Disable access to Looker dashboards (or redirect to Superset).
   • Monitor Superset for errors and performance issues.
   • Have on-call support available for 48 hours.

Looker decommissioning:

1. After 2–4 weeks of Superset running smoothly, begin decommissioning Looker.
2. Export any remaining reports or metadata for archival.
3. Cancel Looker licences and remove infrastructure.
4. Redirect any remaining Looker URLs to Superset equivalents.

---

Cutover Patterns and Phased Rollout

The Big Bang vs. Phased Approach

Big Bang Cutover: Migrate all dashboards at once, disable Looker, and switch users over on a single date.

Pros: Faster overall timeline, simpler to manage (one cutover event). Cons: High risk of failure, difficult to troubleshoot issues affecting many dashboards simultaneously, users have no fallback.

Phased Rollout: Migrate dashboards in waves over 4–6 months, with each wave having its own cutover date.

Pros: Lower risk per wave, easier to troubleshoot, users can adapt gradually, you can pause or adjust based on learnings. Cons: Longer overall timeline, requires maintaining both systems in parallel, more complex change management.

Recommendation for mid-market: Phased rollout with 3–4 waves over 4–6 months. This balances risk and speed. The overhead of running both systems in parallel is worth the reduced risk and better user experience.

Wave Planning

Wave 1: Foundation (Weeks 1–4)

• 10–15 high-priority dashboards
• Executive dashboards, financial reporting, key operational metrics
• Owned by engaged stakeholders
• Goal: Prove that Superset works and build confidence

Wave 2: Expansion (Weeks 5–8)

• 15–20 medium-priority dashboards
• Sales, marketing, product analytics
• Build momentum and expand user adoption

Wave 3: Completion (Weeks 9–12)

• Remaining dashboards, including edge cases
• Retire dashboards that are no longer needed
• Final cleanup and optimisation

Wave 4: Optimisation (Weeks 13+)

• Address any performance issues or missing features
• Retire Looker infrastructure
• Invest in advanced Superset features (alerts, scheduled reports, custom visualisations)

Managing Parallel Systems

During the phased rollout, you’ll run Looker and Superset in parallel. This adds complexity but is necessary for a safe migration.

Strategies to manage parallel systems:

1. URL redirects: Create a redirect layer that points users to the appropriate system. As dashboards migrate, update the redirects.
2. Unified dashboard home: Build a landing page that links to both Looker and Superset dashboards, clearly labelled as “legacy” or “new”.
3. Automated testing: Set up automated tests that compare Looker and Superset results for each dashboard. This catches discrepancies early.
4. Clear communication: Tell users exactly which dashboards are moving and when. Provide training and support for the new system.

---

Managing Stakeholders Through the Transition

Building the Business Case

Before you start migrating, you need buy-in from leadership. The business case should focus on concrete outcomes:

• Cost savings: $50,000–$100,000 annually in licensing and support.
• Faster dashboard development: Superset is simpler than LookML, so new dashboards take less time.
• Reduced vendor lock-in: Superset is open-source, so you’re not tied to Google Cloud.
• Better embedding: Superset makes it easier to embed analytics in your product.

Avoid vague claims like “more flexible” or “better governance”. Instead, tie everything to business outcomes: faster time-to-insight, lower cost, or reduced risk.

Communication Plan

Phase 1: Announcement (Week 1)

• Send a company-wide email explaining why you’re migrating and what it means for users.
• Highlight the benefits (cost savings, faster dashboards, no licence fees).
• Set expectations: dashboards will look slightly different, but functionality will be the same.
• Provide a timeline and FAQ.

Phase 2: Wave Planning (Weeks 2–4)

• For each wave, notify affected users 2 weeks in advance.
• Provide training materials: videos, documentation, and live Q&A sessions.
• Assign a “champion” in each department to help with adoption.

Phase 3: Migration (Weeks 5–26)

• Send weekly updates on progress.
• Highlight wins: “Sales dashboards are now live in Superset. 50 users are already using them.”
• Address concerns quickly. If a user reports an issue, prioritise it.
• Celebrate milestones: “We’ve successfully migrated 50 dashboards. Only 20 to go!”

Phase 4: Decommissioning (Weeks 27+)

• Announce the Looker sunset date (usually 2–4 weeks after the final wave).
• Provide final training and support.
• After sunset, redirect any remaining Looker URLs to Superset equivalents.

Training and Support

Training materials:

• Video tutorials: 5–10 minute videos on common tasks (creating charts, filtering data, exporting results).
• Written documentation: Step-by-step guides for common workflows.
• Interactive training: Live sessions where users can ask questions.
• Office hours: Weekly drop-in sessions where users can get help.

Support structure:

• Tier 1: Self-service documentation and community forums.
• Tier 2: Email support from your analytics team (24–48 hour response time).
• Tier 3: Escalation to your Superset infrastructure team for bugs or performance issues.

Common questions and answers:

• Q: Will my dashboards work the same way? A: Mostly yes. Superset uses the same data and produces the same charts, but the interface is slightly different. We’ve provided training to help you get up to speed.
• Q: What if I find a bug in the new system? A: Report it immediately. We have a dedicated team monitoring Superset and will prioritise critical issues.
• Q: Can I still access Looker after the migration? A: For a limited time, yes. But we recommend switching to Superset as soon as possible to avoid confusion.

---

Post-Migration Optimisation

Performance Tuning

After migration, your Superset dashboards may not perform as well as Looker. This is often due to inefficient queries or missing database optimisations.

Optimisation steps:

1. Profile query performance: Use your data warehouse’s query profiler (BigQuery’s query execution, Snowflake’s query history) to identify slow queries.
2. Add indexes: Create indexes on commonly filtered columns (date, user ID, product ID).
3. Materialise common aggregations: If many dashboards use the same aggregation (e.g., daily revenue), materialise it as a table or view.
4. Cache frequently-used datasets: Superset supports caching. Configure cache TTLs for datasets that don’t need real-time updates.
5. Optimise chart queries: Rewrite complex SQL to be more efficient. Often, a small change (e.g., using a WHERE clause instead of a HAVING clause) dramatically improves performance.

For a typical mid-market migration, post-migration optimisation reduces query times by 20–50%.

Feature Expansion

After the migration is stable, invest in features that Looker didn’t provide:

• Alerts and notifications: Set up alerts that notify users when key metrics exceed thresholds.
• Scheduled reports: Configure dashboards to be emailed to stakeholders on a schedule.
• Custom visualisations: Add custom charts or plugins that your team needs.
• Semantic layer enhancements: If you’re using Cube, add more complex metrics and dimensions.
• Embedded analytics: Build embedded dashboards in your product or internal tools.

Many of these features are easier to implement in Superset than in Looker because Superset is more customisable.

Knowledge Transfer

Document everything you learned during the migration:

• Architecture decision log: Why did you choose self-hosted vs. managed? Why did you pick Cube over native SQL? This helps future team members understand the system.
• Runbooks: Document how to perform common operations (adding a new data source, creating a dashboard, troubleshooting performance).
• Disaster recovery plan: How do you recover if Superset goes down? How do you backup dashboards and metadata?
• Lessons learned: What went well? What would you do differently? This is gold for future migrations or projects.

---

Common Pitfalls and How to Avoid Them

Pitfall 1: Underestimating the Semantic Layer

Problem: You assume you can just point Superset at your warehouse and rebuild dashboards using raw SQL. But without a semantic layer, metric definitions become scattered across hundreds of SQL queries, leading to inconsistency and confusion.

Solution: Invest in a semantic layer from the start. Use Cube or a similar tool to define metrics and dimensions once, then reuse them across dashboards. This takes 2–4 weeks but saves months of rework later.

Pitfall 2: Ignoring Performance Until Too Late

Problem: You migrate dashboards and they work fine in testing, but when users start using them in production, query times balloon. You’re forced to optimise reactively, which is slow and frustrating.

Solution: Profile query performance during the pilot phase. Identify slow queries early and optimise your warehouse before the full migration. Set performance targets (e.g., all dashboards load in < 5 seconds) and enforce them during QA.

Pitfall 3: Losing Governance

Problem: In Looker, metrics were defined in LookML and reused everywhere. In Superset, without a semantic layer, each dashboard has its own SQL. Soon, you have 10 different definitions of “revenue” across your dashboards.

Solution: Implement a semantic layer or establish SQL standards. Create a style guide for writing queries, use version control for dashboard definitions, and enforce code review before dashboards go live.

Pitfall 4: Rushing the Cutover

Problem: You’re eager to shut down Looker and save money, so you cut over before all dashboards are fully tested. Users find bugs in production, and you’re forced to keep Looker running longer than planned.

Solution: Use the phased rollout approach. Don’t cutover until you’re confident the dashboard is correct. Run parallel testing for at least 2 weeks before switching users over.

Pitfall 5: Neglecting User Adoption

Problem: You migrate dashboards to Superset, but users don’t know how to use the new system. They get frustrated and ask to go back to Looker.

Solution: Invest in training and change management. Provide clear documentation, run live training sessions, and assign champions in each department. Make the transition as smooth as possible.

Pitfall 6: Not Planning for Edge Cases

Problem: You migrate the top 80% of dashboards easily, but the remaining 20% have weird dependencies, custom code, or unusual data requirements. These become a long tail of unfinished work.

Solution: During scoping, identify edge cases early. Decide whether to rebuild them in Superset, retire them, or keep them in Looker. Don’t let edge cases derail your migration timeline.

---

Conclusion and Next Steps

Migrating from Looker to Superset is a significant undertaking, but for mid-market organisations, the cost savings and flexibility often justify the effort. A successful migration requires:

1. Clear business case: Understand your current Looker spend and the payback period for migration.
2. Realistic scoping: Inventory your assets, prioritise high-impact dashboards, and plan for 3–6 months of effort.
3. Strong governance: Implement a semantic layer or establish SQL standards to maintain consistency.
4. Phased rollout: Migrate dashboards in waves with parallel testing to reduce risk.
5. User-centric approach: Invest in training, communication, and support to drive adoption.
6. Post-migration optimisation: Profile performance, add features, and document learnings.

If you’re considering this migration, start with a pilot. Select 5–10 representative dashboards, rebuild them in Superset, and validate that the approach works for your organisation. The pilot will surface risks early and give you confidence to proceed with the full migration.

For mid-market organisations with strong data engineering practices and tight BI budgets, Superset is a compelling alternative to Looker. The migration requires discipline and planning, but the long-term cost savings and operational flexibility make it worthwhile.

If you need help scoping or executing a Looker-to-Superset migration, consider partnering with a platform engineering team experienced in data architecture. Teams across Australia and the United States have successfully guided mid-market organisations through similar transitions, reducing risk and accelerating time-to-value.

Specialised teams in key markets—such as Sydney, Melbourne, New York, and Washington, DC—can provide hands-on support for data architecture, semantic layer design, and Superset deployment. For government and public-sector teams, specialists in Canberra and Ottawa understand sovereign cloud and compliance requirements.

Start your migration planning today. The sooner you move off Looker’s per-user licensing, the sooner you’ll realise the cost and operational benefits of Superset.