Content
QlikView 12.90 loses standard Qlik support in October 2026. QlikView 12.100 follows in September 2027. After those dates, your organization absorbs the full operational and security risk of running unsupported software — no guaranteed escalation path, no maintenance updates, and an increasingly thin pool of people in the market who can still work on it.
But the deadline is only part of the story. Many organizations have been feeling the pressure for longer: reports queuing up for weeks, vendors charging premium rates for simple changes, power users who want to build their own views being told to raise a ticket. The move to Power BI makes business sense regardless of the EOS date.
What most organizations don’t anticipate is how much the migration path varies depending on what they’ve built up in QlikView over the years. A migration from a focused, well-maintained estate of 15 reports looks almost nothing like one from an enterprise environment with 120 apps, a QVD staging layer, NPrinting report suites, and decade-old load scripts that nobody has fully read.
Why You Can’t Just “Move” QlikView to Power BI
The first thing to understand is that there is no export button. You cannot open a QlikView app and save it as a Power BI file. The two tools are built on fundamentally different ideas about how data should work.
QlikView uses an associative model — think of it as a web where every table connects to every other table, and the tool figures out the relationships as users click and filter. Power BI uses a structured model, where the designer explicitly defines how tables relate to each other in advance, usually in a pattern called a star schema. Neither is wrong. But they don’t translate directly into each other.
Beyond the data model, QlikView environments accumulate business logic inside load scripts — the code that runs before data reaches the dashboard. Joins, transformation rules, KPI definitions, fiscal calendar logic: all of it ends up embedded in scripts that live inside the BI tool. Modern Power BI architecture puts that logic somewhere else entirely — in a dedicated data pipeline or platform. Migration means deciding where all of that accumulated logic now lives and rebuilding it there, not copying it across.
Security adds a third layer. QlikView controls access through section access, typically embedded in load scripts. Power BI handles this through Row-Level Security (RLS), configured explicitly in the data model and integrated with your identity management system. For organizations with regulatory requirements (HIPAA, SOX, PCI), getting this wrong has compliance consequences — not just configuration ones.
Migration is a re-architecture project, not a file conversion. That distinction changes how you plan, scope, and estimate the work.
For a deeper look at sound Power BI architecture: Power BI Dashboard Architecture — Building Decision Systems, Not Just Visuals.
Understand Your Environment First – Three Complexity Tiers
Before choosing a migration path, you need an honest picture of what you’re migrating from. The most reliable way to underestimate a migration is to assume it is simpler than it is; the most reliable way to overscope it is to catalog everything without distinguishing what matters from what can be retired.
Most QlikView environments fall into one of three complexity tiers:
| Tier 1 — Simple | Tier 2 — Medium | Tier 3 — Complex | |
|---|---|---|---|
| Typical estate size | 10–20 apps | 30–60 apps | 100+ apps |
| QVD/data staging layer | None or minimal | Established QVD layers | Deep, multi-level QVD architecture |
| Section access / security | Limited | Moderate | Complex, often regulatory |
| NPrinting / scheduled reports | No | Sometimes | Yes, typically at scale |
| ERP / system integrations | Few, well-understood | Several sources | Multiple, some undocumented |
| Documentation state | Reasonable | Partial — someone “knows how it works” | Significant institutional knowledge locked in scripts |
| Migration type | Project | Project, phased by domain | Multi-domain program |
| AI compression potential | Medium | High | Very high |
The tier your environment falls into shapes every decision that follows — which architecture path to choose, how long the project will take, and where AI tools deliver the most time savings.
The Four QlikView-to-Power BI Migration Architecture Paths
The central decision in a QlikView-to-Power BI migration is not which reports to build first. It is what platform sits between your source systems and Power BI — the data layer where transformation, storage, and preparation happen. Get it right, and the migration has a stable foundation. Get it wrong, and you are building technical debt from day one.
Path 1: Direct to Power BI — Fast Start, Known Trade-offs
Power BI connects directly to your source systems, with no separate data platform in between. Power Query — Power BI’s built-in transformation tool — handles any data preparation before it reaches the reports.
This is the fastest and lowest-cost option to implement. It suits Tier 1 environments with a limited number of reports, stable source data, and no short-term plans to expand into AI-driven analytics. The trade-off: as the portfolio grows or data volumes increase, the absence of a proper data layer becomes a constraint. Organizations that start here often find themselves rebuilding the foundation within a few years. Treat it as a valid first step, not a permanent architecture.
Path 2: Microsoft Fabric — Recommended Long-Term Choice
Microsoft Fabric is Microsoft’s integrated data platform — it brings data engineering, storage, and analytics into one environment, with Power BI as the native reporting layer on top. Data is stored in a format Power BI can query directly without first copying it into a separate model, which matters for performance and data freshness.
For organizations in the Microsoft ecosystem, Fabric is the recommended long-term architecture. It integrates natively with Power BI, supports built-in Copilot and AI capabilities, and provides the governance layer enterprise BI environments require. It suits all three complexity tiers, with setup investment scaling accordingly. Critically, Power BI’s AI roadmap — Copilot, natural language querying, AI-generated insights — runs through Fabric. Organizations that build on Fabric during migration position themselves to activate those capabilities progressively rather than face a second platform migration later.
For a broader look at fabric-based architectures: Data Fabric — Benefits and Use Cases and Lakehouse Architecture — Combining Data Lakes and Warehouses.
Path 3: Databricks — For Data Engineering and ML-Heavy Organizations
Databricks handles large-scale data processing, Python and Spark-based pipelines, and machine learning workloads exceptionally well. It is the right choice when data engineering and machine learning are equal priorities alongside BI reporting — not when the primary goal is recreating and improving existing QlikView reports. For migrations focused on BI, Databricks introduces more infrastructure complexity than necessary. It is best suited to Tier 3 environments where the migration is one component of a broader data platform modernization.
Path 4: Snowflake — Vendor-Neutral, Multi-Cloud Flexibility
Snowflake runs equally well on Azure, AWS, and Google Cloud, separating storage and compute so each can scale independently. Its key advantage is vendor neutrality — a strong choice for organizations operating across multiple cloud providers or with strategic reasons to avoid single-vendor dependency. Its Time Travel feature, which allows querying historical data snapshots, is particularly useful during migration validation. For organizations already deeply invested in the Microsoft stack, Fabric will generally be more cost-effective. Snowflake is the stronger choice where cloud flexibility is an explicit requirement.
Architecture Path Comparison
| Direct to Power BI | Microsoft Fabric | Databricks | Snowflake | |
|---|---|---|---|---|
| Best suited for | Tier 1 (simple) | Tier 1–3 | Tier 3 (ML-heavy) | Tier 2–3 (multi-cloud) |
| Setup complexity | Low | Moderate | High | Moderate–High |
| Long-term scalability | Limited | High | High | High |
| AI/Copilot integration | Basic (none native) | Native — best | Strong | Snowflake Cortex / ML |
| Microsoft ecosystem fit | Good | Native | Good | Good |
| Indicative platform cost/month | ~€0 extra | ~€260–€1,040 (F2–F8) | ~€200–€800 (DBU) | ~€200–€1,200+ (credits) |
| Indicative total effort (~5 reports) | ~416h | ~576h | ~608h | ~592h |
| Recommended for | Fast starts, simple estates | Most organizations | ML / data engineering priority | Multi-cloud, vendor flexibility |
See our Modern Data Architecture Services for guidance on selecting the right platform.
Not sure which architecture path fits your environment?
We review your estate and walk you out with a clear recommendation — before any commitments are made.
Protect your data and stay compliant.
Protect your data and stay compliant.
How AI Changes Our QlikView Migration Equation
The practical reality of QlikView migration has changed significantly in the past two years. Not because the technical challenges are different — they aren’t — but because AI tooling now compresses the effort at every stage of the process.
Historically, migration meant weeks of manual analysis before any development could begin: reading load scripts line by line, documenting what each app actually does, mapping KPI definitions to Power BI equivalents, running parallel validation by hand. This work is slow, expensive, and requires specialists who know both QlikView and Power BI simultaneously — a genuinely rare combination.
AI-assisted delivery does not remove any of that work. It compresses it — typically reducing total migration effort by 30–40% compared to a conventional approach. That translates directly into lower cost, a shorter timeline, and less disruption during transition.
Here is where that reduction comes from:
| Migration Stage | What AI Does | Time Saved vs. Manual |
|---|---|---|
| QlikView script analysis | Reads all load scripts, maps joins and flags business logic automatically — instead of weeks of manual review | ~40% |
| KPI cataloguing | Generates a full KPI inventory from QVW files, ready for business review and validation | ~30% |
| DAX / data model translation | Produces first-draft DAX measures and Power Query transformations as a starting point for developer refinement | ~35% |
| Report layout scaffolding | Scaffolds Power BI report layouts from QlikView reference screenshots | ~25% |
| QA & reconciliation | Automated diff tooling compares Power BI output against QlikView; deviations flagged rather than manually hunted | ~50% |
What AI does not do is equally important. It does not make business decisions, determine whether a KPI definition is correct (only whether Power BI matches QlikView logic), or replace the judgment of experienced architects making model design decisions. Structured business validation at every stage remains mandatory.
AI accelerates. Humans validate, design, and own the outcomes.
What to Expect? Timelines by Environment Complexity
The most common scoping mistake is applying a single estimate to every QlikView migration. Here is a realistic picture based on environment tier, using an AI-assisted delivery approach.
Tier 1 — Simple
An AI-assisted migration of 10–20 apps with well-understood data models and limited section access can typically be delivered in 11–12 weeks from kickoff to go-live — covering assessment, data model design, Power BI build, parallel validation, and QlikView decommission.
Tier 2 — Medium
A scope covering 30–60 apps with QVD layers and more complex business logic is typically a 4–6 month engagement. The QVD pipeline re-engineering — moving transformation logic out of QlikView and into the target data layer — and the parallel validation phase consistently take longer than initial estimates suggest. These are also the stages where AI compression delivers the most time savings.
Tier 3 — Complex Enterprise
A full enterprise migration covering 100+ apps, complex section access, NPrinting, and ERP integrations is a phased program — typically 18–36 months — with individual business domains migrated and decommissioned sequentially rather than all at once.
One component that is consistently scoped separately regardless of tier: historical data migration. QlikView environments often store years of extracts in QVD files or legacy formats. Whether those archives are worth migrating, and how, requires a dedicated archive audit before scope can be confirmed. Treating historical data as a default inclusion in initial estimates is a reliable path to significant overruns.
Before migration starts: Data Profiling and Cleansing — The First Step Before Any Migration or AI Project.
Our Data Consulting Services You Might Find Interesting
QlikView to Power BI Switch – Intermediate Options and Bridge Solutions
Not every organization is ready to commit to a full migration immediately. Three intermediate steps are genuinely worth considering — as long as they are treated as steps, not substitutes.
Portfolio rationalization before you migrate
Deciding which QlikView assets are worth migrating before any Power BI development begins is one of the highest-value activities in a migration program. In most established estates, a meaningful share of reports are rarely used, duplicated, or were built for projects that no longer exist. Based on our experience, a structured Rebuild / Consolidate / Retire assessment consistently reduces migration scope by 25–40% — lowering cost, shortening the timeline, and ensuring the resulting Power BI environment doesn’t carry the same clutter as the old one.
Upgrading to QlikView 12.100 to extend the support window
Organizations on QlikView 12.90 (EOS: October 2026) can upgrade to 12.100, extending standard support to September 2027. This is a legitimate tactical move when migration planning needs more time to be done properly — a rushed migration built on an inadequate assessment costs more than one that started six months later. The important caveat: upgrading QlikView does not solve any of the operational constraints that make migration compelling in the first place. The upgrade extends the planning window; it should prompt migration planning to begin immediately, not to be deferred.
Phased domain-by-domain migration
For Tier 2 and Tier 3 environments, migrating everything at once is rarely the right approach. Starting with a single business domain — Finance is a common choice: high visibility, well-defined metrics, executives who notice quickly when numbers are wrong — allows the organization to build Power BI competency progressively, demonstrate value early, and decommission QlikView incrementally rather than requiring the entire estate to be ready before any decommissioning happens.
Five Reasons QlikView Migrations Fail — and How to Avoid Them
Most migrations that go wrong don’t fail because of technology. They fail because of decisions made in the planning stage.
1. Rebuilding QlikView logic instead of redesigning it
Recreating QlikView’s associative logic in Power BI using many-to-many relationships and bidirectional joins consistently produces an environment that performs poorly and is hard to maintain. The data model must be redesigned for Power BI’s architecture, not replicated from QlikView’s.
2. Skipping portfolio rationalization
Starting development without auditing what is worth migrating means building Power BI versions of reports nobody uses. The new environment arrives on day one carrying the same clutter as the old one.
3. Underestimating the QVD layer
In mature environments, the QVD layer has become a de facto data warehouse, and the transformation logic embedded in it is invisible from the dashboard. Moving that logic into a proper data platform is frequently the most complex and most underestimated phase of the migration. For context, this is the same kind of pipeline re-engineering described in SSIS to Azure Data Factory — Modernizing ETL, applied to QlikView’s load script layer.
4. Treating Row-Level Security as an afterthought
RLS needs to be designed from the start — it shapes the data model architecture. For organizations with regulatory compliance requirements, retrofitting it after the build is complete can require significant rework.
5. Decommissioning QlikView on a schedule rather than on evidence
Committing to a shutdown date before parallel validation is complete is the most common cause of post-migration trust collapse. Users find discrepancies, confidence in the new numbers evaporates, and the old QlikView instance quietly keeps running alongside Power BI for another year. Decommission on proof — not on optimism.
How to Start? The Migration Assessment with Multishoring
No two QlikView environments are the same. Generic estimates applied without proper investigation consistently miss the specific complexity that defines each migration’s real scope and risk.
A proper assessment covers: full inventory of the estate (apps, scripts, QVD layers, data sources, section access rules); business criticality and usage scoring for each asset; a Rebuild / Consolidate / Retire decision for every report; architecture path recommendation with rationale; realistic effort and timeline estimates with phasing recommendations; and an initial view of where AI-assisted delivery compresses the most effort in your specific environment.
A typical engagement then delivers the following across all architecture options.
| Deliverable |
|---|
| AI-assisted extraction and analysis of QlikView load scripts, joins, KPIs and data flows |
| Provisioning and configuration of the selected intermediate data layer |
| Connection to relevant source systems |
| Migrated reports in Power BI, with KPI logic extracted from QlikView, validated with the business, and re-implemented |
| Modernized report layout and consistent design aligned with Power BI best practices |
| Implementation of agreed improvements — new filters, updated KPIs or consolidated views |
| Automated validation of Power BI outputs against business-approved reference outputs before handover |
| Power-user and administrator training, supported by a maintenance guide |
The output is a migration roadmap you can plan and budget against — not a proposal built on unexamined assumptions.
Given the QlikView 12.90 EOS deadline in October 2026, organizations on that version should begin assessment now. Not because migration needs to be complete by then in all cases, but because a proper assessment takes time, and starting it in the second half of 2026 leaves no runway for planning.
Get Your QlikView Migration Assessment with Multishoring →
