Excel zu SQL Migration: Praktischer Leitfaden für Business-Analysten

Du verwaltest seit Jahren Daten in Excel — VLOOKUP, SUMIF, Pivots, die ganze Palette. Es funktioniert, meistens. Aber dann wächst der Datensatz über 100.000 Zeilen, drei Personen bearbeiten dieselbe Datei und plötzlich referenzieren deine Formeln Zellen, die nicht mehr existieren. SQL löst diese Probleme, und die Lernkurve ist kleiner als du denkst, wenn du schon Excel kannst. Das ist der praktische Leitfaden zur Excel-zu-SQL-Migration, den niemand mal klar geschrieben hat.

TL;DR

• SQL ist set-based statt zell-based — der Mental-Shift ist der schwerste Teil
• VLOOKUP → LEFT JOIN, SUMIF → SUM + GROUP BY, Pivot → GROUP BY mit Aggregaten
• NULL behandelt SQL anders als Excel — IS NULL statt = NULL
• LEFT JOIN als Default bis du Daten-Beziehungen voll verstehst
• Klein anfangen: ein Arbeitsblatt nach SQL portieren, validieren, nächstes

Warum sich die Migration lohnt

Vor der Mechanik: SQL ist nicht "Excel, aber schneller". Es ändert, wie du über Daten denkst.

Excel ist zell-basiert. Du denkst in einzelnen Zellen, Bereichen und Formeln, die Koordinaten referenzieren. SQL ist set-basiert. Du denkst in Operationen auf ganzen Tabellen gleichzeitig. Sobald dieses Modell klickt, löst du Daten-Probleme schneller.

Konkrete Vorteile vom Wechsel:

• Datensätze beliebiger Größe (Millionen Zeilen sind Routine)
• Keine Versions-Konflikte — die Datenbank ist Single Source of Truth
• Reproduzierbare Analyse — deine Query ist die Doku
• Kollaboration ohne File-Locking-Albträume
• Auditierbarkeit — Queries sind Text, gehen in Versionskontrolle

Migrations-Roadmap

graph TD
    A["① Dein Excel-Workbook"]:::blue --> B["② Datenstruktur<br/>auditieren"]:::amber
    B --> C["③ Excel-Konzepte<br/>auf SQL mappen"]:::amber
    C --> D["④ Daten in eine<br/>SQL-Datenbank laden"]:::green
    D --> E["⑤ Formeln als<br/>SQL-Queries neu schreiben"]:::green
    E --> F["⑥ Resultate gegen<br/>Excel-Baseline validieren"]:::amber
    F --> G["⑦ Spreadsheet<br/>außer Dienst nehmen"]:::rose

    classDef blue fill:#D6DCF5,stroke:#7B83B0,stroke-width:1.5px,color:#2B3674,font-weight:bold
    classDef green fill:#D8E4BF,stroke:#9AAF78,stroke-width:1.5px,color:#2B3674,font-weight:bold
    classDef amber fill:#F0E2C8,stroke:#C4A97A,stroke-width:1.5px,color:#2B3674,font-weight:bold
    classDef rose fill:#F5D5D5,stroke:#C49A9A,stroke-width:1.5px,color:#2B3674,font-weight:bold

① Beginne mit deinem tatsächlichen Workbook — versuche nicht zuerst zu "redesignen". Bring es in SQL zum Laufen, dann optimiere.

② Auditiere deine Datenstruktur — identifiziere, welche Arbeitsblätter Rohdaten-Tabellen sind vs. Berechnungs-Sheets vs. Dashboards. Nur die Rohdaten-Tabellen wandern direkt nach SQL.

③ Mappe Konzepte — nutze die Referenz-Tabelle unten.

④ Lade die Daten — exportiere als CSV und importiere in eine SQL-Datenbank (PostgreSQL ist für Anfänger am freundlichsten).

⑤ Schreibe deine Formeln neu — eine nach der anderen, mit dem Mapping-Guide.

⑥ Validiere — lass deine SQL-Query und deine Excel-Formel parallel auf einer bekannten Stichprobe laufen. Zahlen müssen matchen, bevor du SQL vertraust.

⑦ Außer Dienst nehmen — sobald die SQL-Version validiert ist und stabil läuft, archiviere das Spreadsheet.

Die Excel → SQL Konzept-Map

Diese Referenz-Tabelle nutzt du ständig während der Migration. Bookmarke sie.

SQL-Code-Beispiele

Beispiel 1: SUMIF durch GROUP BY ersetzen

In Excel würdest du =SUMIF(region_spalte, "Nord", umsatz_spalte) in jeder Zeile einer Summen-Tabelle nutzen — eine Formel pro Region, wiederholt.

In SQL berechnest du alle Regionen auf einmal:

-- PostgreSQL
-- Ersetzt: mehrere SUMIF-Formeln, eine pro Region
-- Zeigt: Gesamtumsatz, Bestellanzahl, durchschnittlicher Bestellwert pro Region

SELECT
    region,
    SUM(amount)         AS total_sales,
    COUNT(*)            AS order_count,
    ROUND(AVG(amount), 2) AS avg_order_value
FROM orders
WHERE order_date >= '2025-01-01'
  AND order_date <  '2026-01-01'
GROUP BY region
ORDER BY total_sales DESC;

Das ersetzt, was in Excel eine Pivot-Tabelle gewesen wäre — und läuft gleich schnell auf 100 oder 100 Millionen Zeilen.

Beispiel 2: VLOOKUP durch JOIN ersetzen

VLOOKUP ist eine der meistgenutzten Excel-Formeln. Sie sucht einen Wert in einer Tabelle und gibt eine Spalte aus der passenden Zeile zurück. In SQL ist das ein JOIN.

-- PostgreSQL
-- Ersetzt: =VLOOKUP(A2, customers_sheet, 3, FALSE) für customer_name pro Order
-- LEFT JOIN behält alle Orders, auch wenn kein passender Kunde existiert
--   (entspricht VLOOKUP mit #N/A — hier kommt NULL stattdessen)

SELECT
    o.order_id,
    o.order_date,
    o.amount,
    c.customer_name,
    c.email,
    c.region
FROM orders AS o
LEFT JOIN customers AS c
    ON o.customer_id = c.customer_id
ORDER BY o.order_date DESC;

Achte auf LEFT JOIN — es behält alle Zeilen aus orders, auch wenn kein passender Kunde existiert. Ein INNER JOIN würde diese Zeilen still fallen lassen, was meist nicht erwünscht ist.

Bonus-Beispiel: Pivot-Summen ersetzen

-- PostgreSQL
-- Ersetzt: Pivot-Tabelle mit monatlichem Umsatz nach Produktkategorie

SELECT
    DATE_TRUNC('month', order_date)::date  AS month,
    category,
    SUM(amount)                            AS revenue,
    COUNT(DISTINCT order_id)               AS num_orders
FROM orders
JOIN products USING (product_id)
WHERE order_date >= '2025-01-01'
GROUP BY 1, 2
ORDER BY 1, 3 DESC;

Häufige Stolpersteine

1. Spalten-Positionen wie Excel-Bereiche behandeln In Excel heißt VLOOKUP(A2, B:D, 3, FALSE) "gib die 3. Spalte zurück". In SQL referenzierst du Spalten immer über Namen. Das ist eigentlich besser — deine Queries brechen nicht, wenn Spalten umgeordnet werden.

2. NULL vs. leerer String vergessen Excel behandelt leere Zellen in numerischen Formeln als Null. SQL behandelt NULL anders als 0 oder ''. SUM(amount) ignoriert NULLs. COUNT(*) zählt sie. amount = NULL gibt nie true zurück — nutze amount IS NULL. Das stolpert fast jeden Excel-zu-SQL-Migranten.

3. JOINs droppen still Zeilen INNER JOIN dropt Zeilen ohne Match. Das entspricht VLOOKUP, wo #N/A-Zeilen einfach entfernt werden — was du in Excel nie akzeptieren würdest. Starte mit LEFT JOIN, bis du die Datenbeziehungen voll verstehst.

4. Die erste Query überkomplizieren Analysten versuchen oft, ihr komplexestes Excel-Modell in einer SQL-Query nachzubauen. Schreib die einfachste mögliche Query. Validiere. Erweitere inkrementell.

5. SQL-Dialekte ignorieren DATEDIFF('day', start, end) funktioniert in Databricks SQL. DATE_DIFF(end, start, DAY) in BigQuery. end - start (gibt Tage als Integer zurück) in PostgreSQL. Prüfe besonders bei Datums-Funktionen den Dialekt.

Du musst nicht alles selbst schreiben

Ein großer Friction-Punkt im Excel→SQL-Umstieg ist, die exakte Syntax für eine unbekannte Operation nicht zu wissen. Genau hier hilft Harbinger Explorer — du tippst eine Frage in Klartext ("zeig mir den Gesamtumsatz pro Region für letztes Quartal") und es generiert die SQL-Query für dich. Eine gute Möglichkeit, die Lücke zu überbrücken, während du SQL-Fluency aufbaust — du lernst durch Lesen der generierten Queries.

FAQ

Wie lange dauert die Migration eines typischen Workbooks? Für ein Workbook mit 5–10 Tabs und mittlerer Komplexität: 1–3 Tage inklusive Validierung. Komplexe Modelle mit verschachtelten Berechnungen können eine Woche dauern.

Welche SQL-Datenbank für Einsteiger? PostgreSQL ist am freundlichsten — gute Doku, breiter Dialekt-Support, viele Tools. Für Cloud-First: BigQuery (Google) oder DuckDB (lokal).

Brauche ich einen Datenbank-Server? Nicht zwingend. DuckDB läuft als Embedded-Datenbank auf deinem Rechner — keine Server-Installation nötig. Für Team-Setups: Managed PostgreSQL (Supabase, Neon) ab paar Euro/Monat.

Wie validiere ich, dass die SQL-Resultate stimmen? Lass dieselbe Berechnung in Excel und SQL parallel laufen auf einer bekannten Teilmenge. Summen, Counts und Top-Werte vergleichen. Erst wenn das matcht, der vollständigen Migration vertrauen.

Fazit

Der Mental-Shift von zell-basiert zu set-basiert ist der schwerste Teil der Excel-zu-SQL-Migration. Die Syntax lernst du in ein paar Wochen. Das Urteilsvermögen — wann GROUP BY vs. Window-Function, wann LEFT JOIN vs. INNER JOIN — kommt mit Praxis.

Starte mit einem Arbeitsblatt mit klarem, abgegrenztem Zweck: eine Umsatz-Summe, eine Kundenliste, ein Monatsreport. Bring es in SQL zum Laufen und validiere gegen Excel. Dann nimm das nächste. Versuch nicht, alles auf einmal zu migrieren — lass Confidence inkrementell wachsen.

Weiterlesen

• Databricks vs Snowflake vs BigQuery (2026)
• Medallion Architecture erklärt
• Delta Live Tables vs Classic ETL

Stand: 14. Mai 2026.