TL;DR
A Qlik to Power BI migration is a rebuild, not a conversion, so cost follows the number of apps actually used. Mid-size programs run 6 to 12 months at about $150,000 to $600,000 (Addend planning ranges). Microsoft-standardized organizations with a core set of active apps gain most, while a small Qlik Cloud estate can reasonably stay. CIOs and BI heads should retire unused apps, pilot three to five, then decide.
CIOs and BI heads weighing a Qlik to Power BI migration have usually heard the sales pitch already: lower licence cost, better Microsoft fit, one platform. Now it comes down to the decision, and the numbers have to hold up in front of finance.
The decision is hard because nobody can price it without opening the Qlik estate. Set Analysis, load scripts and the associative model all have to be rebuilt, not copied, and vendor estimates swing widely. A CIO or BI head also has to explain what the organization pays while two platforms run side by side.
This post gives CIOs and BI heads realistic cost and timeline ranges, six criteria for judging a partner, and a go or no-go checklist that can be used this month. It also says plainly when staying on Qlik is the better call. Addend Analytics is a Microsoft-focused consultancy, so this view should be read with that in mind.
Qlik Sense to Power BI: What the Migration Covers
A Qlik to Power BI migration is a rebuild, not a file conversion. Qlik and Power BI store, calculate and secure data differently, so almost every app needs fresh design decisions. The good news is that most business logic carries over once it is translated.
The table below shows where the effort sits. Set Analysis, Aggr() and the associative model take the most time, because each one needs a business owner to confirm the numbers after the rewrite.
| Qlik feature | Where it lands in Power BI | Effort and risk |
| Set Analysis expressions | DAX measures built with CALCULATE and filter arguments | High. Logic is rewritten and reconciled number by number. |
| Aggr() and nested aggregation | DAX iterator functions over virtual tables | High. Often needs a redesigned measure. |
| Associative model and synthetic keys | Star schema semantic model with explicit relationships | High. This is a redesign, not a migration. |
| Load scripts and QVD layers | Power Query, dataflows or Fabric pipelines and lakehouse tables | Medium. Depends on how much logic sits in scripts. |
| Section Access | Row-level security roles in the semantic model | Medium. Retest every user group. |
| Alternate states and mashups | Field parameters, bookmarks or separate report pages | Medium. No one-to-one equivalent exists. |
| NPrinting reports | Paginated reports and scheduled subscriptions | Medium. Layouts are rebuilt. |
| Third-party extensions | AppSource or custom visuals, checked one by one | Medium. Some have no match. |
Caption: Where common Qlik logic lands in Power BI, and how much effort each translation typically adds.
QlikView and Qlik Sense share the same script and expression language, so the logic work looks similar. QlikView apps usually cost more to rebuild because of fixed layouts, macros and Publisher tasks that have no direct Power BI equivalent. Qlik Sense apps tend to be easier to inventory and to map to Power BI visuals.
“Most Qlik migrations are priced on the wrong unit. Teams count reports, when the real driver is how many apps people still open. Retire what nobody uses, rebuild what matters as a clean semantic model, and the cost and timeline both become predictable.”
Benefits of Moving From Qlik to Power BI
The benefits are real, but they land in different places for different organizations. CIOs and BI heads should treat each one below as a hypothesis to test on the Qlik estate, not as a promise.
| Benefit | What changes | Condition for the gain |
| Licensing flexibility | Pro is included in Microsoft 365 E5, and report viewers need no Pro licence on Fabric capacity at F64 or larger. | Largest where many users only view reports. |
| One Microsoft platform | Power BI, Fabric, Entra ID, Teams and Excel share identity, data and administration. | Strongest where Microsoft 365 or Azure is already the standard. |
| Reusable semantic models | One governed model feeds many reports, replacing logic duplicated across Qlik apps. | Needs the star schema redesign done properly. |
| Simpler security | Row-level security roles map to existing Entra ID groups instead of a separate Section Access table. | Every user group must be retested. |
| Familiar self-service | Analyze in Excel and Teams put governed data where business users already work. | Users used to associative exploration need training. |
| A cleaner estate | The inventory forces unused apps to be retired instead of carried forward. | Needs usage data and an owner for each app. |
Caption: Benefits of a Qlik to Power BI migration and the condition each one depends on.
The cleaner estate is the benefit most often overlooked. Migration is the one moment when every app has to justify its existence, and retiring the unused ones lowers the cost of everything that follows.
None of these benefits is automatic. An organization that is not standardized on Microsoft, or one with a small Qlik Cloud estate on a fresh contract, may find the gains too thin to justify a rebuild. The sections below show how to test that with numbers.
What a Qlik to Power BI Migration Costs by Phase
You are pricing two separate things: the licences you pay every year, and the migration you pay once. Mixing them up is the most common reason a business case falls apart in front of a CFO.
On licences, list prices tell a more mixed story than most vendor blogs admit. Microsoft lists Power BI Pro at $14 per user per month and Premium Per User at $24, both paid yearly, and Pro is included in Microsoft 365 E5. Qlik lists Qlik Cloud Analytics Standard from $825 per month for 25 GB and 20 Full Users, and Premium from $2,500 per month for 50 GB with up to 100,000 Basic Users. Client-managed Qlik Sense and QlikView are quoted, so your renewal quote is the baseline.
The break-even point depends on how many people only view reports. On Fabric capacity at F64 or larger, viewers need no Pro licence, though authors still do. At list price, F64 runs roughly $60,000 a year pay-as-you-go and about 40 percent less on a one-year reservation, so it tends to beat per-seat Pro at around 360 viewers, or about 210 with a reservation. Test your own numbers in the capacity estimator before you rely on these.
If your Qlik estate is small and on a fresh Qlik Cloud contract, licence savings may be modest. The stronger savings tend to come from retiring client-managed servers, folding spend into Microsoft 365 and Azure agreements, and dropping duplicate tools.
The one-off migration cost is where ranges widen. These are Addend’s planning ranges for mid-market and enterprise Qlik estates, not quotes.
| Scope | What you get | Indicative investment | Typical timeline |
| Assessment | App inventory, usage scoring, effort estimate and a go or no-go view | $8,000 to $20,000 | 2 to 4 weeks |
| Pilot of 3 to 5 apps | Rebuilt semantic model and reports, reconciled to Qlik | $25,000 to $60,000 | 6 to 10 weeks |
| Per rebuilt app | Simple, moderate or complex rebuild including testing | $3,000 to $8,000 simple; $8,000 to $20,000 moderate; $20,000 to $45,000 complex | Delivered in waves |
| Mid-size program of 20 to 60 apps | Waves, row-level security, training, parallel run and Qlik shutdown | $150,000 to $600,000 | 6 to 12 months |
Caption: Addend planning ranges by scope, before Power BI or Fabric licences, which you price separately.
Four things push cost up: the number of active apps left after you retire unused ones, heavy Set Analysis and Aggr() logic, Section Access rules that differ by user group, and a data model that lives only in QVD files with no warehouse behind it. Three things keep it down: usage-based retirement, an existing warehouse or Fabric lakehouse, and a willingness to rebuild reports for Power BI instead of copying every Qlik layout.
That composite is not a forecast for your migration, and the study covers Fabric, not Qlik moves specifically. Use it as a framework for building your own case, not as a promise.
Migrating QlikView to Power BI: Three Paths Compared
Leaders have three real options, and the right one depends on estate size, renewal date and Microsoft footprint. Most mid-size and large estates do best with a phased plan, which is the approach this post favors.
| Criteria | Stay on Qlik | Full migration | Phased migration |
| Upfront cost | Renewal only | Highest. Every active app is rebuilt. | Moderate. Assessment first, then pay per wave. |
| Time to first insight | Immediate | 6 to 12 months before cutover | 6 to 10 weeks for pilot apps |
| Long-term fit with Microsoft | Weak if the rest of your stack is Microsoft | Strong once complete | Strong, after a period of two platforms |
| Main risk | Cost growth at renewal and version support dates | Cutover errors and user backlash | Running two platforms longer than planned |
| Best for | Small, healthy Qlik Cloud estates | Small estates facing a hard renewal date | Mid-size and large estates |
Caption: How staying, migrating fully and migrating in phases compare on cost, speed, fit and risk.
When migrating is the wrong move. If you run a small Qlik Cloud estate on a fresh contract and your teams depend on associative exploration, alternate states or mashups, Power BI will not reproduce that experience directly. The same goes if your stack is not Microsoft, because much of the saving comes from sitting inside Microsoft 365 and Azure. In those cases, renegotiate your Qlik renewal and revisit in a year. Addend works inside the Microsoft ecosystem, so we are also not the right choice if you want to stay on Qlik.
Want an inventory before you commit? Addend’s migration assessment scores each of your Qlik apps for usage and rebuild effort, then gives you a costed plan. Book an assessment
Qlik Migration Partner Checklist for CIOs and BI Heads
A good partner is easy to spot if you ask for proof on your own apps. Use these six criteria in order, because the first three decide whether your numbers will be right.
- A pilot on your app, not a demo. Ask them to rebuild one of your real Qlik apps that contains Set Analysis.
- A written approach to data model redesign. They should explain how your associative model becomes a star schema and who signs off.
- Number-by-number reconciliation. Every KPI is checked against Qlik and approved by a business owner.
- Usage-first scoping. They score your apps by use and propose retiring the unused ones before they price.
- Named people. You know who writes the DAX, and you can see their Qlik and Power BI experience.
- Training and shutdown included. The plan covers user training, licence guidance and a date to switch Qlik off.
Take these questions to your next vendor meeting:
- Which of our apps would you rebuild first, and why?
- How do you reconcile DAX results against our Qlik numbers, and who signs off?
- What share of our apps do you expect us to retire?
- What happens to our timeline if you find undocumented dependencies mid-project?
- Who owns the semantic model and the documentation when you leave?
Per-report estimates swing widely, so ask every partner to price in aggregate and to show their range.
“One large company received a 50-day estimate for a complex report, and the Power BI rebuild took about 50 hours.”
Source: Microsoft Learn, 2024
Common Pitfalls in a Qlik Sense Migration
Three problems cause most failed Qlik migrations, and all three can be planned for.
Migrating everything. Large estates collect apps nobody opens. In one published Microsoft customer example, about half of the reports had been used in the previous year, and perhaps half of those delivered real value.
Copying the model. Teams that copy Qlik logic one to one end up with slow DAX and reports nobody trusts. Redesign the data model first, then translate the expressions.
Skipping change management and licensing. Authors who like Power BI keep requesting Pro licences, and users who loved click-anywhere Qlik exploration need training. Plan both before cutover.
“Won’t this take too long to show results?”
A pilot of three to five apps takes 6 to 10 weeks in our planning, and it gives you real numbers before you fund the rest. Full programs run 6 to 12 months because both platforms stay live during each wave. Microsoft’s published customer examples were phased over years, with Power BI already in daily use before the formal migration began.
“Will our users accept Power BI after years of Qlik?”
Some will resist, and that is a fair reaction. Qlik users click anywhere to filter, while Power BI relies on slicers and designed pages. Plan training, keep a business expert on each app during the rebuild, and aim for fit-for-purpose reports instead of exact copies, which is what Microsoft’s own customer found worked.
“Can we trust the numbers after the expressions are rewritten?”
Only if every KPI is reconciled against Qlik and signed off by a business owner. Run one full reporting cycle in parallel for apps that drive financial decisions. Small differences are normal at first, and unexplained differences should block go-live.
“Don’t automated converters make this quick?”
Converters can speed up inventory and first-pass layouts, and some vendors advertise 70 percent or more automation. Set Analysis, the data model and Section Access still need human decisions, so treat automation as a time saver on the first draft, not a guarantee on the final numbers.
Your Next 30 Days: A Go or No-Go Checklist
You do not need to decide the whole program this month. You need enough evidence to say go, no-go or pilot.
- Days 1 to 10, inventory. Export your Qlik app list with owners, users and last-opened dates from the management console or usage logs. Flag anything unopened in 12 months for retirement.
- Days 11 to 20, score and price. Rate each remaining app simple, moderate or complex, then price in aggregate using the ranges above. Choose three to five pilot apps, including one with heavy Set Analysis.
- Days 21 to 30, decide. Run the checklist below with finance and business owners, then approve a pilot or renew Qlik on a shorter term.
Go if most of these are true:
- Microsoft 365 or Azure is already your standard platform.
- A Qlik renewal or QlikView version support date falls within the next 12 months.
- Usage scoring shows a defined core set of apps, not an estate where everything is used.
- A named business owner will sign off the numbers for each KPI.
- Your budget covers a pilot first, not the full program.
- Someone owns Power BI governance and licensing after cutover.
If fewer than four are true, renew Qlik on a shorter term and revisit after your next planning cycle. For a similar framework, read our guide to Tableau migration costs, and see semantic model design for what your rebuilt data model should look like.
The Decision in Front of You
You now have realistic cost ranges, a timeline, a way to judge partners and a checklist you can run this month. A decision this size deserves time, and asking for a pilot before a program is a reasonable position, not a delay. If the numbers say migrate, Addend Analytics can run the assessment on your Qlik estate and give you a costed, phased plan to take to your finance team. If they say stay, you will renew with sharper terms and a clear trigger for revisiting. Either way, you will be deciding with evidence from your own apps, and that makes whatever comes next, a first Power BI wave or a better renewal, much easier to defend.
Why Choose Addend for Your Qlik to Power BI Migration
Addend Analytics is a Microsoft-focused consultancy, and its work centers on Power BI, Microsoft Fabric and data engineering. For a Qlik migration, that focus matters because the target platform decisions, such as licence mix, Fabric capacity size and governance model, change the business case as much as the rebuild itself.
Partner credential: [Add Addend’s confirmed Microsoft partner designation or badge here, for example Solutions Partner status, before publishing. Do not state one until verified.]
The approach is built around the risks covered in this post:
- Assessment first. Each Qlik app is scored for usage, owners and rebuild effort, so unused apps are retired before anything is priced.
- Reconciliation by KPI. Set Analysis and Aggr() logic is rebuilt as DAX measures and signed off by business owners against the Qlik numbers.
- Models built once. Star schema semantic models on Fabric replace logic duplicated across apps and keep reports consistent.
- Phased delivery. A pilot of three to five apps comes first, followed by waves, with Qlik running in parallel until sign-off.
- Security and handover. Section Access is rebuilt as row-level security, retested for every user group, and followed by training and a named governance owner.
The same assessment can also conclude that renewing Qlik is the better call. A partner that is willing to say so, and that works inside the Microsoft stack the migration targets, is better placed to give CIOs and BI heads a number worth taking to finance. To see how this fits the broader program, read about Addend’s Power BI consulting approach.
FAQs
CALCULATE and filter arguments. Ignoring selections usually becomes removing filters with ALL or REMOVEFILTERS. Set operators such as P() and E() need table-filter patterns and are the hardest to translate. There is no one-to-one conversion, as this Fabric Community thread shows.
SUMX or AVERAGEX over a virtual table built with SUMMARIZE or ADDCOLUMNS. Often the cleaner fix is to restructure the data model or add a calculated column instead of copying nested logic. See this Aggr to DAX discussion.
Author By
Afroz Labbai
Afroz is a Data Engineer and Team Lead with 4+ years of experience in building scalable data platforms using Azure technologies such as Azure Data Factory, Azure SQL, Databricks, and Synapse. He specialises in ETL development, SQL optimisation, and data modelling, delivering reliable and cost-efficient solutions for enterprise analytics. He is passionate about continuous learning, mentoring teams, and driving data-driven decision-making.
