Co-authored by

Why BI Migration Mistakes Cost More Than the Migration

Quick answer: The most common BI migration mistakes — rebuilding reports 1:1, skipping the parallel run, sizing Fabric capacity by guesswork — routinely double a project's cost. None of them are technical surprises. They are planning decisions made in week one that surface as overruns in month four.

A migration from Tableau, Qlik, or Cognos to Power BI is a budgeted project with a defined end date, which is exactly why it goes wrong in predictable ways. The team commits to a scope before auditing what actually needs to move. Licensing gets estimated from a vendor slide instead of real usage. The old platform stays on "for safety" and quietly doubles the run cost for a year.

This post covers the ten BI migration mistakes we see most often in enterprise projects across the UAE and Saudi Arabia, drawn from the patterns documented in our Tableau, Qlik, and Excel migration guides and the 500-seat enterprise case study. Each mistake comes with the fix.

Where they bite, at a glance:

Mistake 1: Rebuilding Every Report 1:1 on the New Platform

Quick answer: Recreating each legacy report pixel-for-pixel in Power BI is the single most expensive BI migration mistake. It forces Power BI to imitate another tool's architecture, triples build effort, and ships the old platform's problems to the new one.

The instinct is understandable. Users know their reports, so the safest-looking promise is "everything will look the same." But Tableau workbooks, Qlik apps, and Cognos report packages encode the design assumptions of their own engines. A Tableau dashboard with six worksheets and quick filters maps badly onto a Power BI report page; a Cognos package with nested report layers maps even worse. Forcing the copy means fighting the semantic model instead of using it.

Microsoft's own migration guidance is blunt on this point: rather than migrating reports precisely as they appear in the legacy platform, focus on the business question each report answers. In practice that consolidates reports too — we have seen a dozen single-purpose legacy reports collapse into one Power BI report with field parameters and bookmarks.

What to do instead: Treat the legacy report as a requirements document, not a blueprint. For each one, write down the decision it supports, redesign around a shared semantic model, and consolidate where questions overlap. Budget redesign time per business question, not per report file.

Mistake 2: Migrating Reports Nobody Uses

Quick answer: Most enterprise BI estates carry a long tail of reports with zero views in the last quarter. Migrating them wastes 30–50% of project scope. Audit usage first and migrate only what earns its place.

Ask a BI team how many reports they have and you will get a number like 800. Ask how many were opened last month and the honest answer is usually a fraction of that — in the usage audits we run before migrations, 30–50% of the nominal report count never survives review. Legacy platforms accumulate duplicates, one-off exports that became "official," and dashboards built for managers who left years ago. Every one of those carried into the migration plan inflates the estimate, the timeline, and the testing matrix.

This is also the cheapest mistake to avoid, because the evidence already exists. Tableau Server, Qlik Sense, and Cognos all expose usage logs. Stage 1 of Microsoft's migration series is explicitly about gathering requirements and prioritizing: an inventory ranked by usage and business criticality, not an alphabetical list.

What to do instead: Pull 6–12 months of usage data before scoping anything. Classify every asset: migrate-and-redesign, consolidate, archive, or kill. Get business owners to sign the kill list — silence is approval. A scope cut from 800 reports to 220 is the same migration, minus the dead weight.

Mistake 3: Ignoring Data Quality Until After Cutover

Quick answer: A migration faithfully reproduces whatever data problems the old platform had — then gets blamed for them. Profile and fix source data quality before building semantic models, not after users dispute the first dashboard.

There is a special kind of project pain that arrives the week after go-live: the new Power BI numbers do not match the old Tableau numbers, and nobody can say which one is right. Sometimes the legacy report was silently filtering out bad rows. Sometimes three departments maintained three customer lists. The migration did not create the problem, but the migration team owns it now, and "the new tool is wrong" becomes the story.

Hidden data quality debt also wrecks estimates. A semantic model built on clean, conformed dimensions takes a fraction of the time of one built on sources that need fixing mid-build. If the plan assumes clean data and the data is not clean, the variance lands entirely on the build phase.

What to do instead: Profile the sources during scoping — duplicate keys, orphaned records, inconsistent business definitions across systems. Fix what you can upstream, document what you cannot, and agree reconciliation rules with finance before the first model ships. A proper star schema is much easier to build when the dimensions are agreed first.

Mistake 4: Underestimating the DAX Learning Curve

Quick answer: DAX is a different evaluation model built on filter context, not a syntax swap for Tableau calculated fields or Qlik expressions. Teams that budget a week for "formula conversion" usually need four to six, and the measures written in week one tend to need rewriting.

Tableau LOD expressions, Qlik set analysis, and Cognos expressions all have rough DAX equivalents, but the mapping is conceptual, not mechanical. CALCULATE modifies filter context in ways that have no direct Tableau parallel; row context versus filter context trips up experienced analysts for weeks. Our LOD-to-DAX translation guide exists because this is consistently the hardest skill transition in a Tableau migration.

The cost shows up twice. First in the timeline, when "convert the calculations" runs long. Then in performance, when measures written by DAX beginners (iterator-heavy, blind to context transition) make a model crawl at production data volumes and need a rewrite pass anyway.

What to do instead: Train the team before the build phase, not during it. Microsoft Learn's DAX modules plus a few weeks of practice on real company data work; so does pairing internal analysts with an experienced DAX developer who reviews every measure in the first month. Adopt DAX standards from day one and treat measure review like code review.

Mistake 5: Skipping the Parallel Run

Quick answer: Running the old and new platforms side by side for one or two reporting cycles is the only reliable way to validate numbers and build user trust. Cutting over without it turns every discrepancy into a production incident.

The parallel run gets cut for an honest-sounding reason: it costs money to run two platforms at once, and the project is already over budget (often because of mistakes 1–4). But the alternative is worse. Without a parallel period, the first month-end close on Power BI is also the first real test of every measure, refresh schedule, and security rule — with no trusted baseline to reconcile against.

Microsoft's migration framework treats deployment as a staged activity with support and monitoring, not a switch-flip, and notes that migration almost always happens in parallel with new Power BI development. The parallel run is where finance signs off that YTD revenue matches to the dirham, and where refresh failures surface while the old report still exists as a fallback.

What to do instead: Plan a parallel run of at least one full reporting cycle — month-end for finance estates, ideally a quarter-end. Define reconciliation tolerances up front, log every variance with a root cause, and make business sign-off on the reconciliation the formal gate for decommissioning. Budget the dual-running cost from the start so nobody is tempted to skip it.

Mistake 6: Leaving Governance for "Phase 2"

Quick answer: Workspace structure, naming standards, certified datasets, and access policies must exist before the first production report ships. Retrofitting governance onto six months of organic sprawl costs more than the original migration.

A migration without a governance framework succeeds briefly and then drowns. Every team creates its own workspace. Three versions of the sales model appear, each "certified" by whoever built it. Row-level security gets configured per report instead of per model. Twelve months later the new platform has reproduced the exact chaos that motivated leaving the old one — and an internal audit in a UAE bank or Saudi government entity will find it.

This matters more in the Gulf than the generic advice suggests. Data residency rules, UAE PDPL obligations, and sector regulators mean workspace and tenant decisions are compliance decisions. Microsoft's Fabric adoption roadmap treats governance and the center of excellence as foundations, not follow-ups.

What to do instead: Stand up the minimum viable framework before the first workload migrates: workspace taxonomy (dev/test/prod), a certified-dataset process, naming conventions, RLS patterns, and a deployment pipeline. Our Fabric adoption roadmap for UAE and Saudi enterprises covers the sequencing. One page of enforced standards beats a 40-page policy nobody reads.

Mistake 7: Sizing the Fabric SKU Wrong

Quick answer: Fabric capacity runs from F2 to F2048, and the jump that matters is F64 — the threshold where viewers with free licenses can consume Power BI content. Sizing by guesswork either overspends from day one or throttles refreshes within a quarter.

Two failure modes, opposite directions. The cautious team buys F64 reserved for 80 users "to be safe," paying capacity prices when Pro licenses at $14/user/month would cover the same audience for far less. The optimistic team buys F16 for 600 viewers, discovers every viewer below F64 still needs a Pro or PPU license per Microsoft's licensing rules, and lands an unbudgeted licensing bill mid-project.

The break-even arithmetic is straightforward but rarely done: viewer count, refresh workload, and model size determine whether per-user, capacity, or a mix wins. Our Pro vs PPU vs Fabric comparison walks the full decision, and the licensing cost optimization guide covers tuning after go-live.

What to do instead: Model licensing from the real audience count and the parallel-run telemetry. Start pay-as-you-go, measure capacity utilization for a billing cycle or two, then commit to a reservation once the steady-state load is known; Microsoft prices reservations roughly 40% below pay-as-you-go.

Mistake 8: Running the Migration as an IT-Only Project

Quick answer: A BI migration scoped, built, and validated entirely inside IT delivers technically correct reports that the business does not trust or use. Business owners must hold the scope decisions, definitions, and sign-offs.

When the migration lives only in IT, requirements get read from the old reports instead of from the people who use them — which is how mistakes 1 and 2 happen. Metric definitions get translated without anyone confirming that "active customer" should still mean what a 2019 Cognos developer decided it meant. And at go-live, the business receives the new platform as a surprise rather than a thing they shaped.

We see the same split across migration projects: the ones that finish on budget have a business sponsor who makes scope calls in days, department owners who validate their own numbers during the parallel run, and finance in the room when reconciliation tolerances are set. The ones that overrun have IT chasing sign-offs from stakeholders who never agreed to the plan. The ROI business case only survives contact with reality when the people who own the savings also own decisions.

What to do instead: Name an executive sponsor with real authority — Microsoft lists this first among its migration success factors. Give every report domain a business owner responsible for the keep/kill call, the definitions, and the parallel-run sign-off. IT owns the platform; the business owns what runs on it.

Mistake 9: No Change Management or Adoption Plan

Quick answer: Users do not switch BI tools because a new one exists. Without training, communication, and visible champions, they export to Excel from the old platform until it dies — and then complain. Adoption work is a project workstream, not an email at the end.

The hard costs of this mistake hide in the licensing line. If 400 users keep working in Tableau while Power BI sits ready, you are paying for both platforms during the exact period the budget assumed only one. Adoption lag is the most common reason a "9-month migration" pays 15 months of dual licensing.

The scale of the risk is well documented: Forrester's Boris Evelson has estimated that no more than 20% of decision-makers who could use BI hands-on actually do so. A migration that ignores adoption inherits that ceiling.

There is also a quieter failure: resistance from the people whose expertise lives in the old tool. A Qlik developer with ten years of set-analysis fluency has rational reasons to slow-walk a Power BI rollout. Microsoft's migration guidance names resistance to change explicitly. Pretending it away does not work.

What to do instead: Run adoption as a workstream with an owner and a budget — typically 10–15% of project cost. Train by role, not by tool tour: analysts need DAX and modeling, consumers need a 30-minute "where is my report" session in Arabic and English where relevant. Recruit one champion per department, publish a cutover calendar, and track active usage per department weekly so lagging teams are visible early.

Mistake 10: Switching Off the Old Platform Too Early

Quick answer: Decommissioning the legacy platform before the new one has survived a full reporting cycle — including quarter-end and audit season — removes your only fallback and your reference data. Cut licenses in stages, keep read-only access through one full cycle, and archive before you delete.

After nine mistakes about moving too slowly, the last one is about moving too fast. Once Power BI go-live is declared, someone reasonably asks why the Tableau or Cognos contract is still being paid. The renewal date becomes the deadline, and the platform gets switched off before the new estate has been through a quarter-end close, a board pack, or an external audit request that needs three-year-old report outputs.

Then a regulator or auditor asks for a 2023 report exactly as it was published, and the platform that rendered it is gone. Or a critical reconciliation breaks in month two and the trusted baseline no longer exists. Emergency re-licensing a decommissioned enterprise BI platform is as expensive and humiliating as it sounds.

What to do instead: Decommission in stages: freeze new development at go-live, drop to read-only at parallel-run sign-off, and terminate after one full reporting cycle plus an archive of regulatory-relevant outputs (PDF or extract, stored independently). Time the migration plan against the legacy renewal date from the start — that date is a forcing function you want working for you, not against you.

What a Migration That Holds Its Budget Looks Like

Quick answer: Budget-stable migrations follow the same sequence: usage audit, business-owned scope, governance and training before the build, redesign on a shared semantic model, a full parallel reporting cycle, then staged decommissioning timed to the legacy renewal date.

Nothing in this list is exotic. Microsoft's five-stage framework — requirements, deployment planning, proof of concept, content creation, deploy and monitor — already encodes most of it. The mistakes happen when commercial pressure (a renewal date, a budget cycle) pushes teams to skip the unglamorous stages: the usage audit, the data profiling, the parallel run.

The pattern from projects that land on budget, including the 500-seat Tableau migration we documented: scope shrinks at the audit stage, grows back slightly during redesign, and the parallel run catches discrepancies while they are still cheap. Cost comparisons like Cognos vs Power BI only hold if the migration itself does not burn the projected savings.

If you are planning a migration in the UAE, Saudi Arabia, or the wider Gulf, Beyond The Analytics runs migration readiness assessments that score your estate against exactly these failure modes — usage audit, data quality profile, licensing model, governance baseline — before you commit a budget.

Frequently Asked Questions

Q: How long does a BI migration to Power BI actually take?

Microsoft publishes no standard durations, and consultancy estimates vary with estate size: Withum quotes 6–12 weeks for a focused Tableau-to-Power-BI migration, while mid-size estates (50–150 actively used reports) more commonly run 4–7 months including the parallel run: 4–6 weeks for the usage audit and scoping, 2–3 weeks for proof of concept, 2–4 months for model and report build, and one full reporting cycle running parallel before cutover. Large enterprises with complex Cognos or Tableau estates typically need 9–18 months. The single biggest timeline variable is scope discipline — estates that audit usage first migrate a fraction of their nominal report count.

Q: What is the most expensive BI migration mistake?

Rebuilding every legacy report 1:1 in Power BI. It multiplies build effort by two to three times, skips the consolidation that makes the new estate cheaper to maintain, and imports the old platform's design debt. The fix costs nothing: treat legacy reports as requirements documents and redesign around shared semantic models. Closely behind it is skipping the parallel run, which leaves every post-cutover discrepancy to be debugged in production with no trusted baseline.

Q: Should we run the old BI platform and Power BI in parallel?

Yes, for at least one full reporting cycle — a month-end close at minimum, a quarter-end if your board reporting depends on the migrated estate. The parallel run validates measures against a trusted baseline, surfaces refresh and gateway issues while a fallback exists, and produces the reconciliation evidence finance needs to sign off. Budget the dual-platform cost into the project from day one so the parallel run does not get cut to save money mid-project.

Q: Do we need Microsoft Fabric capacity to migrate to Power BI?

Not necessarily. Power BI Pro at $14/user/month covers organizations where everyone who views content can hold a Pro license. Fabric capacity becomes the better deal at scale: from F64 upward, viewers consume Power BI content with free licenses, which usually wins on cost once the viewer count reaches the low hundreds. Below F64, every viewer still needs Pro or PPU, so small capacities only make sense for workload isolation or Fabric features, not licensing savings. Model both options against your real audience before committing.

Q: Who should own a BI migration — IT or the business?

Both, with different responsibilities. IT owns the platform: tenant setup, capacity, gateways, security patterns, deployment pipelines. The business owns the content decisions: which reports live or die, what metric definitions mean, and whether the parallel-run reconciliation passes. The projects that overrun are almost always the ones where IT made content decisions by default because no business owner was named. An executive sponsor with budget authority is the strongest single predictor Microsoft cites for migration success.