Azure SQL für IT-Entscheider

Auf einen Blick

Microsoft Azure SQL ist nicht ein Produkt. Es ist eine Familie aus vier Bereitstellungsmodellen, die unter dem gleichen Markennamen laufen, sich aber in Funktionsumfang, Kosten, Betrieb und Migrationsweg unterscheiden. Wer das nicht weiß, kauft das falsche Modell. Das ist die häufigste, teuerste und gleichzeitig vermeidbarste Fehlentscheidung in Cloud-Datenbankprojekten.

Dieses Whitepaper richtet sich an IT-Entscheider, CIOs, Geschäftsführer und Architekten, die vor einer Entscheidung stehen oder eine bestehende Entscheidung überprüfen wollen. Es liefert keine vCore-Tabellen oder T-SQL-Snippets — es liefert die Antworten auf die fünf Fragen, die in jeder Entscheidersitzung kommen:

• Welches der vier Azure-SQL-Modelle passt zu welchem Anwendungsfall?
• Was kostet das wirklich — und wo verstecken sich die Posten, die im Angebot fehlen?
• Welche Sicherheits- und Compliance-Pflichten gehen vom Anbieter auf uns über?
• Was leistet die Cloud-Verfügbarkeit, was müssen wir selbst konfigurieren?
• Welche Migrationsstrategien gibt es — und welche endet im Desaster?

Sie lesen ungefähr 25 Minuten. Am Ende haben Sie eine Entscheidungs-Checkliste, mit der Sie Ihre konkrete Lage einsortieren können.

IN KÜRZE Azure SQL ist vier Produkte mit einem Namen: Azure VM (volle Kontrolle), Managed Instance (managed mit fast allen SQL-Server-Features), Azure SQL Database (single DB, modern), Serverless (Auto-Scaling). Die häufigste Fehlentscheidung: Managed Instance kaufen, wenn eigentlich Azure SQL Database genügt — oder umgekehrt. Beides kostet jährlich fünfstellig zu viel oder zu wenig. Hochverfügbarkeit ist nicht inklusive in dem Sinn, wie Vertriebskollegen es verkaufen. 99,99 % heißt 53 Minuten ungeplanter Ausfall pro Jahr.

 

Azure SQL ist nicht eine Sache

Wenn ein Microsoft-Vertriebler von „Azure SQL“ spricht, meint er meistens ein Produkt aus einem Vier-Pack — und nicht zwingend dasselbe Produkt, das Sie meinen. Die vier Modelle teilen sich den Markennamen und einen Teil der Engine, unterscheiden sich aber in fast allem, was für eine Kaufentscheidung relevant ist: Funktionsumfang, Betriebsmodell, Kostenmodell, Migrationsfreundlichkeit.

Bevor Sie auch nur über Anforderungen sprechen, müssen Sie die vier Modelle auseinanderhalten können. Sonst landen Sie in der klassischen Falle: Drei Anbieter machen drei Angebote zu drei verschiedenen Modellen, alle nennen es „Azure SQL“, und Sie vergleichen Äpfel mit Streuobstwiesen.

Abbildung 1: Die vier Bereitstellungsmodelle, sortiert von hoher Kontrolle (links) nach hoher Automatisierung (rechts).

Die vier Modelle in einer Minute

SQL Server auf Azure VM

Eine virtuelle Maschine bei Microsoft, auf der Sie SQL Server installieren. Aus Sicht des Datenbank-Administrators identisch mit On-Premises. Sie sind verantwortlich für Betriebssystem-Patches, SQL-Server-Updates, Backup-Strategie, Hochverfügbarkeit, alles. Microsoft kümmert sich um die Hardware darunter.

Empfohlen, wenn: Sie die volle Kontrolle brauchen (Linked Server, FileStream, SQL Agent mit obskuren Jobs), wenn Sie eigene Lizenzen mit Software Assurance einbringen wollen, oder wenn Sie eine Anwendung migrieren, deren Hersteller nur SQL Server „bare metal“ supportet.

Azure SQL Managed Instance

Die für die meisten Migrationen interessanteste Option. Microsoft betreibt SQL Server für Sie — Patches, Updates, Backup-Infrastruktur, Hochverfügbarkeits-Stack. Sie behalten fast den vollen SQL-Server-Funktionsumfang inklusive Cross-Database-Joins, Linked Server zu anderen Managed Instances, SQL Agent, Service Broker und Common Language Runtime. Eingebettet in ein eigenes virtuelles Netzwerk.

Empfohlen, wenn: Sie eine bestehende SQL-Server-Anwendung migrieren wollen, ohne den Anwendungs-Code anzufassen. Das ist der ehrliche „cloudifizierte SQL Server“ — fast alles, was bei Ihnen on-premises läuft, läuft hier ohne Änderung.

Azure SQL Database

Eine einzelne Datenbank als Service. Schnell aufgesetzt, modern, aber mit Einschränkungen: Cross-Database-Joins gibt es nur eingeschränkt, kein SQL Agent (Stattdessen Elastic Jobs), kein FileStream, kein Service Broker. Dafür ist die Verwaltung trivial und das Modell skaliert horizontal über Elastic Pools.

Empfohlen, wenn: Sie eine neue Anwendung bauen oder eine modernisierte Anwendung deployen, die mit den Cloud-typischen Datenbank-Constraints umgehen kann. Vor allem für SaaS-Architekturen, in denen Mandantentrennung über separate Datenbanken läuft.

Azure SQL Database — Serverless

Ein Sonderfall von Azure SQL Database: Die Compute-Leistung skaliert automatisch zwischen einem Minimum und einem Maximum, und bei Inaktivität pausiert die Datenbank vollständig. Sie zahlen nur für tatsächlich genutzte Sekunden Compute. Storage läuft normal weiter.

Empfohlen, wenn: Sie eine Datenbank haben, die stark schwankend belastet wird oder die meiste Zeit ungenutzt ist (Test-Systeme, interne Tools, sporadisch genutzte Reports). Bei konstanter Last ist Serverless teurer als ein normaler Tier mit Reserved Capacity.

Im direkten Vergleich

Eigenschaft	Azure VM	Managed Instance	SQL Database	Serverless
OS-Kontrolle	Voll	Keine	Keine	Keine
Patching	Sie	Microsoft	Microsoft	Microsoft
SQL-Funktionsumfang	100 %	~95 %	~85 %	~85 %
SQL Agent	Ja	Ja	Nein (Elastic Jobs)	Nein
Cross-DB-Joins	Voll	Voll	Eingeschränkt	Eingeschränkt
Eigene Lizenz nutzbar	Ja (BYOL)	Ja (Hybrid Use)	Ja (Hybrid Use)	Ja (Hybrid Use)
Skaliert mit Last	Manuell	Manuell	Manuell	Automatisch
Geeignet für Migration	Sehr gut	Sehr gut	Mittel	Schlecht
Geeignet für Neuentwicklung	Eher nein	Mittel	Sehr gut	Sehr gut

Tabelle 1: Direktvergleich der vier Bereitstellungsmodelle. Prozentangaben bei „SQL-Funktionsumfang“ sind grobe Richtwerte und beziehen sich auf die häufig benötigten Features.

PRAXIS Aus der Beratungspraxis: In etwa drei von fünf Migrationsprojekten kommt ein Kunde mit der festen Vorstellung „Azure SQL Database“ in den ersten Workshop — weil das Vertriebs-Material das so suggeriert hat. In etwa zwei von drei dieser Fälle ist nach 30 Minuten klar, dass Managed Instance die richtige Antwort wäre. Der Hauptgrund: Linked Server, SQL Agent oder eine Anwendung, die ohne Anpassung mit der eingeschränkteren Database-Variante nicht klarkommt.

 

Welches Modell für welchen Zweck

Die Modell-Wahl ist die wichtigste Entscheidung des gesamten Projekts. Sie legt fest, wie viel Sie zahlen, wie viel Sie selbst verwalten müssen, ob Sie überhaupt migrieren können — und ob Sie in zwei Jahren wieder umziehen müssen.

Drei Ausgangslagen kommen mit Abstand am häufigsten auf den Tisch.

Ausgangslage 1: Bestehende Anwendung migrieren

Sie haben eine SQL-Server-Datenbank im Haus, die seit Jahren läuft, eventuell vom Hersteller mitgeliefert oder selbst entwickelt. Die Anwendung soll in die Cloud, der Anwendungs-Code soll möglichst unangetastet bleiben. Vielleicht weil der Hersteller keine andere Variante supportet, vielleicht weil der Aufwand für eine Anpassung zu hoch wäre.

In diesem Fall sollten Sie zwischen Azure VM und Managed Instance wählen — je nachdem, ob Sie volle OS-Kontrolle brauchen oder nicht. Azure SQL Database scheidet hier praktisch immer aus, weil es zu viele Funktionen weglässt, die in gewachsenen Anwendungen vorausgesetzt werden.

Ausgangslage 2: Neue Anwendung bauen

Sie planen oder entwickeln eine neue Anwendung — Cloud-nativ, mit moderner Architektur, ohne historischen Ballast. Hier öffnet sich das volle Spektrum, und Azure SQL Database wird zum Standard. Bei stark schwankender Last ist Serverless die elegante Variante; bei konstanter Last ist Database mit Reserved Capacity günstiger.

Die Frage ist hier weniger „welches Modell“ als „welcher Service-Tier“ — und das ist eine Tuning-Entscheidung nach den ersten Lasttests, nicht der Architektur-Workshop.

Ausgangslage 3: Konsolidierung

Sie haben einen Wildwuchs an SQL-Server-Instanzen — Reste aus Akquisitionen, einzelne Anwendungen mit eigenen Servern, ein Mix aus Standard- und Enterprise-Lizenzen. Sie wollen das konsolidieren und gleichzeitig modernisieren.

Hier ist Managed Instance fast immer die Antwort. Sie können viele Datenbanken in eine Instanz packen, behalten den Funktionsumfang, und kommen schmerzfrei vom Lizenz-Albtraum weg.

Abbildung 2: Vereinfachter Entscheidungsbaum für die häufigsten Konstellationen.

Use Case → Empfehlung

Anwendungsfall	Empfehlung	Alternative
ERP-Migration ohne Code-Anpassung	Managed Instance	Azure VM
Neue SaaS-Anwendung, Multi-Tenant	SQL Database (Elastic Pool)	Managed Instance
Berichts-/BI-DB mit sporadischer Last	Serverless	SQL Database (Standard)
Branchen-Software vom Hersteller	Azure VM	Managed Instance (nach Freigabe)
Konsolidierung vieler kleiner DBs	Managed Instance	SQL Database Elastic Pool
Test-/Entwicklungs-Umgebung	Serverless	Azure VM (auto-shutdown)
DWH / OLAP mit vorhersehbarer Last	SQL Database (Reserved)	Synapse / Fabric (eigenes Thema)
Anwendung mit Linked Server / CLR	Managed Instance	Azure VM

Tabelle 2: Anwendungsfälle und passende Modelle. Die Empfehlungen gelten für den typischen Mittelstand; Konzern-Konstellationen können abweichen.

ACHTUNG Verwechseln Sie Empfehlung nicht mit Vorgabe. Jede Konstellation hat Detailfragen — Compliance-Region, Netzwerk-Topologie, vorhandene Skills, bestehende Lizenzen mit Software Assurance, geplante Wachstumsraten — die das Bild verschieben können. Diese Tabelle ist die Eingangstür, nicht die Antwort.

 

Was es wirklich kostet

Über Cloud-Kosten wird viel geredet und wenig verstanden. Das liegt nicht an böser Absicht — es liegt daran, dass Microsoft drei verschiedene Stellschrauben gleichzeitig dreht: Compute (Rechenleistung), Storage (Speicher) und Lizenz. Wer eine davon ignoriert, kalkuliert sich um 30 bis 50 Prozent.

Abbildung 3: Die drei Kostenkomponenten und ihre typischen Anteile am Monatspreis.

Compute — der größte Brocken

Der größte Kostenblock ist die Rechenleistung. Sie wird in vCores (virtuelle Kerne) oder DTUs (Database Transaction Units) abgerechnet — vCores sind die modernere und transparentere Variante. Pro vCore bekommen Sie eine bestimmte Menge an RAM und IOPS, je nach Service-Tier.

Drei Tier sind relevant: General Purpose ist der Standard für die meisten Workloads. Business Critical hat schnellere Storage (SSD lokal), höhere IOPS und automatisch Read Replicas — kostet etwa das Doppelte. Hyperscale ist für Datenbanken jenseits von 4 TB oder mit besonderen Skalierungs-Anforderungen.

Der größte Hebel an dieser Stelle: Reserved Capacity. Wenn Sie sich für ein oder drei Jahre auf eine bestimmte Compute-Größe festlegen, bekommen Sie zwischen 20 und 55 Prozent Rabatt auf den Listenpreis. Bei produktiven Datenbanken, die ohnehin durchlaufen, ist das kein Verzicht — es ist verschenktes Geld, wenn man es nicht macht.

Storage — kleiner Posten, große Falle

Datenbank-Storage ist überschaubar günstig. Wo es teuer wird: Backup-Storage und Geo-Replikation. Microsoft schreibt automatisch Backups, und die werden je nach Konfiguration in einer zweiten Region repliziert. Standardmäßig ist Geo-redundanter Speicher (GRS) eingestellt — für viele DSGVO-Konstellationen ist das ein Compliance-Problem (Daten verlassen die EU-Region) und gleichzeitig ein Kostentreiber. Locally Redundant Storage (LRS) ist günstiger und für viele Anwendungen ausreichend.

Long-Term Retention ist die zweite Falle. Wenn Sie Backups jahrelang aufheben müssen (typisch bei Steuer- oder Compliance-Anforderungen), explodieren die Storage-Kosten — das wird oft erst nach Monaten sichtbar.

Lizenz — der Hybrid-Use-Hebel

Bei General Purpose ist die SQL-Server-Lizenz im Compute-Preis enthalten. Wenn Sie aber bereits SQL-Server-Lizenzen mit aktiver Software Assurance besitzen, können Sie diese in die Cloud mitnehmen — der sogenannte Azure Hybrid Use Benefit. Damit zahlen Sie nur die Compute-Komponente, nicht die Lizenz, was nochmal 30 bis 40 Prozent spart.

HYBRID USE BENEFIT KONKRET Kombiniert mit Reserved Capacity ist der Hybrid Use Benefit der größte Einzel-Hebel: Bis zu 80 Prozent Ersparnis gegenüber dem Pay-as–you–go-Listenpreis sind realistisch. Voraussetzung: Aktive Software Assurance auf den Lizenzen, korrekte Lizenzzählung, Dokumentation der Verwendung. Das wird gelegentlich von Microsoft auditiert. Bei Azure VM gilt: Sie können entweder die Azure-Lizenz nutzen (im VM-Preis) oder Ihre eigene mitbringen. Letzteres ist meistens günstiger — wenn Sie die Lizenzen haben.

Beispielkalkulation

Drei Beispiele, alle mit dem Stand Mai 2026, ohne Hybrid Use Benefit, ohne Reserved Capacity (also Pay-as–you–go-Listenpreise). Region: West Europe. Werte gerundet, dienen der Größenordnung.

Szenario	Konfiguration	PAYG / Monat	Mit HUB + 3J RC
Klein: SaaS-Backend	SQL DB GP, 4 vCore, 100 GB	ca. 750 EUR	ca. 200 EUR
Mittel: ERP-Migration	Managed Instance GP, 8 vCore, 500 GB	ca. 2.800 EUR	ca. 1.000 EUR
Groß: Konsolidierte Plattform	MI Business Critical, 16 vCore, 2 TB	ca. 7.500 EUR	ca. 2.700 EUR

Tabelle 3: Größenordnung der monatlichen Kosten. PAYG = Pay-as-you-go, HUB = Hybrid Use Benefit, RC = Reserved Capacity (3 Jahre).

ACHTUNG Versteckte Kosten, die in fast jeder Kalkulation fehlen: Outbound Data Transfer (wenn Anwendung außerhalb Azure liegt) Backup über die enthaltene Größe hinaus Long-Term Retention bei Compliance-Anforderungen Geo-Replikation, falls aktiviert (oft Default) Lese-Replikate für Berichte / BI Private Endpoints und Express Route (Netzwerk-Komponenten) In der Praxis liegen die Gesamtkosten 20 bis 35 Prozent über der reinen Compute-/Storage-Rechnung. Wer das nicht einplant, hat im ersten Quartal eine unangenehme Überraschung.

 

Sicherheit und Compliance

Das größte Missverständnis: „Microsoft kümmert sich darum.“ Microsoft kümmert sich um die Plattform — also um Patches, physische Sicherheit, Verfügbarkeit der Infrastruktur. Microsoft kümmert sich nicht um Ihre Berechtigungen, Ihre Daten-Klassifizierung, Ihre DSGVO-konforme Konfiguration oder Ihren NIS2-Nachweis. Das nennt sich Shared Responsibility — und es bedeutet, dass die Verantwortung geteilt ist, nicht abgegeben.

Was Microsoft mitliefert

Aus dem Karton bekommen Sie eine erfreulich solide Basis: Verschlüsselung der Daten ruhend (Transparent Data Encryption ist standardmäßig aktiv), Verschlüsselung im Transport (TLS 1.2+ erzwungen), Patches für SQL Server und Betriebssystem, Microsoft Entra ID-Integration, eingebautes Threat Detection, Audit-Logs, Backup-Verschlüsselung.

Das ist mehr, als die meisten On-Premises-Installationen je hatten. Die Versuchung ist groß, hier den Haken zu setzen und zur nächsten Aufgabe zu gehen. Tun Sie es nicht.

Was Sie konfigurieren müssen

Die wirklich relevante Compliance-Arbeit liegt darunter. Zugriffsregeln (wer darf was), Privileged Access Management (wer darf admins werden), Datenklassifizierung (welche Tabelle enthält personenbezogene Daten), Auditing-Strategie (was wird geloggt, wie lange aufbewahrt), Backup-Strategie passend zu Ihren Recovery-Anforderungen, Region-Wahl (DSGVO-Datenstandorte), Netzwerk-Isolation (Private Endpoints, Firewall-Regeln).

Feature	Inklusive	Standardmäßig an	Konfigurations-aufwand	Compliance-relevant
Transparent Data Encryption	Ja	Ja	Niedrig	DSGVO, NIS2
Always Encrypted	Ja	Nein	Hoch	DSGVO Art. 32
Auditing (SQL Audit)	Ja	Nein	Mittel	DSGVO, NIS2, GoBD
Threat Detection	Ja (Defender)	Nein	Niedrig	NIS2
Private Endpoints	Ja	Nein	Mittel	Best Practice
Microsoft Entra Auth	Ja	Nein	Mittel	NIS2, BSI
Daten-Klassifizierung	Ja	Nein	Hoch	DSGVO Art. 30
Region-Wahl (DSGVO)	Ja	Nein	Niedrig	DSGVO

Tabelle 4: Sicherheits- und Compliance-Features. Grün = Microsoft erledigt, Orange = Sie müssen aktiv konfigurieren.

PRAXIS Aus einem Audit beim Mittelständler aus dem Maschinenbau: Der Kunde war stolz, dass Azure SQL „verschlüsselt“ war. Stimmte — TDE war an. Auf die Frage, wer die TDE-Schlüssel kontrolliert, kam Schulterzucken. Antwort: Microsoft. Für die DSGVO-Auditerin ein klares Defizit, weil Customer-Managed Keys (CMK) für personenbezogene Daten der Stand der Technik sind. Nachholzeit: drei Monate, weil Key Vault, Rotation und Wiederherstellungsprozesse erst aufgesetzt werden mussten.

DSGVO und NIS2 — die zwei zentralen Pflichten

Beide Regelwerke setzen Datenbanken explizit ins Scoping. DSGVO (seit 2018) verlangt Datenkategorisierung, Zweckbindung, Auskunfts- und Löschrechte sowie technisch-organisatorische Maßnahmen zum Schutz. NIS2 (seit 2024 in nationaler Umsetzung) verlangt für mittlere und große Unternehmen ein durchgängiges Sicherheits-Risikomanagement, Vorfall-Meldung, Lieferkettensicherheit, Geschäftsführer-Verantwortung.

Für Azure SQL bedeutet das konkret: Sie brauchen ein Verfahrensverzeichnis, in dem die Datenbank steht. Sie müssen die Datenstandorte dokumentieren (welche Region, welche Backup-Region). Sie müssen Auditing aktivieren und die Logs aufbewahren. Sie müssen Privileged Access kontrollieren und dokumentieren. Sie müssen einen Vorfall-Reaktionsplan haben.

Das ist alles machbar. Aber es ist Arbeit, die nach dem Setup weitergeht — nicht beim Setup endet.

 

Hochverfügbarkeit und Disaster Recovery

„Wir sind doch in der Cloud, da ist Verfügbarkeit kein Thema mehr.“ Schöner Satz, leider unwahr. Microsoft garantiert eine Service Level Agreement von 99,99 Prozent für Azure SQL — das klingt viel, sind aber 53 Minuten ungeplanter Ausfall pro Jahr. Für viele Anwendungen ist das verkraftbar. Für andere ein Geschäftsrisiko, das Sie aktiv adressieren müssen.

Abbildung 4: Verfügbarkeitsstufen, von Standard bis Geo-Redundanz.

Was Azure mitliefert

In allen Modellen ist eine grundlegende Hochverfügbarkeit eingebaut. Bei Azure SQL Database und Managed Instance läuft das automatisch im Hintergrund — wenn der Knoten ausfällt, übernimmt ein anderer, in der Regel innerhalb weniger Sekunden bis Minuten. Bei Azure VM müssen Sie das selbst aufsetzen, mit Always On Availability Groups oder Failover Cluster Instances.

Wenn Sie die Standard-Konfiguration nehmen, liegen alle Replikate im selben Rechenzentrum. Das schützt vor Hardware-Ausfällen, aber nicht vor dem Komplettausfall einer Verfügbarkeits-Zone.

Zonenredundanz

Azure-Regionen bestehen aus mehreren Verfügbarkeits-Zonen — physisch getrennten Rechenzentren in derselben Region, mit redundanter Stromversorgung und Netzwerk. Wenn Sie zonenredundante Bereitstellung wählen, werden Ihre Datenbank-Replikate über mindestens drei Zonen verteilt. Damit überlebt Ihre Datenbank den Ausfall eines kompletten Rechenzentrums in der Region.

Aufpreis: rund 30 bis 50 Prozent gegenüber der Single-Zone-Variante. SLA steigt auf 99,995 Prozent — das sind 26 Minuten ungeplanter Ausfall pro Jahr.

Geo-Redundanz mit Failover Groups

Für echtes Disaster Recovery brauchen Sie eine zweite Region. Failover Groups replizieren Ihre Datenbank asynchron in eine geographisch entfernte Region — typischerweise West Europe nach North Europe oder umgekehrt. Bei Ausfall der primären Region können Sie auf die sekundäre umschalten, automatisch oder manuell.

Wichtig: Asynchrone Replikation heißt, dass im Failover-Fall die letzten Sekunden bis Minuten an Transaktionen verloren gehen können. Das ist bei den meisten OLTP-Anwendungen kein Drama, bei Finanztransaktionen aber relevant.

HA/DR-Stufe	Azure VM	Managed Instance	SQL Database
Lokal redundant	Selbst aufsetzen (AG)	Inklusive (99,99 %)	Inklusive (99,99 %)
Zonenredundant	Selbst aufsetzen	Optional (BC-Tier)	Optional (alle Tier)
Geo-Redundanz (DR)	Selbst (Log Shipping etc.)	Failover Groups	Failover Groups / Geo-Replikation
Lese-Replikate	Manuell konfigurieren	BC-Tier inklusive	BC-Tier oder Hyperscale
Backup-Retention max.	Selbst definiert	35 Tage + LTR bis 10 J	35 Tage + LTR bis 10 J

Tabelle 5: HA/DR-Optionen je Modell. AG = Always On Availability Groups, BC = Business Critical, LTR = Long-Term Retention.

ACHTUNG 99,99 Prozent SLA klingt unscheinbar, ist aber ungefähr 53 Minuten ungeplanter Ausfall pro Jahr. Bei einer ERP-Datenbank, an der 200 Mitarbeiter hängen, sind das schnell sechsstellige Beträge an Produktivitätsausfall. Wenn das nicht akzeptabel ist: Failover Group plus dokumentierter, regelmäßig getesteter Failover-Prozess. Das Setup ohne Test ist nichts wert — getestete Failover sind in der Praxis die Ausnahme.

 

Migration: Wie Sie hinkommen

Die Migration aus dem Rechenzentrum in die Cloud ist selten ein Ein-Wochenende-Projekt. Sie hat drei mögliche Pfade, die sich in Aufwand, Risiko und Endergebnis deutlich unterscheiden.

Abbildung 5: Drei Migrationspfade von On-Premises in die Cloud.

Lift & Shift — der schnellste Weg

Sie nehmen Ihren On-Premises-SQL-Server, machen ein Backup, und stellen es in einer Azure-VM wieder her. Anwendungs-Code unverändert, alle Features verfügbar, niedrigster Migrations-Aufwand. Der Preis: höchste Betriebskosten, Sie betreiben weiterhin den ganzen Stack selbst, keine Cloud-Vorteile außer dem Standortwechsel.

Geeignet als Übergangslösung, wenn Termin-Druck herrscht oder das Rechenzentrum aus dem Vertrag läuft. Nicht als Endzustand. „Wir migrieren erstmal Lift & Shift und modernisieren später“ ist ein häufig gehörter Satz und meistens ein Selbstbetrug — die spätere Modernisierung kommt nie.

Re-Platform — der empfohlene Mittelweg

Sie migrieren in Managed Instance über den Azure Database Migration Service. Das geht oft als Online-Migration — Ihre Anwendung läuft weiter, während die Daten kontinuierlich repliziert werden. Beim Cutover wechseln Sie die Connection Strings, fertig. Anwendungs-Code muss in den allermeisten Fällen nicht angefasst werden, der Funktionsumfang bleibt fast vollständig erhalten.

Das ist der pragmatische Mittelweg: Sie kommen in die Managed Welt (kein Patching mehr, kein Backup-Setup mehr), behalten den vollen SQL-Server-Funktionsumfang und sparen 30 bis 50 Prozent gegenüber Lift & Shift mit Reserved Capacity. Für die meisten ERP- und Branchen-Software-Migrationen ist das die richtige Antwort.

Re-Architect — die Modernisierung

Sie nehmen die Migration zum Anlass, die Anwendung umzubauen — von Stored Procedures auf Microservices, von Synchronous-RPC auf Event-Driven, von Cross-Database-Joins auf saubere Service-Grenzen. Ziel-Plattform meistens Azure SQL Database, oft mit Elastic Pools für Multi-Tenancy.

Das ist das richtige Vorgehen für strategische Schlüsselanwendungen, in die ohnehin investiert werden muss. Es ist das falsche Vorgehen für „eine Migration nebenbei“ — der Aufwand sprengt jedes Migrationsbudget. Re-Architect ist ein Entwicklungsprojekt, kein Migrationsprojekt.

ACHTUNG Drei Klassiker, die Migrationen reihenweise versenken: Linked Server zu Drittsystemen (Oracle, SAP HANA) — funktioniert in Azure SQL Database gar nicht, in Managed Instance nur eingeschränkt. SQL Agent Jobs, die nirgends dokumentiert sind — niemand weiß mehr, was die tun, also bleiben sie. Bis zum Cutover. Hardcodierte Connection Strings in Konfigurations-Dateien, die im Code verteilt sind — beim Cutover bleibt die Hälfte der Anwendung mit der alten DB verbunden. Diese drei Punkte gehören in jede Migrationsanalyse, vor jedem Plattform-Entscheid.

 

Fünf Fallstricke, die Sie kennen sollten

Aus zwei Jahrzehnten Datenbank-Beratungspraxis kommen die folgenden fünf Fallstricke immer wieder. Sie sind nicht spektakulär — sie kosten einfach jährlich fünf- bis sechsstellige Beträge oder eine Audit-Note.

1. Über-Provisionierung

Der häufigste Fehler in den ersten sechs Monaten Cloud-Betrieb. Im Zweifel wird die Datenbank großzügig dimensioniert — „kann man später ja runterskalieren“. Dann wird es nicht mehr angefasst, weil keiner Lust hat, an einer Produktiv-DB zu schrauben. Ergebnis: Sie zahlen für 16 vCores, was 4 vCores erledigen würden. Bei Reserved Capacity über drei Jahre summiert sich das zu Beträgen, die ein ordentlicher Beratungsauftrag locker einspielt.

2. Backup-Falle

Standard-Backup-Retention ist 7 Tage, kann auf 35 Tage erhöht werden. Wenn Ihre Compliance-Anforderungen eine längere Aufbewahrung verlangen (Steuer: 10 Jahre für die Gewinnermittlungsdaten), brauchen Sie Long-Term Retention. Das ist konfigurierbar, kostet aber separat — und wird oft erst aktiviert, wenn der Wirtschaftsprüfer fragt.

3. Lizenz-Compliance bei Azure VM

Der Hybrid Use Benefit ist großartig, hat aber Spielregeln. Sie brauchen aktive Software Assurance, die richtige Lizenzart, korrekte Zählung. Microsoft auditiert das gelegentlich. Wer ohne ordentliche Dokumentation arbeitet, riskiert Nachzahlungen plus Vertragsstrafen — das ist mehr als die ursprüngliche Ersparnis.

4. Connection-Pooling übersehen

Cloud-Datenbanken haben eine Verbindungs-Latenz, die spürbar höher ist als On-Premises. Wenn Ihre Anwendung pro Request eine neue Verbindung aufbaut (sehr häufig in alten Web-Anwendungen), wird sie in der Cloud spürbar langsamer. Lösung: Connection Pooling im Client oder ein Proxy wie Azure Database Proxy. Das ist kein Bug von Azure, sondern eine Anpassung an die Cloud-Realität, die in der Migrationsplanung fast immer fehlt.

5. Region-Wahl ohne DSGVO-Blick

Die Default-Auswahl bei der Anlage ist oft nach Performance optimiert, nicht nach Datenschutzregion. Standardmäßig replizieren Backups oft in eine zweite Region (Geo-Redundant Storage). Wenn diese außerhalb der EU liegt, haben Sie ein DSGVO-Problem, ohne es zu wissen. Die Region- und Backup-Konfiguration gehört in die Erstkonfiguration, nicht ins erste Audit ein Jahr später.

PRAXIS Aus einem Sanierungsfall: Mittelständler hatte 18 Monate Azure SQL Managed Instance produktiv. Die Backups wurden nach North Europe (Irland) gespiegelt — Standard. Audit-Befund DSGVO-Datenflüsse: Kategorie 4 von 4 (kritisch). Sanierung: Region-Wechsel der MI nach Germany West Central, Re-Konfiguration der Backups auf LRS, Anpassung des Verfahrensverzeichnisses, Information aller Betroffenen. Aufwand: zwei Monate, Kosten im fünfstelligen Bereich. Hätte man bei der Erstkonfiguration für 30 Minuten Aufmerksamkeit gehabt.

 

Drei Praxisbilder

Wie sieht die Modell-Wahl in konkreten Konstellationen aus? Drei stellvertretende Beispiele aus der Beratungspraxis, anonymisiert und auf das wesentliche reduziert.

Musterwerk GmbH — Mittelständischer Maschinenbauer

Ausgangslage: 280 Mitarbeiter, ERP-System des Branchenherstellers (SQL Server 2019, Standard Edition, etwa 250 GB Datenbank-Größe), drei eigene SQL-Datenbanken für CRM, Wartungsplanung und Qualitätsmanagement. Rechenzentrum-Vertrag läuft in 14 Monaten aus, Geschäftsführung möchte „in die Cloud“. Compliance-Anforderungen DSGVO, NIS2 ab 2026. Keine eigenen DBA-Kapazitäten.

Empfehlung: Managed Instance, General Purpose, 8 vCores, mit Hybrid Use Benefit (vorhandene SQL-Server-Lizenzen mit Software Assurance). Eine Instanz für alle vier Datenbanken, Region Germany West Central, zonenredundant, Failover Group als DR-Option in Germany North. Migration über Database Migration Service, geplante Umstellung am Wochenende mit zwei Stunden Stillstand.

Begründung: Branchen-Software ist freigegeben für Managed Instance. Konsolidierung der vier Datenbanken in eine Instanz spart Kosten gegenüber separaten Azure-VMs. Hybrid Use Benefit nutzt vorhandene Investitionen. Region innerhalb Deutschland erleichtert DSGVO-Argumentation. Kein DBA-Aufwand mehr für Patching und Backup-Setup.

Sparfuchs & Partner Steuerberatungs GmbH

Ausgangslage: 45 Mitarbeiter, mandantenfähige Steuerberatungs-Software mit etwa 80 separaten SQL-Server-Datenbanken (eine pro Mandant). Datenbank-Größen zwischen 100 MB und 8 GB. Lastprofil tagsüber moderat, nachts und am Wochenende fast keine Last. DSGVO-Sensibilität hoch (Mandantendaten). Lange Aufbewahrungspflichten (Steuer-Datenbanken: 10 Jahre).

Empfehlung: Azure SQL Database in einem Elastic Pool mit Serverless-Compute. Storage in Germany West Central, Backups als LRS (lokal redundant), Long-Term Retention für 10 Jahre konfiguriert. Always Encrypted für die personenbezogenen Spalten. Microsoft Entra-Authentifizierung mit MFA für alle Admin-Zugriffe.

Begründung: Die vielen kleinen Datenbanken passen perfekt zum Elastic-Pool-Modell — Sie zahlen nicht 80 Mal die Compute-Mindestgröße, sondern teilen die Compute-Ressource. Serverless pausiert die nachts und am Wochenende ungenutzten Datenbanken automatisch, was die Kosten weiter drückt. LRS reicht aus DSGVO-Sicht und ist günstiger als GRS.

Trendforge Digital GmbH — SaaS-Anbieter

Ausgangslage: 25 Entwickler, eine moderne SaaS-Anwendung im Aufbau, geplant 200 bis 500 Kunden in den ersten zwei Jahren. Architektur: Microservices auf Azure Kubernetes Service, jedes Service hat eigene Datenbank-Anforderungen. Variable Last je Tageszeit, Wochentag und Marketing-Kampagne. CTO will explizit „nichts mehr selbst betreiben“.

Empfehlung: Azure SQL Database, je nach Service-Typ entweder Standard (Reserved Capacity) für die durchgängig belasteten Services oder Serverless für die schwankend belasteten Services. Mandantentrennung über separate Datenbanken pro Kunde, organisiert in Elastic Pools. Region: West Europe (Niederlande), GRS für Backups (DSGVO innerhalb EU akzeptabel laut Verfahrensverzeichnis).

Begründung: Reine SaaS-Architektur, keine Migration eines Altbestandes. Cloud-natives Design, kein Bedarf an SQL Server-Spezialfeatures. Serverless für die unvorhersehbar belasteten Services nutzt das Pay-per-Use-Modell optimal. Mandantentrennung pro Datenbank ist Standard-Pattern für SaaS und vereinfacht spätere Mandanten-Migration oder -Löschung.

Wer wählt was und warum

Unternehmen	Modell	Hauptgrund
Musterwerk GmbH	Managed Instance	Bestehende ERP-Migration ohne Code-Änderung, Konsolidierung mehrerer DBs, Hybrid Use Benefit
Sparfuchs & Partner	SQL DB Elastic Pool + Serverless	Viele kleine DBs mit schwankender Last, Pay-per-Use für Nacht/Wochenende, einfaches Mandanten-Modell
Trendforge Digital	SQL Database (mixed Tiers)	SaaS-Architektur ohne Altlast, Cloud-native, Mandantentrennung pro DB

Tabelle 6: Drei Praxisbilder im Vergleich. Jeder Fall hat eine andere Antwort — und in jedem Fall ist die Antwort begründbar.

 

Entscheidungs-Checkliste

Wenn Sie eine konkrete Entscheidung vorbereiten, arbeiten Sie diese Punkte ab. Sie ersetzen keine Beratung, aber sie bringen Sie an den Punkt, an dem ein Beratungsgespräch produktiv wird.

Anwendungs-Profil

• Was ist die Quelle: bestehende Anwendung migrieren oder Neuentwicklung?
• Welche SQL-Server-Features nutzt die Anwendung? Linked Server, SQL Agent, CLR, FileStream, Service Broker?
• Wie viele Datenbanken sind betroffen, wie groß ist die größte?
• Wie ist das Lastprofil: konstant, tageszeitabhängig, schubweise?

Compliance & Region

• Welche Datenschutz-Region ist verpflichtend (Deutschland, EU, weltweit)?
• Welche Aufbewahrungspflichten gelten (DSGVO, GoBD, branchenspezifisch)?
• Greift NIS2? Wer ist zur Vorfall-Meldung verantwortlich?
• Wer kontrolliert die Verschlüsselungs-Schlüssel — Microsoft (Default) oder Sie (Customer-Managed Keys)?

Kosten & Lizenz

• Bestehen SQL-Server-Lizenzen mit aktiver Software Assurance? Hybrid Use Benefit nutzbar?
• Ist die Last vorhersehbar genug für Reserved Capacity (1 oder 3 Jahre)?
• Wer trägt die Cloud-Kosten — IT-Budget oder Fachbereich?

Verfügbarkeit & Recovery

• Was ist der akzeptable ungeplante Ausfall pro Jahr (RTO)?
• Welcher Datenverlust ist im Worst Case akzeptabel (RPO)?
• Brauchen Sie Geo-Redundanz, oder reicht Zonenredundanz innerhalb einer Region?

Migration & Übergang

• Welcher Migrationspfad: Lift & Shift, Re-Platform oder Re-Architect?
• Welche Test-Strategie: Pilot mit Teilbestand oder Big-Bang?
• Wer übernimmt den Betrieb nach der Migration: eigene Mannschaft, Dienstleister, Cloud-Provider?

TIPP Wenn Sie alle Punkte beantworten können, sind Sie bereit für eine Architektur-Entscheidung. Wenn drei oder mehr Punkte unklar sind, sollten Sie eine strukturierte Standortbestimmung machen, bevor Sie sich auf ein Modell festlegen.

 

Wenn Sie weitergehen wollen

Die Modell-Wahl bei Azure SQL ist eine Entscheidung mit erheblichen finanziellen und betrieblichen Konsequenzen — gleichzeitig eine, die in vielen Unternehmen nebenbei zwischen Tür und Angel getroffen wird. Das Resultat sind Kosten, die zu hoch sind, Compliance-Lücken, die zu spät auffallen, und Migrationen, die ihre Versprechen nicht halten.

Wenn Sie Klarheit brauchen, bevor Sie eine Entscheidung treffen — oder eine zweite Meinung zu einer bereits getroffenen Entscheidung — ist eine strukturierte Standortbestimmung der richtige Einstieg. Eine bis zwei Wochen Aufwand, ein Befundbericht im neunteiligen Format, eine priorisierte Aktionsliste.

Drei typische Einstiegspunkte:

• Pre-Flight-Check vor einer geplanten Migration: Modell-Wahl, Lizenzbetrachtung, Kostenkalkulation, Migrationsplan.
• Standortbestimmung einer bestehenden Azure-SQL-Umgebung: Konfigurations-Audit, Compliance-Bewertung, Optimierungspotenziale.
• Strategische Beratung beim Aufbau einer Cloud-Datenbank-Strategie: Welche Anwendungen wann, in welcher Reihenfolge, mit welchem Modell.

Alle drei Formate biete ich remote an, mit transparenter Abrechnung und ohne Vor-Ort-Zwang. Zur Werkzeug-Familie gehören außerdem Diagnose-Tools für Performance-Analyse und Lastsimulation.

ERSTGESPRÄCH VEREINBAREN Eine kurze Mail mit zwei, drei Sätzen zur Ausgangslage genügt — daraus ergibt sich meistens schon der richtige Termin und ein erster Eindruck, ob die Chemie stimmt. Mail: info@boddenberg.de Web: boddenberg.de

Über den Autor

Ulrich B. Boddenberg ist seit über 25 Jahren als IT-Consultant und Fachbuchautor in der Microsoft-Welt unterwegs. Schwerpunkte sind SQL Server, SharePoint, Microsoft 365, Identity-Themen rund um Entra ID und ADFS sowie Compliance-Architekturen. Er ist Autor mehrerer Fachbücher, darunter die Reihe „SQL Server in der Praxis“ (Band 1: Performance & Troubleshooting) und „Microsoft Copilot für Entscheider“. Sitz: Dortmund.

© 2026 Ulrich B. Boddenberg.