QlikView to Power BI migration services
Fixed-fee QlikView to Power BI migration for US small businesses, delivered by senior US-based Microsoft engineers: we open the load script buried inside your .qvw and .qvf documents, rebuild the Qlik associative data model as a Power BI star schema, translate Qlik load logic into Power Query M, and re-derive set analysis expressions as tested DAX measures — one written price, typical delivery in 2–4 weeks, 30 days of hypercare included.
Representative dashboard — sample data
What you get
A QVW keeps its script, its model and its layout in one file. Power BI deliberately keeps them apart, and that split is most of the work.
Fields that associated by sharing a name are re-expressed as explicit fact and dimension tables with declared cardinality and filter direction — the point where synthetic keys and loosened circular references finally get resolved rather than tolerated.
LOAD and RESIDENT steps, CONCATENATE blocks, ApplyMap lookups and QUALIFY rules are rewritten as Power Query queries — or pushed upstream into the warehouse, where several of them belonged all along.
Every {<Year={2024}>} modifier, Aggr() nesting and dollar-expanded variable is rewritten as a named DAX measure defined once, then checked against the number your QlikView document produces today.
Your QVD extracts are inventoried and each one is either bypassed in favor of its original source or staged out to an open format. Nothing depends on a proprietary file Power BI cannot read.
Data reduction that happened at reload time moves into security roles on the semantic model, so the same person sees the same rows — enforced by the service rather than by which copy of the document they opened.
Each phase ends with your figures side by side against the live QlikView document. Agreed check numbers have to match before anyone calls that phase finished or cancels a reload task.
How it works
A free consultation plus a pass over your documents, load scripts, QVD folder and reload tasks tells us where the logic actually lives. You get a written scope, a phase plan, one fixed price and a delivery date.
We build the star schema and its Power Query queries first, re-derive expressions into DAX measures, rebuild each phase's sheets as report pages, and reconcile them with your team against the live QlikView numbers.
Reports publish to your workspace with row-level security and a refresh schedule applied. Once the final phase is signed off you get the decommission list, and we stay on for 30 days of hypercare.
QlikView's defining idea is that you do not declare joins. Load two tables that both contain a field called CustomerID and they associate, automatically, on that name. It is a fast way to get somewhere and a slow way to stay there: share two field names between the same pair of tables and QlikView quietly manufactures a synthetic key table to reconcile them; close a loop between three tables and it loosens one of them for you and tells you afterwards. Most QVW estates carry a few of each, tolerated for years because the numbers looked plausible.
Power BI will not let you do that, and this is the single biggest reason a QlikView migration is not the same job as any other. A model relationship in Power BI relates exactly one column to one column in a different table, with a cardinality and a cross-filter direction you declare on purpose; Microsoft's documentation on model relationships in Power BI Desktop (opens in new tab) is explicit that only one active filter propagation path may exist between two tables, and that ambiguous paths are an error rather than something the engine papers over. So the associative sprawl has to be resolved into fact and dimension tables built on star schema principles (opens in new tab) before a single visual is placed. That is slower than redrawing the sheets, and it is where the value of the project sits: it is the moment three definitions of “active customer” that nobody had noticed disagreeing finally get settled.
A QlikView document is its own ETL tool. The script does the extract, the reshaping, the mapping and the incremental logic, all in sequence, all inside the file. Power BI splits that work: row-level shaping goes into the Power Query M formula language (opens in new tab), and aggregation logic goes into measures evaluated against the model. We walk the script statement by statement and decide which of the three destinations each step belongs to — M, the model, or upstream in the warehouse, which is frequently the right answer for a mapping table that has been rebuilt on every reload since 2014.
Expressions get the same treatment. Set analysis and DAX are close cousins in intent and nothing alike in form: sum({<Region={'West'}>} Sales) narrows what one aggregation sees, and CALCULATE (opens in new tab) — which Microsoft documents as evaluating an expression in a modified filter context — is the tool that does the equivalent job in Power BI. The mapping is rarely one line for one line. Aggr() usually becomes an iterator over a summarized table; dollar-sign variable expansion becomes a measure or a calculation group; Above() and Below() chart offsets become explicit time intelligence against a real date table, because Power BI has no notion of the row above in a chart. Each one is re-derived from the rule it encodes and confirmed with whoever owns the number, not transliterated by a converter that produces something which runs and answers a different question.
Most QlikView estates decompose into the same handful of pieces. The table below is the mapping we work from; the inventory in your written scope is a filled-in version of it, document by document.
| QlikView artifact | What it actually holds | Where it lands in Power BI |
|---|---|---|
| .qvw document (or .qvf app) | Load script, in-memory data model and every sheet, in one binary file | Split three ways: Power Query queries, a semantic model, and a .pbix report whose pages replace the sheets |
| .qvd extract files | Qlik's proprietary columnar staging layer, often the only surviving copy of a retired source | Bypassed by re-pointing Power Query at the original database, or staged out to an open format where the source is gone |
| Load script (LOAD / SELECT / RESIDENT / CONCATENATE) | Sequential ETL living inside the document rather than in a pipeline | Power Query M queries, or promoted upstream into the warehouse or a scheduled data pipeline |
| MAPPING LOAD and ApplyMap() | Lookup substitution applied row by row during reload | A merge step in Power Query, or a proper dimension table plus a relationship where the lookup is really a hierarchy |
| Associative field naming | Implicit joins wherever two tables share a field name | Explicit one-column relationships with declared cardinality and cross-filter direction |
| Synthetic keys and loosened circular references | Automatic reconciliation tables the engine created when the model was ambiguous | Removed by design: a composite key column, a conformed dimension, or a bridge table chosen deliberately |
| Set analysis modifiers | Per-aggregation overrides of the current selection | DAX measures built on CALCULATE with explicit filter arguments and filter modifiers |
| Aggr(), Above(), Below(), RangeSum() | Chart-level and virtual-grouping calculations with no model equivalent | Iterators over summarized tables and time intelligence written against a real date dimension |
| Variables with dollar-sign expansion | Reusable expression text substituted at evaluation time | Named DAX measures, calculation groups, or Power Query parameters, depending on what the variable was for |
| Section Access | Row-level data reduction enforced when the document reloads | Row-level security roles with DAX filter expressions, enforced by the service at query time |
| QMC / Publisher reload tasks | Scheduled reloads and document distribution | Semantic model refresh schedules, plus an on-premises data gateway where sources stay behind your firewall |
| NPrinting output | Pixel-perfect documents and scheduled report delivery | Paginated reports for anything that must keep its printed shape; Power BI subscriptions for everything else |
| Green / white / gray selection states | Visual feedback showing selected, associated and excluded values | No direct equivalent — rebuilt as slicers with visible applied filters, cross-highlighting, and explicit measures where exclusion drives a decision |
Two rows in that table are the ones that decide a timeline. If the QVD layer can be bypassed because the underlying databases are still there, the project is mostly modeling and expression work. If the QVDs have quietly become the system of record for a source that was switched off years ago, staging them out is a real piece of scope and we price it as such rather than discovering it in week three.
It fits small and mid-size US organizations running a QlikView estate that has outlived the person who wrote it — often with a renewal date approaching, a Microsoft 365 tenant already paid for, and nobody left in-house who is comfortable opening the load script. It is scoped as one fixed-fee project with a stated end date, not a rolling program, and we are candid when a document is better retired than rebuilt.
If the incumbent is a different platform, a sibling page will fit you better. Our Tableau to Power BI migration service covers workbooks that carry their own calculation logic, where LODs and table calculations rather than set analysis are the translation problem. Our SSRS to Power BI migration service is the Microsoft-to-Microsoft case, where RDL definitions travel largely intact as paginated reports and the work sits in subscriptions and folder security. And our Crystal Reports to Power BI migration service deals with .rpt files, formula fields and subreports opened from a button inside an ERP. And our Cognos to Power BI migration service covers the estate where a Framework Manager package already holds the modeling layer and report bursting handles distribution. And our Domo to Power BI migration service covers the all-in-one SaaS case, where Beast Mode calculated fields and Magic ETL dataflows have to be rehoused at the same time as the cards, because Domo bundles storage and transformation with the reporting. And our SAP BusinessObjects to Power BI migration service covers the opposite extreme: a universe already centralizes the business definitions, so that estate is read as a specification rather than reverse-engineered from a script. And our MicroStrategy to Power BI migration service covers the MicroStrategy estate — the platform its vendor now brands as Strategy — where a project metadata repository already holds the attributes, facts and level metrics centrally, which is the exact opposite of a load script rewritten once inside every document. QlikView is its own animal because of the associative engine and the QVD layer — none of those seven pages has an equivalent problem to solve.
Once you have landed on Power BI, the work usually continues. Our fixed-fee Power BI dashboard development service covers reports built new on the model rather than migrated onto it, the guide to what a Power BI dashboard actually costs explains how scope drives a fixed fee, and if the scale of your estate eventually justifies it, our Power BI to Fabric migration service handles capacity. Where the load script was doing work that belonged in a pipeline, our Azure Data Factory pipeline development service builds the scheduled loads that replace it.
Most QlikView estates sort cleanly into three phases. The table shows scope and typical timeline rather than prices, because an honest number requires reading your load scripts first — the same principle described on how our fixed-fee process works.
| Phase | Scope | Typical timeline | Fee |
|---|---|---|---|
| Phase 1 — core model and headline documents | The documents leadership and operations open weekly: star schema built from the load script, QVD dependencies resolved, headline set analysis expressions rewritten as DAX and reconciled, workspace and access configured | About the first week | Fixed fee — scoped after your free consultation |
| Phase 2 — departmental documents | Finance, sales or operations sheets rebuilt as report pages on the shared model, with Section Access re-expressed as row-level security, drill-through in place of embedded detail, and a walkthrough per team | Weeks 2–3 | Fixed fee — scoped after your free consultation |
| Phase 3 — distribution, long tail and decommission | NPrinting output rebuilt as paginated reports or subscriptions, refresh schedules and gateway configured, low-traffic documents rebuilt, consolidated or retired by agreement, plus the written list of reload tasks and licences you can cancel | Week 4 and close-out | Fixed fee — scoped after your free consultation |
Nothing is switched off early. Your QlikView documents keep reloading on their existing schedule while Power BI connects to the same sources alongside them, so both can sit on one screen while your team argues about the numbers before anyone commits. Everything produced is yours from the first day: the semantic model, the report files, every measure and query, and the workspace configuration all live in your own Microsoft tenant, never in ours.
Related services
Fixed-fee dashboard development for the reports you want built new, once your estate has landed on Power BI.
Scheduled pipelines that take over the extract and reshape work your QlikView load script was doing.
The scoping process, what a written fixed-fee proposal contains, and what happens after delivery.
What to ask, what to check, and the answers that should make you walk away.
Pro vs Premium Per User vs Fabric, explained for small business budgets.
Where a modelled BI tool earns its place — and where a spreadsheet still wins.
FAQ
No, and we would not trust a tool that claimed otherwise. A QVW holds its load script, data model and sheets in one binary file, and Power BI keeps those three concerns apart. We read the script, rebuild the model deliberately, and re-derive each expression from the business rule it encodes.
QVD files are a Qlik-proprietary format with no native Power Query connector, so they cannot simply be plugged in. Wherever the original database or warehouse is still reachable, we re-point Power Query at it. Where a QVD is the only surviving copy, we stage it out to an open format first.
Set analysis modifies the selection an aggregation sees; CALCULATE modifies filter context. The intent maps closely, the syntax does not. We rewrite each expression as a named DAX measure, then reconcile its output against the same figure in QlikView before the report carrying it is signed off.
Partly, and we say so up front. Power BI has no direct equivalent of QlikView's associated and excluded states. What we rebuild instead is the job those colors did: slicers with clear applied filters, cross-highlighting between visuals, and explicit measures where knowing what was excluded genuinely drives a decision.
It follows the shape of your estate: how many documents move, how much logic sits in the load script rather than upstream, how many set analysis expressions need re-deriving, and whether the QVD layer can be bypassed. After a free consultation you get a written scope with one fixed price.
Section Access becomes row-level security: roles with DAX filter expressions applied to the semantic model rather than data dropped at reload. NPrinting distribution splits in two — pixel-perfect documents are rebuilt as paginated reports, and everything else becomes a Power BI subscription against the report that already exists.
Book a free consultation
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.