We moved off Looker because "modern data stack" complexity was killing us. 300 users. 3 months on Power BI. Here's the blunt summary.
**The Good:**
* **Cost:** ~65% lower. Looker's model-based pricing didn't scale for our mostly dashboard-consuming users.
* **Performance:** DirectQuery to our cloud warehouse is faster for our users. LookML compilation became a bottleneck.
* **Operational Simplicity:** No more Git-based development cycle, dedicated LookML developers, or model bloat. Business logic moved to the data layer where it belongs.
**The Bad:**
* **DAX is a tax.** Complex measures are painful. LookML was cleaner for derived metrics.
* **Version control is a joke.** PBIX files in SharePoint isn't a solution.
* **Embedding:** Power BI Embedded API feels clunky compared to Looker's.
We traded a "single source of truth" ideology for a simpler, cheaper, faster tool. The data team grumbles about DAX, but the business gets their reports faster and finance is happy. The "modern" stack isn't always the right stack.
Simplicity is the ultimate sophistication
Marketing ops manager at a 200-person SaaS company. I run our entire email and lead scoring program, and we've used both Looker and Power BI for marketing analytics over the last two years.
**Real TCO for 300 users:** Your ~65% savings tracks. Looker was easily $75k-$90k annually at that scale. Power BI Pro at $10/user/month is $36k, but Premium capacity (needed for serious publishing) adds a $5k/month SKU. The break-even is around 250 heavy users.
**Development & Maintenance:** Power BI's "no-model" setup cuts initial build time by half. But ongoing changes cost you 3x the hours. A simple metric change in LookML took us 20 minutes; rebuilding the PBIX data model and updating all visuals took 2 hours.
**Data Team Skill Tax:** You're right on DAX. We had to hire a contractor for $120/hr to build complex time-intelligence measures (prior period growth, rolling averages). LookML was easier for our SQL-savvy analysts to pick up.
**Embedded Analytics Reality:** Looker's iFrame embed is truly turnkey. Power BI Embedded requires an Azure service principal, managing workspace permissions, and handling token refresh. It added 3-4 weeks to our dev timeline for a customer portal.
I'd pick Power BI for a finance-driven org with mostly static reports and a tight budget. I'd go back to Looker if I had a data-mature team and needed a central metric layer for self-serve. To decide, tell us the percentage of your users who build reports versus just view them, and if you have a dedicated BI developer.
That's a great breakdown on the real ongoing costs. We're planning a smaller migration soon, maybe 50 users.
When you mentioned the > rebuilding the PBIX data model for simple changes, is that always required? I thought you could tweak measures in the service without a full republish, or does that break things?
The embedded part sounds like a nightmare. We were hoping to avoid Looker's cost but still offer customer-facing dashboards. Might have to rethink that.
CloudNewbie
You've hit on the critical operational nuance. For measure changes, it depends entirely on where the logic is defined. If you create a measure directly in the Power BI Service using "Quick measures" or the DAX editor on a published dataset, you can modify it without republishing the PBIX. However, this creates a fragmented, unversioned logic layer that's difficult to manage at scale.
The more sustainable practice, which triggers the full rebuild pain, is when business logic is defined as calculated columns or more complex measures within the PBIX file in Power BI Desktop. Any change to those, or to the underlying data model itself, requires a full republish, which overwrites the dataset in the service and can break existing report pages if you're not careful.
Regarding embedding for customer-facing dashboards, reconsidering is prudent. The Power BI Embedded per-session pricing model is opaque and can become explosively expensive with unpredictable external user traffic. For a 50-user internal team, the Pro license model is straightforward. For external embedding, you're comparing Looker's predictable, user-based cost against a variable, usage-based Azure meter that is notoriously difficult to forecast.
show me the SLA
Your point about trading the "single source of truth" ideology for pragmatism hits home. We made a similar call last year, moving from a complex marketing automation platform to a simpler one.
The DAX pain is real, especially for lead scoring and funnel metrics. We ended up pushing those calculations back into our customer data platform to avoid DAX spaghetti. It's an extra step, but keeps the logic centralized.
Have you found any decent patterns for managing those PBIX files, or is SharePoint truly the only option?
automate the boring stuff
Absolutely, pushing logic back to the CDP is the move. We did the same with our lead scoring stages, and it saved us from some truly gnarly DAX. It also keeps our marketing and sales ops teams on the same page.
> Have you found any decent patterns for managing those PBIX files?
For versioning, it's rough. We use a hybrid approach: source-controlled Tabular Editor scripts for the core dataset logic (measures, relationships). The actual PBIX report files, which are just visuals pointing to that dataset, we treat as disposable and store in SharePoint. It's not perfect, but it separates the business logic from the presentation layer a bit. Still miss the clean Git flow of LookML, though.
Less hype, more data.