Migration von Qlik zu Power BI: kompakter Plan für Reports, Datenmodell und Governance

Definition

Die Migration von Qlik zu Power BI ist die strukturierte Überführung von Qlik Sense/QlikView-Apps, Datenmodellen, Transformationslogik und Berechtigungen in das Microsoft-Power-BI-Ökosystem. Sie ist kein reines Nachbauen von Visuals, sondern vor allem ein Umbau von Daten- und Berechnungslogik inklusive Governance und Betrieb.

Einleitung

Wenn Qlik bei euch teuer, schwer wartbar oder schlecht ins Microsoft-Ökosystem integrierbar ist, wird die Migration von Qlik zu Power BI schnell relevant. Damit der Wechsel nicht im Chaos endet, brauchst du vor allem Klarheit: Welche Reports sind wirklich wichtig, woher kommen die Daten, und wie beweist du nach dem Go-live, dass die KPIs stimmen. Dieser Artikel gibt dir einen kompakten, entscheidungsfähigen Plan.

Voraussetzungen vor dem Start: grob und im Detail

Grob brauchst du drei Dinge: ein sauberes Zielbild (welche Reports zuerst), verlässliche Datenzugänge und ein Team, das Zeit für Entscheidungen freimacht. Im Detail entscheidet die Vorarbeit über Budget, Risiko und Laufzeit.

• Report-/App-Inventar: Owner, Nutzerkreis, Aktualisierungsrhythmus, Kritikalität, „wird wirklich genutzt?“ (Qlik-Usage-Logs helfen).
• Ziel-Setup in Microsoft 365 / Office 365: Arbeitsbereiche, Deployment-Pipeline-Strategie (Dev/Test/Prod), Namenskonzept.
• Security-Klärung: Identitäten über Azure Active Directory / Microsoft Entra ID, Rollen und Datenzugriffe je Fachbereich.

Datenquellen identifizieren, bewerten und vorbereiten

Eine BI-Migration scheitert selten am Dashboard-Design, sondern an Datenzugriff und Datenqualität. Deshalb werden alle Quellen zuerst erfasst und bewertet: SQL Server, SharePoint, Excel-Files, Drittsysteme oder Exportstrecken aus Qlik.

Bewertungskriterien mit praktischem Nutzen: Aktualität (kann das automatisch refreshen?), Granularität (gibt es Beleg-/Transaktionsebene?), Stabilität (ändert sich das Schema häufig?). Vorbereitung heißt: Zugänge klären, Datenfelder vereinheitlichen (z. B. Konten-/Kostenstellenlogik), und bewusst entscheiden, was in Power Query (M) bereinigt wird und was besser upstream im ETL passiert.

Datenmodell-Mapping: Qlik-Logik nach Power BI übersetzen

Qlik arbeitet stark mit der Associative engine (assoziatives Modell, automatische Verknüpfungen). Power BI ist in der Praxis am stabilsten mit einem klaren relationalen Modell, meist Star Schema, betrieben über VertiPaq im Import mode oder über DirectQuery, wenn nötig.

• Keys/Verknüpfungen: Qlik-Synthetic Keys und viele-to-many-Muster werden in Power BI aktiv designt (Dimensionen/Fakten, eindeutige Schlüssel, saubere Beziehungen).
• Transformationslogik: Qlik Load Script wird typischerweise zu Power Query (M) oder zu Dataflows; Ziel ist nachvollziehbare, wiederverwendbare Datenaufbereitung.
• Berechnungen: Set Analysis wird zu DAX. Wichtig ist, dass KPI-Definitionen dokumentiert und testbar sind, sonst entstehen „neue Zahlen“.

Schritt-für-Schritt-Migrationsplan (Phasen und Verantwortlichkeiten)

Phase 1: Discovery & Scope

Fachbereich priorisiert Reports (Top 10 nach Business-Impact), IT klärt Datenzugänge. Ergebnis: Migrations-Backlog, Abnahmekriterien je Report, Risiko-Liste.

Phase 2: Daten-Fundament

Teams bauen die Anbindung der wichtigsten Quellen, definieren das Ziel-Datenmodell und legen Refresh-/Gateway-Strategie fest. Ergebnis: erstes stabiles Dataset/Semantikmodell als Basis für mehrere Reports.

Phase 3: Report-Migration

Reports werden in Power BI umgesetzt, bevorzugt mit nativen Visuals und klaren KPI-Seiten. Ergebnis: lauffähige Berichte in Test, inkl. Security und Performance-Checks.

Phase 4: Validierung, Parallelbetrieb, Go-live

Power BI läuft parallel zu Qlik, KPIs werden verglichen, Nutzer geben frei. Ergebnis: produktiver Rollout, Hypercare und Übergabe in den Betrieb.

Verantwortlichkeiten: Fachbereich liefert KPI-Definitionen und Abnahmen, IT verantwortet Zugänge/Security, BI-Team setzt Modell, Power Query/DAX und Dashboards um.

Risikobewertung, Qualitätsmanagement und Validierungskriterien

Typische Risiken sind Kompatibilität (Extensions, Speziallogik), Zeitaufwand durch ungeklärte Datenquellen und Akzeptanz („neues Tool, andere Logik“). Qualitätsmanagement braucht klare, messbare Kriterien statt Bauchgefühl.

• Validierung: definierte KPI-Vergleiche Qlik vs. Power BI (Toleranzen, Stichtage, Filterlogik), inklusive „Drilldown bis zur Buchung“.
• Performance: Ladezeiten, Refresh-Dauer, Modellgröße; bei Engpässen Aggregation tables oder Modellvereinfachung.
• Änderbarkeit: Berechnungen und Mappings sind dokumentiert, damit Teams später nicht wieder in Excel ausweichen.

Governance, Sicherheit und Compliance in Power BI

Berechtigungen werden in Power BI typischerweise über Row-Level Security (RLS) und Entra ID Gruppen abgebildet (als Gegenstück zu Section Access). Governance heißt: zentrale, geprüfte Datasets statt viele private Kopien, klare Workspace-Regeln und ein Veröffentlichungsprozess.

Praktischer Nutzen: Nutzer bekommen verlässliche „Gold“-Daten und bauen damit in Power BI oder Excel weiter, ohne jedes Mal die Datenlogik neu zu erfinden. Compliance wird einfacher, weil Zugriffe, Freigaben und Datenflüsse nachvollziehbarer sind als in vielen isolierten Qlik-Apps.

Kosten-, Lizenz- und Ressourcenüberlegungen (ohne Preise)

Für die Budgetplanung sind drei Blöcke entscheidend: Power-BI-Lizenzmodell (Wer erstellt? Wer konsumiert?), Infrastruktur/Betrieb (Gateways, Kapazität, Monitoring) und Migrationsaufwand (Modell + Reports + Tests). Ressourcenbedarf wird häufig unterschätzt: Ohne Fachbereichszeit für Abnahmen und KPI-Klärung wird jede BI migration teuer, egal welches Tool.

Best Practices, Stolpersteine und Mini-Checkliste

Best Practice ist „wertorientiert migrieren“: zuerst die Reports, die Entscheidungen steuern, nicht die, die am leichtesten sind.

• Stolperstein: 1:1-Optik statt 1:1-Logik zu priorisieren. Erst müssen KPIs stimmen, dann das Layout.
• Stolperstein: unklare Owner. Jeder Report braucht einen fachlichen Product Owner.
• Stolperstein: DirectQuery ohne Not. Oft ist Import mode stabiler und schneller.

Mini-Checkliste: Inventar der Qlik Apps, Top-Datenquellen & Zugriff, KPI-Katalog, Security-Mapping (Section Access → RLS), Validierungsfälle, Go-live-Kriterien.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn ihr parallel Tagesgeschäft habt, die Qlik-Logik komplex ist oder Governance/Security sauber sitzen muss. Typische Trigger: viele Apps ohne Doku, Performance-Probleme, Unsicherheit bei DAX und Datenmodellierung, oder wenn die BI-Umstellung „nebenbei“ passieren soll, ohne dass Teams ausbrennen.