Qlik to Snowflake Migration Checklist: 12 Questions for BI Teams

A scoping artifact for BI managers and CIOs — twelve audit questions covering inventory, architecture, team, and decision readiness, designed to be answered before any vendor conversation starts.

If you've decided that a Qlik-to-Snowflake migration is coming — or you've been told one is — the next conversation in your organization is the scoping conversation. How long will it take? How many people? What's the budget? What could go wrong?

The mistake most teams make is to scope the migration as a technical project. The technical work is the visible work, but it's not where projects stall. Projects stall on inventory the team didn't know existed, on political conversations nobody had at the start, and on decisions that got conflated when they should have been separated. This checklist is structured to surface those before they cost you a quarter.

It is twelve audit questions across four categories. Each one is designed to be defensible in front of your CIO or CFO. If you can't answer all twelve with confidence, you're not ready to scope a timeline — you're ready to do the scoping work that comes before the timeline. That's the right place to be.

For the strategic framing this checklist sits inside, see the our guide on migrating from Qlik to Snowflake. For the architectural reasons the modernization matters, see the broader companion piece on legacy BI vs. cloud-native BI.

TL;DR

The migration is a logic-relocation project, not a tool swap, and the scoping work that actually matters has more to do with inventory honesty, architectural decisions, and political readiness than with vendor selection. Twelve audit questions, grouped into four categories. If you can answer all twelve, your scoping is defensible. If you can't, you've found the work that comes before scoping.

Pre-migration inventory

The inventory phase is where 60-80% of migration projects discover scope they hadn't planned for. Mature Qlik environments accrete complexity invisibly — apps get built, ownership rotates, documentation lags, and the team genuinely doesn't know what they have until they look.

1. Do you know how many Qlik apps your inventory will reveal that nobody admits owning?

Every mature Qlik environment has apps in production that no current employee will claim. Built three years ago by someone who left. Used by a function that doesn't formally own them. Critical to one team's weekly process and unknown to the BI team that operates the platform. Your inventory will find these. Plan for the discovery phase to surface 20-40% more apps than your current documentation lists, and budget the triage work — keep, replace, retire — before you commit to a migration timeline.

Warning sign: if your current Qlik administrator can't name an owner for every app in production, you have inventory work to do before any scoping conversation.

2. Have you mapped your load script logic — separating real business logic from Qlik-architecture workarounds?

Mature Qlik environments contain a decade of accumulated load script logic. A significant fraction of it exists not to serve the business but to work around Qlik's own architecture — QVD optimization, incremental reload tricks, set analysis written to fake what SQL does natively. Faithfully porting these workarounds means rebuilding solutions to problems you no longer have. The teams whose migrations succeed audit each piece of logic with one question: would we write this if we were starting from scratch? The answer eliminates 30-50% of the work. Gray Decision Intelligence's 50-75% cost savings after replacing Qlik came in part from being honest about what to recreate and what to retire.

Warning sign: if your project plan assumes every existing piece of load script logic needs a corresponding artifact in the new platform, your scope is inflated.

3. Have you identified which Qlik IP is most expensive to recreate, and which you can safely retire?

Not all Qlik investment is equal. Some of it is genuine business logic worth preserving in the new architecture. Some of it is dashboards nobody opens. Some of it is master items that turned out to be doing more than their names suggested. The triage matrix is straightforward: critical, important, replaceable, orphaned. The mistake is to treat all four categories as if they need to migrate.

Warning sign: if your project plan assumes every existing Qlik app needs a corresponding artifact in the new platform, your scope is inflated by 30-50%.

Warehouse and architecture readiness

The migration's largest strategic decisions are architectural, not procedural. They happen — explicitly or implicitly — in the first weeks of the project, and they shape everything downstream.

‍4. Have you decided where business logic will live after the move — in the warehouse, or in the new BI tool?

This is the single most consequential decision in the migration. Two paths. Logic lives in the warehouse — expressed in dbt models, Snowflake views, or a headless semantic layer — and the BI tool becomes a thin presentation tier reading from it. Or logic lives in the BI tool — expressed in its calculation language — recreating the architecture you have today in Qlik. The first path is the modernization opportunity. The second is the lift-and-shift trap. This decision shapes the BI tool selection, the data engineering work, the team composition, and the project timeline.

Warning sign: if your project plan doesn't name dbt or an equivalent warehouse-side modeling layer as part of the work, you've defaulted to path two without choosing it.

‍5. Have you sized your Snowflake warehouses for live-query BI traffic, not just batch ELT?

Snowflake compute configuration optimized for nightly ELT batches is not configured for the query pattern that warehouse-native BI generates. Live-query dashboards generate small, frequent queries throughout the working day. Without the right warehouse sizing, auto-suspend settings, and query routing, dashboard performance suffers and Snowflake costs compound in ways that look like the BI tool's fault but aren't. Your data engineering team needs to be in the scoping conversation, not just informed of the outcome.

Warning sign: if your current Snowflake warehouse architecture has one warehouse handling ELT, ad-hoc queries, and dashboards together, plan for warehouse separation as part of the migration project.

‍6. Have you designed a Snowflake-native security model rather than trying to port Qlik section access?

Qlik section access doesn't migrate cleanly. It's tightly coupled to Qlik's identity model, and most aged section access deployments aren't the clean security model they were originally designed as — they've accreted exceptions over years. The migration is the one opportunity to rebuild security correctly in the warehouse layer, with Snowflake's row access policies governed by the same identity system that controls every other data asset. Switch RCM's behavioral healthcare deployment is the example most often cited — they didn't port section access; they rebuilt their security model warehouse-native from the start, which was the precondition for everything else they wanted to do.

Warning sign: if anyone on your team uses the phrase "port section access" in a planning meeting, redirect the conversation. Section access doesn't migrate. It gets rebuilt.

‍Team and project readiness

Migrations are political projects as much as technical ones. Most projects that stall, stall on conversations the team should have had earlier — about authority, about identity, about commitment to a date.

‍7. Do you have a migration lead with the authority to make decisions and resolve political conflicts?

A migration lead without decision authority is a coordinator, not a lead. Coordinators can keep meetings on schedule. Leads can resolve disputes about which dashboards get rebuilt, which Qlik power users get retrained vs. reassigned, and what the team does when the inventory phase reveals scope that breaks the original timeline. The role needs an executive sponsor behind it who will defend hard decisions in front of the people whose dashboards are affected.

Warning sign: if the migration lead reports into a function that doesn't own the outcome, the role won't survive contact with the political conversations the project will generate.

‍8. Is there a realistic plan for the identity transition your Qlik developers will go through?

Your Qlik developers have spent five to fifteen years getting good at Qlik script, set analysis, master items, and the QIX engine's quirks. The migration recasts them as analytics engineers working in dbt, SQL, and a warehouse-native semantic layer. The skill base they spent a decade building feels invalidated. Teams that don't manage this transition explicitly lose their best Qlik developers — who leave for other Qlik shops rather than retrain — and end the project with weaker analytics capability than they started with. The plan should name how skills get transferred, who gets training time, what the career path looks like, and what the role becomes in the new architecture.

Warning sign: if your project plan budgets training hours for business users but not for your Qlik developers, you have an attrition risk you haven't priced in.

‍9. Have you set a Qlik sunset date — and is leadership willing to defend it when the parallel-run feels safer?

The most common reason migrations don't finish is that the parallel-run phase extends indefinitely. Both systems work. Nobody is forced to choose. The new system is good enough to use but the old system is comfortable enough to keep, so the team keeps both, paying for both, maintaining both. The sunset date needs to be set at the start of the project and defended through to the end.

Warning sign: if your project charter doesn't include a Qlik decommissioning date and a named executive who owns enforcement of it, the parallel-run will outlast the migration.

‍Decision readiness

The strategic decisions that shape the migration's outcome happen before any vendor is selected. Conflating these decisions — or deferring them to vendor conversations — is how teams end up with a tool that fits an architecture they hadn't decided to commit to.

10. Have you separated the "do we migrate" decision from the "which BI tool" decision?

These are two decisions, and most teams treat them as one. The result is that the BI tool selection becomes the proxy fight for the migration commitment, and the actual architectural decisions get buried inside vendor pitches. The right sequence is: decide whether to migrate based on the strategic case (cost, capability, talent, architecture). Then decide on the architecture (where logic lives, what the warehouse stack looks like). Then — and only then — evaluate BI tools that fit the architecture you've chosen.

Warning sign: if your team is comparing BI vendor demos before you've decided where business logic will live after the move, the BI tool decision will drive your architecture instead of the other way around.

‍11. Have you baselined the engineering hours your team spends maintaining Qlik reloads, before the migration removes them?

Qlik teams have lived with reload-cycle maintenance for so long that the cost has become invisible. Quantify it honestly before the migration starts and the numbers are usually startling — one to two engineer-equivalents per year in mature environments goes into fixing failed reloads, optimizing slow ones, and tuning incremental-load logic. After the migration, that effort disappears. But it only counts as a documented win if you measured it beforehand. The same baselining applies to data latency, dashboard delivery cycles, and the categories of decisions the business has stopped requesting because they assumed they were impossible.

Warning sign: if the only success metric in your project plan is cost reduction, you've under-scoped the wins your CFO will care about most.

12. Have you defined what "success" looks like to your CFO, not just to your BI team?

Your BI team will measure the migration by the things they care about — dashboard performance, developer velocity, fewer 6 a.m. failures. Your CFO will measure it by the things they care about — total cost of analytics, time-to-insight on business decisions, headcount efficiency. These metrics don't conflict, but they're not the same, and the migration's perceived success depends on which set gets surfaced to leadership. Define both. Communicate both. Report on both. Gray Decision Intelligence's 50-75% cost reduction was the headline, but the longer-term win was the engineering capacity returned from Qlik maintenance back into product work — a metric the BI team would never have surfaced without deliberate baselining.

Warning sign: if your success metrics live only in a BI team dashboard and not in a leadership steering committee artifact, the migration will be evaluated on the wrong outcomes.

What to do with this checklist

Twelve items. If you can answer all twelve with confidence, your scoping is defensible. You can walk into a leadership conversation with a timeline, a team plan, and a budget that will survive contact with the actual project.

If you can't answer all twelve, you've found the scoping work that comes before the scoping conversation. That work is cheaper to do now than after the project has started and a leadership team is asking why month four looks different from month four in the plan.

The checklist is paradigm-neutral. The items above will be useful whether your migration ends with a warehouse-native BI tool, a hybrid stack, or — for some teams in specific contexts — a decision to stay on Qlik with a clearer-eyed view of why. The point isn't to push you toward a particular tool. It's to help you walk into the vendor conversations with the questions that actually matter already answered.

For the strategic case behind the migration, see the Complete Guide to Migrating from Qlik to Snowflake. For the architectural reasons modernization matters, see Legacy BI vs. Cloud-Native BI: What's Actually Different.

If you're at the BI platform decision moment and you want to evaluate warehouse-native options, Astrato is one of several options worth your shortlist — alongside Sigma and Looker — that fit the architecture this checklist is designed to help you choose.