I recently led a full BI platform migration from PowerBI to Looker for a global luxury retail company. 50+ dashboards, 200+ users across 15 countries, and a 6-month timeline. Here's everything I learned.

Why Migrate?

PowerBI is a great tool, but it wasn't working for this organization:

  • Governance nightmare: 300+ reports with no version control, duplicate logic everywhere
  • Performance issues: Import mode datasets hitting refresh limits
  • HQ alignment: Global headquarters was standardizing on Looker
  • Self-service gap: Business users couldn't explore data without IT help

Looker's semantic layer (LookML) promised to solve the governance issues, and the move to BigQuery would address performance.

Phase 1: Discovery (Weeks 1-4)

Audit Everything

Before migrating anything, we needed to understand what existed:

  • Cataloged all 300+ reports (most were unused)
  • Identified 50 "critical" dashboards through usage analytics
  • Documented business logic embedded in DAX measures
  • Mapped data sources and refresh schedules

The 80/20 Rule

80% of users relied on 20% of reports. We prioritized those 50 dashboards for migration and deprecated the rest.

Phase 2: LookML Foundation (Weeks 5-10)

Model Architecture

We organized LookML into three layers: 

├── base/           # Raw table definitions
│   ├── sales.view.lkml
│   ├── products.view.lkml
│   └── customers.view.lkml
├── core/           # Business logic & joins
│   ├── order_facts.view.lkml
│   └── core.model.lkml
└── marts/          # User-facing explores
    ├── sales_explore.lkml
    └── inventory_explore.lkml

Naming Conventions

Consistency matters at scale. Our rules:

  • Views: snake_case, singular nouns (order, not orders)
  • Dimensions: descriptive, no abbreviations (customer_lifetime_value)
  • Measures: verb + noun (total_revenue, count_distinct_customers)
  • Explores: business domain names (Sales Performance)

Reusable Patterns

We built a library of common patterns: 

# Reusable date dimension
view: _date_dimension {
  extension: required
  
  dimension_group: created {
    type: time
    timeframes: [date, week, month, quarter, year]
    sql: ${TABLE}.created_at ;;
  }
  
  dimension: is_current_year {
    type: yesno
    sql: EXTRACT(YEAR FROM ${created_date}) = EXTRACT(YEAR FROM CURRENT_DATE()) ;;
  }
}

Phase 3: Dashboard Migration (Weeks 11-18)

Don't Replicate, Reimagine

The biggest mistake teams make is trying to recreate PowerBI dashboards exactly in Looker. Don't do this. Looker has different strengths:

  • PowerBI: pixel-perfect reports → Looker: exploratory dashboards
  • PowerBI: complex visuals → Looker: simple, filterable tiles
  • PowerBI: static exports → Looker: scheduled deliveries & alerts

User Involvement

For each dashboard, we:

  1. Interviewed the primary users
  2. Identified the actual questions they needed answered
  3. Built a Looker dashboard addressing those questions
  4. Iterated based on feedback

This added time but resulted in better dashboards that people actually used.

Phase 4: DevOps & Governance (Weeks 19-22)

Git Workflow

LookML's biggest advantage is that it's code. We implemented:

  • Branch protection on main
  • Required PR reviews from BI team
  • Spectacles for automated testing
  • CI/CD via GitHub Actions
# .github/workflows/lookml-ci.yml
name: LookML CI
on: [pull_request]
jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: spectacles-ci/spectacles-action@v1
        with:
          looker-url: ${{ secrets.LOOKER_URL }}
          client-id: ${{ secrets.LOOKER_CLIENT_ID }}
          client-secret: ${{ secrets.LOOKER_CLIENT_SECRET }}
          project: my-project
          validator: sql

Content Governance

  • Folder structure: By department, with clear ownership
  • Naming: [Department] Dashboard Name
  • Quarterly reviews: Archive unused content
  • Training: Self-service exploration guidelines

Phase 5: Rollout & Training (Weeks 23-26)

Staged Rollout

  1. Week 1: Power users (10 people) for feedback
  2. Week 2: Department leads (30 people)
  3. Week 3-4: Full organization (200 people)

Training Program

  • 30-min "Getting Started" video
  • Written guides for common tasks
  • Office hours twice weekly for first month
  • Slack channel for questions

Lessons Learned

What Worked

  • Starting with governance: LookML structure before dashboards
  • User interviews: Better dashboards than 1:1 migration
  • Deprecation: Migrating 50 dashboards instead of 300
  • CI/CD: Catching errors before they hit production

What I'd Do Differently

  • Earlier BigQuery optimization: Some queries were slow initially
  • More training time: Users needed longer to adjust
  • Clearer deprecation timeline: Some PowerBI reports lingered

Results

Six months after go-live:

  • Dashboard count: 300 → 50 (83% reduction)
  • Average query time: 45s → 8s
  • Self-service exploration: 0 → 40% of queries
  • Data team support tickets: -60%

Conclusion

BI migrations are as much about change management as technology. The LookML semantic layer is powerful, but only if you invest in governance and training.

Don't migrate reports—migrate the questions your business needs answered.