Moving a Qlik estate to Amazon Quick: a field guide

Why Qlik estates resist migration

Most BI migrations are planned from a list of dashboards and a set of interviews. That works for a few dozen. It does not work for a Qlik estate of a few thousand apps, because the thing that makes each app work is not visible from the dashboard.

In Qlik, the transformation logic sits in the load script: SQL pulled from source systems, joined and concatenated in memory, reshaped through resident loads and mapping loads, and incrementally appended to QVD files that other apps then read. The business logic sits in chart expressions, often written with set analysis and functions that have no one-to-one equivalent elsewhere. Security sits in Section Access tables loaded by the same script.

None of that is in a warehouse you can query. It has to be read.

Step 1 — Inventory every app before choosing any

Start with an export of the whole estate: the load script for every app, and for Qlik Sense the output of qlik app unbuild, which carries the sheets, objects, measures and dimensions as JSON. Scripts and definitions are enough; no data rows are needed.

For each app, capture the sources it reads, the tables it builds, the visual objects it uses and every expression. Then score it. The drivers that consistently predict effort are:

• Script size, and the number of joins and resident loads — logic that must move into SQL or ETL
• Incremental load patterns — a pipeline redesign, not a dataset refresh
• Section Access — a row-level security design
• Hard expressions — set analysis, Aggr, inter-record functions, dollar-sign expansion
• Object types with no direct Amazon Quick equivalent — extensions, containers, some custom charts
• Loops and subroutines in the script

Step 2 — Trace the estate to its sources

Once every script is parsed, draw the estate as a graph: connections and files, the physical tables behind them, and the apps that read them. Two details matter more than they look. Tables must be keyed by their full name — dbo.Customers and mtg.Customers are different tables — and files loaded in a loop must be resolved to the pattern they read, not left as a variable.

The graph answers the planning question directly. In a synthetic test estate of several thousand apps that we built to rehearse this, one shared FX-rates QVD was read by every app, a calendar QVD by nearly half, and a Section Access table by more than a third. Those shared sources are the backbone of the migration: move them first, and each wave that follows is mostly presentation work.

Step 3 — Design the gold layer from the estate

The estate is the best requirements document you will get for the target data model. What the dashboards measure are the facts; what they group and filter by are the dimensions; the tables the scripts read are the upstream sources.

Two cautions from practice. First, conform aggressively: the same Region, Product or Month field appears across hundreds of apps and should become one dimension, not hundreds. Second, keep one fact per business process. Left to itself, a model built from a mixed estate tends to produce a single catch-all fact; loans, claims, payments and exposures belong in separate facts that share dimensions.

Step 4 — Translate expressions honestly

A large share of expressions are mechanical — sums, counts, averages, ratios and simple conditionals — and can be converted to Amazon Quick calculated fields automatically. The rest need a person, and the useful thing is to know exactly which ones.

• Set analysis: usually a filter on the calculated field, a parameter, or a pre-computed column in the gold layer
• Aggr: level-aware calculations in Amazon Quick, or an aggregate table if it is reused
• Above, Before and RangeSum: window functions such as runningSum and lag
• Dollar-sign expansion: parameters or controls, decided per case
• Dual and formatting tricks: field formatting in the analysis

Step 5 — Rebuild security, don't copy it

Section Access maps users to reduction values inside the Qlik app. Amazon Quick expresses the same intent as row-level security on datasets, driven by user or group rules. The rules can often be generated from the existing Section Access tables, but identity mapping — which Qlik user is which directory user — is a decision for your security team, and it is easier to make once for the estate than once per app.

Step 6 — Reconcile, then sign off

Every migrated dashboard needs its key numbers compared with the original: the same filters, the same period, an agreed tolerance, and a named owner who signs it off. Build the reconciliation checks into the plan for each app rather than leaving them to user acceptance testing.

Plan in waves, calibrated by a pilot

Per-app effort bands are a starting point, not a quote. Pick five to ten representative apps across the complexity tiers, take them end to end — gold model, starter packs, translation, security, reconciliation — and use what they actually took to calibrate the bands. Then plan the waves around the shared sources from step 2.

Where Data Foundations fits

Data Foundations does steps 1 to 3 for the whole estate in the background, flags what step 4 and step 5 will need, and gives your team an Amazon Quick starter pack per app with the mechanical conversions done and everything else listed. Your people make the decisions; the platform makes sure they are making them with the whole estate in view.