Inventory before estimate
We catalogue every document, app, sheet, and object with its owner, sources, and expressions. You get a rebuild, merge, or retire recommendation per item before any budget is committed.
Leaving Qlik
A Qlik to Power BI migration built around your renewal date
We rebuild QlikView documents and Qlik Sense apps in Power BI: load-script logic re-expressed in Power Query, set-analysis expressions translated into DAX measures, and every figure reconciled against the original before anything is switched off.
Representative dashboard — sample data
Why teams move
The contract renewal is what sets the clock
Almost every one of these projects starts with a date on a contract. Finance circulates the renewal figure, IT points out that the business already pays for Microsoft 365, and a question that was theoretical for two years needs an answer in one quarter. That is why so much of this work gets done badly: object by object, in a hurry, with nobody checking the rebuilt figures against the originals.
The honest version of the job has three parts. Decide what deserves to survive, rebuild that logic on a semantic model, and prove the outputs match. Skip the first and you pay to recreate sheets nobody opens. Skip the third and adoption stalls the first time two numbers disagree in a meeting.
What the migration covers
- Document & app inventory
- Load script → Power Query
- Set analysis → DAX
- Star-schema model rebuild
- Section Access → RLS
- Reconciliation & handover
Try us risk-free for 4 hours
Start with a block of prepaid Flex hours and, if you’re unhappy within the first 4 hours, we refund you in full — no questions asked. An inventory of your documents and apps is a sensible first task: it sizes the job before you commit to it.
How we approach it
Start with one slice of the estate, not all of it
Recreating charts is the easy half. The value sits in what gets retired, which expressions finally get one agreed definition, and whether the numbers survive.
A pilot that proves the mapping
One subject area moves first, script and measures included. It settles the awkward expressions early and produces a real hours-per-app figure to budget the rest against.
Expressions, not screenshots
Set analysis, variables, and chart expressions are read, understood, and rewritten as tested DAX measures. Copying the layout while guessing at the arithmetic is how migrations lose their audience.
One model, not many scripts
Per-document load scripts collapse into shared Power Query logic and one governed star schema, so a measure is defined once and every report inherits it.
Reconciled before sign-off
Each rebuilt report is compared with its Qlik original over the same period. Differences get explained rather than waved through, and some turn out to be corrections.
Sequenced around the renewal
The reports people depend on move first, so the old platform is retired on schedule instead of being extended for a handful of items nobody triaged.
What actually has to be rebuilt when you leave Qlik?
Both platforms turn a data model into interactive analysis, but by different routes. Qlik’s associative engine keeps every field linked and resolves selections at query time. Power BI works from an explicitly modelled star schema with defined relationships and DAX measures. A move between them is a rebuild against a known map, not a file conversion — and the map is what makes it predictable.
The second difference is where logic lives. In a Qlik estate much of the transformation sits in the load script and much of the analysis sits in chart expressions and variables attached to individual objects. Power BI separates those layers: Power Query shapes the data, the model holds the relationships, DAX measures do the calculation. Deciding which layer each piece of existing logic belongs in is the real work, and it is also the moment your organisation settles which definition of “margin” wins.
How do Qlik constructs map to Power BI?
Here is the practical mapping we work from. Every row below is a conceptual correspondence rather than an automated conversion: each construct is rebuilt by hand and then checked against the original output.
| Qlik construct | Power BI equivalent | What changes in practice |
|---|---|---|
| QlikView document / Qlik Sense app | Power BI report plus a shared semantic model | Several documents often consolidate into one report with slicers |
| Sheet and sheet objects | Report pages and visuals | Layout is re-created on Power BI’s canvas, not imported |
| Load script and QVD layer | Power Query queries and dataflows | Script transformation becomes staged, reusable queries with visible lineage |
| Chart expression / aggregation | DAX measure in the model | Written once centrally rather than per object, then reused everywhere |
| Set analysis expression | CALCULATE with explicit filter arguments | Selection-state modifiers become filter-context modifiers, reconciled one by one |
| Variable with dollar-sign expansion | DAX measure or a what-if parameter | Text substitution becomes a typed, testable object |
| Master items (Qlik Sense) | Named measures, dimensions, and hierarchies | The closest one-to-one mapping in the exercise |
| QlikView macro / module code | Power Query step or native report interaction | A Power BI report has no scripting layer, so the behaviour is redesigned |
| Section Access | Row-level security roles | Per-user filtering becomes DAX role filters, tested before release |
| Streams and published apps | Power BI workspaces and apps | Publishing rights become workspace roles and app audiences |
Measure authoring absorbs most of the hours, and Microsoft’s guide to creating measures in Power BI Desktop (opens in new tab) describes the target state well, as does its documentation on row-level security (opens in new tab). Our data modeling and DAX work turns that mapping into a model your analysts can extend later.
Does QlikView differ from Qlik Sense in the move?
Enough that we scope them separately. QlikView is document-centric, with designer-built fixed layouts and script logic held per document. Qlik Sense is app-centric, with responsive sheets and master items that already centralise some definitions. The script language and set-analysis work is broadly shared; the inventory and consolidation effort is not.
| Aspect | QlikView estate | Qlik Sense estate |
|---|---|---|
| Unit of work | Documents with fixed, designer-built layouts | Apps with responsive sheets and master items |
| Where measures live | Inside chart expressions on each object | Often centralised as master measures |
| Inventory effort | Object-by-object extraction per document | The master-item list gives it a head start |
| Sensible first pilot | One heavily used document and its script | One app plus the master items it shares |
| Common surprise | Near-duplicate expressions that quietly disagree | Self-service sheets with no owner left |
What does the move off Qlik cost?
Work runs on prepaid Flex hours that never expire, in three published blocks: Starter $2,500, Growth $4,600, or Power $8,000 (USD), with hourly rates from $100/hour. The inventory and pilot usually fit inside a Starter block, and that is what we recommend buying first, because it turns an unknown project into a per-app estimate you can take to a budget holder.
After the pilot, cost tracks how many objects survive triage and how much expression logic each one carries. A sheet with three straightforward aggregations is a different job from one built on nested set analysis, alternate states, and a chain of variables. You approve only what you want built, and unused hours stay banked. See Flex pricing.
How long does a Qlik migration take?
Individual reports typically ship within 3–5 business days of your approval, and a phased migration is a sequence of those tasks rather than one long programme with a single risky cutover. Larger estates get a clear timeline per phase once the inventory is done.
Running both platforms in parallel for one reporting cycle is worth the overlap: users compare old and new on live data, and licences lapse only once the replacements have been used in anger. Where the estate is consolidated as well as moved, our report design work runs alongside the rebuild, and a Power BI health check keeps refresh honest once it is live.
Who this is for
Mid-market teams with a Qlik renewal in sight, an existing Microsoft estate, and reporting people genuinely depend on. It suits estates in roughly the 20–150 object range — large enough that a weekend rebuild is not credible, small enough that an enterprise-grade migration programme with its own governance board would cost more than the reporting is worth. It is not for teams who want a like-for-like copy with no decisions made along the way.
What you get
- Inventory of documents, apps, and objects
- Rebuild / merge / retire recommendation
- A scoped pilot on one subject area
- Expressions rebuilt as tested DAX measures
- Reconciliation against the originals
- Handover docs and a user walkthrough
3–5
business days per report
Pilot
before the estate
You
own everything
Buy the inventory and pilot first, then decide the rest.
How it works
From a Qlik estate to trusted Power BI reporting
- 1
Inventory and triage
Every document, app, and object is catalogued with its owner, sources, and expressions, then tagged rebuild, merge, or retire. You approve the list before anything gets built.
- 2
Pilot, then rebuild
One subject area moves first to prove the mapping and set the hours-per-app rate. Surviving reports are then rebuilt on a governed model, with set analysis reconstructed as tested DAX.
- 3
Reconcile and hand over
We compare outputs against the Qlik originals, explain every difference, translate Section Access into row-level security, publish to your workspace, and walk users through the changes.
Representative perspective
The pilot changed the conversation internally. Once we had a real hours figure for one app, the rest of the estate stopped being an unknown and became a schedule.Analytics manager, mid-market distributor
Representative perspective
Nobody left in the building could explain half the set-analysis expressions. Having them read, rewritten, and reconciled line by line is what let us sign off.Finance director, manufacturing group
Find out what your move off Qlik really involves
Tell us roughly how many documents or apps you have and when the renewal lands. We’ll scope the inventory and a pilot in hours, so you see the true size of the project before committing to it.
FAQ
Questions we get before the pilot
No. The associative engine, the load script, and set analysis have no direct equivalents, so apps are rebuilt rather than converted. What is systematic is the inventory, the expression-by-expression mapping, and the reconciliation. Treat any promise of a one-click conversion as a claim worth testing on a small pilot first.
A set expression modifies the selection state for a single aggregation, and CALCULATE does the same job by modifying filter context. A set-analysis sum restricted to one year becomes a CALCULATE measure with an explicit year filter. The pattern transfers cleanly, the syntax does not, and every rebuilt measure is reconciled against the original.
Not quite. QlikView documents carry fixed layouts and per-document scripts, so consolidation decisions come first. Qlik Sense apps already separate master items from sheets, which makes the measure inventory faster to extract. The load script, set analysis, and Section Access work is broadly similar across both estates.
Yes, and we recommend it. A pilot on one subject area, covering a single app with its script and its measures, proves the mapping, exposes the awkward expressions, and gives you a real hours-per-app figure. You then decide whether to continue, pause, or re-scope before committing the rest of the estate.
Section Access rules become row-level security roles in the Power BI semantic model, defined as DAX filters and tested per user. It is worth scoping as its own task rather than folding it into a report rebuild, because access rules are the one thing nobody wants discovered wrong in production.
Related work
This page covers the Qlik path specifically. If your estate spans several tools, our broader migration to Power BI service handles Excel, SSRS, and legacy BI on the same prepaid model, and teams leaving a different visual-analytics platform should read the Tableau to Power BI migration service page instead. Estates governed by an Oracle repository rather than a script are covered on the OBIEE to Power BI migration page, where the RPD's logical layer and session variables drive the plan. Estates built on a cached in-memory cube rather than a load script are a closer relative: our Sisense to Power BI migration page starts from the ElastiCube schema and its build steps, because that is where the logic and the timeline actually live. Estates where the logic ended up in a scripting layer instead have their own page: Spotfire to Power BI migration is scoped from the DXP analysis files, the Information Links behind them and every IronPython script and TERR data function, because script density rather than page count drives that timeline. The rebuild leans on data modeling and DAX, while Power BI vs Tableau frames the platform comparison for anyone still presenting the decision. Security-heavy estates should read our guide to Power BI row level security setup before the Section Access rules are translated. Every task is scoped before work begins from your prepaid block of senior-led hours — no project minimums, and hours are deducted only for work you approve.
Book a free demo
Get senior Power BI help, on demand
Tell us the task. We scope it, you approve, and a senior consultant delivers — typically in 3–5 business days. Prepaid hours that never expire.
- Prepaid hours from $100/hour — and they never expire
- Senior-led delivery — 20+ years on the Microsoft platform
- Typical 3–5 business day turnaround
- Full refund if you’re unhappy in your first 4 hours
The fastest way to reach us is the form — tell us the task and we'll reply within one business day.