Sie möchten eine SQL-Server-Anwendung nach Azure verlagern. Dafür kommen drei unterschiedliche Zielplattformen infrage: SQL Server auf einer Azure-VM, Azure SQL Managed Instance und Azure SQL Database.
Die passende Wahl hängt davon ab, welche Funktionen Ihre Anwendung benötigt, welche Abhängigkeiten vorhanden sind und welche Betriebsaufgaben Sie selbst übernehmen möchten. Dazu kommen Last, Verfügbarkeit und Wirtschaftlichkeit.
Beginnen Sie mit zwei Fragen: Was setzt unsere Anwendung heute voraus? Und was soll sich durch den Wechsel verbessern? Der folgende Vergleich hilft Ihnen, die Antworten zu ordnen.
Die drei Möglichkeiten im Überblick
VMSQL Server auf einer Azure-VM: Instanz und Betriebssystem selbst gestalten
Auf einer Azure Virtual Machine betreiben Sie einen SQL Server mit Zugriff auf das Betriebssystem und die Instanzkonfiguration. Sie wählen eine geeignete SQL-Server-Version und Edition und gestalten unter anderem Datenträger, Installation und Wartung.
Das ist besonders dann eine prüfenswerte Option, wenn Ihre Anwendung eng mit dem bisherigen Server verbunden ist: durch zusätzliche Software, Betriebssystemzugriffe oder Funktionen, die ein verwalteter Dienst nicht in derselben Form bereitstellt.
Mit diesen Gestaltungsmöglichkeiten sind Betriebsaufgaben verbunden. Patchen, Sicherungen, Überwachung und SQL-Hochverfügbarkeit brauchen ein abgestimmtes Verfahren. Azure bietet dafür Funktionen und Automatisierung; die Gesamtverantwortung für Ihre SQL-Server-Konfiguration und deren Prüfung bleibt Teil Ihres Betriebsmodells.
Die entscheidende Frage: Welche Kontrolle benötigen Sie, und wie wird die Umgebung dauerhaft betrieben?
MIAzure SQL Managed Instance: viele Instanzfunktionen als verwalteter Dienst
Managed Instance bietet einen verwalteten SQL-Dienst mit zahlreichen instanzweiten Funktionen. Dazu gehören SQL Server Agent und Zugriffe zwischen Datenbanken derselben Instanz. Microsoft betreibt die darunterliegende Plattform und übernimmt wesentliche Aufgaben wie Engine-Patching und automatisierte Sicherungen.
Damit ist Managed Instance ein wichtiger Kandidat für bestehende Anwendungen mit mehreren zusammenhängenden Datenbanken oder weiteren Instanzabhängigkeiten. Die verwendeten Funktionen müssen trotzdem einzeln geprüft werden. Bei Jobs, Dateizugriffen, externen Verbindungen und Administrationsabläufen gibt es Unterschiede zum selbst betriebenen SQL Server.
Sie erhalten keinen administrativen Zugriff auf das darunterliegende Betriebssystem. Vorhandene Skripte und Betriebsannahmen sollten deshalb Teil der Migrationsprüfung sein.
Die entscheidende Frage: Welche Ihrer Instanzabhängigkeiten unterstützt Managed Instance, und welche müssen angepasst werden?
DBAzure SQL Database: die Datenbank als verwalteter Dienst
Bei Azure SQL Database steht die einzelne Datenbank beziehungsweise eine Gruppe von Datenbanken in einem Elastic Pool im Mittelpunkt. Microsoft betreibt die Plattform und stellt Funktionen für Sicherung, Verfügbarkeit und Überwachung bereit.
Die Anwendung verbindet sich mit einem Datenbankdienst. Der in Azure angelegte logische Server dient der Verwaltung und dem Zugriff; er ist keine frei administrierbare SQL-Server-Instanz wie auf einer VM.
Innerhalb von SQL Database gibt es mehrere Dienstebenen. Hyperscale trennt Rechenleistung, Datenhaltung und Transaktionslog in eigene Bausteine und ist für Datenbanken bis 128 TB ausgelegt; Sicherungen entstehen dort als Snapshots. Hyperscale ist eine Dienstebene von SQL Database. Für Managed Instance gibt es sie nicht.
Diese Plattform ist ein Kandidat für Anwendungen, deren benötigte Funktionen zum Datenbankmodell passen. Gewohnte Instanzannahmen sind besonders sorgfältig zu prüfen: SQL Server Agent ist nicht vorhanden, und normale Zugriffe per Drei-Teil-Namen zwischen Datenbanken lassen sich nicht unverändert übernehmen. Für bestimmte Aufgaben gibt es andere Verfahren, etwa Elastic Jobs oder Elastic Query. Deren Voraussetzungen und Grenzen gehören in die Architekturprüfung.
Die entscheidende Frage: Kann Ihre Anwendung mit den angebotenen Datenbankfunktionen arbeiten, und welche Anpassungen sind dafür sinnvoll?
- Ihr Team: eigene Gestaltung
- Microsoft-Plattformbetrieb
- Dienstgrenze: ab hier betreibt Microsoft
Microsoft erläutert das grundlegende Betriebsmodell im Überblick über die Azure-SQL-Familie.
Funktionen und Betriebsaufgaben vergleichen
Die Tabelle zeigt Orientierungspunkte für die Auswahl. Konkrete Unterstützung hängt zusätzlich von Version, Edition, Dienstmodell und Konfiguration ab.
| Frage | SQL Server auf Azure-VM | Azure SQL Managed Instance | Azure SQL Database |
|---|---|---|---|
| Was verwalten Sie? | Betriebssystem, SQL-Instanz und Datenbanken im gewählten Betriebsmodell | Instanz und Datenbanken innerhalb der Dienstgrenzen | Datenbanken und ihre Konfiguration innerhalb der Dienstgrenzen |
| Administrativer Betriebssystemzugriff? | Ja | Nein | Nein |
| SQL Server Agent? | Bei geeigneter SQL-Server-Edition verfügbar | Verfügbar, mit dokumentierten Unterschieden | Nicht verfügbar; andere Automatisierung, etwa Elastic Jobs, prüfen |
| Zugriffe zwischen Datenbanken? | Native Instanzfunktionen, abhängig von Konfiguration und Berechtigungen | Native Zugriffe innerhalb derselben Instanz | Gewohnte Drei-Teil-Namen-Zugriffe nicht vorhanden; gesonderte Verfahren prüfen |
| Zusätzliche Software oder lokale Dateien? | Im Rahmen der VM-/SQL-Konfiguration möglich | Keine frei gestaltbare lokale Betriebssystemumgebung | Keine frei gestaltbare lokale Betriebssystemumgebung |
| Wer patcht Betriebssystem und Engine? | Ihr Betriebsteam beziehungsweise die vereinbarte Automatisierung/Dienstleistung | Microsoft für die Plattform; Anwendungen auf Wartung vorbereiten | Microsoft für die Plattform; Anwendungen auf Wartung vorbereiten |
| Wie entstehen Sicherungen? | Gewähltes SQL-/Azure-Sicherungsverfahren konfigurieren und betreiben | Plattform führt automatisierte Sicherungen aus | Plattform führt automatisierte Sicherungen aus |
| Was bleibt bei Wiederherstellung zu klären? | Vollständiges Verfahren, Dateien, Zugriff, Ziele und Tests | Aufbewahrung, geeigneter Wiederherstellungsweg, Zugriff und Tests | Aufbewahrung, geeigneter Wiederherstellungsweg, Zugriff und Tests |
| Worauf achten bei Verfügbarkeit? | VM- und SQL-Architektur, Ausfallfälle und Anwendungsreaktion | Dienstkonfiguration, weitere Ausfallvorsorge und Anwendungsreaktion | Dienstkonfiguration, weitere Ausfallvorsorge und Anwendungsreaktion |
| Was prägt die Dimensionierung? | VM, Speicher, Datenträger, SQL-Konfiguration und Workload | Instanzausstattung, Dienstebene und gemeinsame Datenbanklast | Datenbank-/Poolausstattung, Dienstebene und Workload |
SQL Server auf Azure-VM: Patchen und Sicherungen laufen über Ihr Betriebsmodell. Azure bietet dafür Funktionen und Automatisierung; Ihr Team oder die vereinbarte Dienstleistung führt aus und prüft.
SQL Server auf Azure-VM: Patchen und Sicherungen laufen über Ihr Betriebsmodell. Azure bietet dafür Funktionen und Automatisierung; Ihr Team oder die vereinbarte Dienstleistung führt aus und prüft.
Azure SQL Managed Instance: Die Plattform patcht und führt automatisierte Sicherungen aus. Aufbewahrung, Wiederherstellungsweg, Zugriff und Tests legen Sie fest.
Azure SQL Database: Für diese Aufgaben gilt dasselbe wie bei Managed Instance: Die Plattform patcht und sichert; Festlegen und Erproben bleiben bei Ihnen. Unterschiede liegen bei den Funktionen, etwa beim Agent.
| Aufgabe | Microsoft-Plattform | Ihr Team | Dienstleister, z. B. PSGim vereinbarten Umfang |
|---|---|---|---|
| Betriebssystem und Engine patchen | führt aus Engine-Patching der PlattformBei VM: stellt bereit Funktionen und Automatisierung | legt fest Anwendungen auf Wartung vorbereitenBei VM: führt aus selbst oder per vereinbarter Automatisierung/Dienstleistung | im Auftrag festzulegen |
| Aufbewahrung festlegen | stellt bereit Funktionen für SicherungBei VM: – je nach gewähltem Verfahren | legt fest passende AufbewahrungBei VM: legt fest im gewählten Sicherungsverfahren | im Auftrag festzulegen |
| Sicherungen erzeugen | führt aus automatisierte SicherungenBei VM: stellt bereit Azure-Sicherungsverfahren zur Wahl | – keine eigene Ausführung der automatisierten SicherungenBei VM: führt aus gewähltes Verfahren konfigurieren und betreiben | im Auftrag festzulegen |
| Restore erproben | stellt bereit WiederherstellungswegeBei VM: – je nach gewähltem Verfahren | prüft Weg wählen, Zugriff klären, testenBei VM: prüft vollständiges Verfahren mit Dateien, Zugriff, Zielen und Tests | im Auftrag festzulegen |
| Abfragen gestalten | stellt bereit Diagnose- und AutomatisierungsfunktionenBei VM: – nicht Aufgabe der Plattform | führt aus Datenmodell, Abfragen, Transaktionen, Datenbankaufrufe | im Auftrag festzulegen |
| Anwendungsfehler behandeln | – nicht Aufgabe der Plattform | legt fest Reaktion auf Verbindungsunterbrechungen, prüft im Test | im Auftrag festzulegen |
- führt auserledigt die Arbeit
- legt festentscheidet und konfiguriert
- prüfterprobt und weist nach
- stellt bereitbietet Funktionen an
Die offiziellen Detailgrenzen stehen in Microsofts Funktionsvergleich für SQL Database und Managed Instance. Prüfen Sie auch die dort verlinkten Unterschiede, wenn eine Funktion für Ihre Anwendung entscheidend ist. Eine einzelne grüne Tabellenzelle ersetzt keinen Anwendungstest.
- VMEdition, Rechte, Job prüfenAgent bei geeigneter SQL-Server-Edition verfügbarprüfen
- MISchritte und Unterschiede prüfenAgent verfügbar, mit dokumentierten Unterschiedenprüfen
- DBAndere Automatisierung planenKein Agent; etwa Elastic Jobs mit eigenen Voraussetzungen prüfenanpassen
- VMKonfiguration und Berechtigungen prüfenNative Instanzfunktionenprüfen
- MILiegen beide Datenbanken in derselben Instanz?Dort native Zugriffe; externe Zugriffe gesondert untersuchenprüfen
- DBGesondertes Verfahren prüfenKeine gewohnten Drei-Teil-Namen; etwa Elastic Query (laut Microsoft-Funktionsvergleich derzeit als Preview geführt) mit eigenen Grenzen, Transaktionsanforderungen klärenanpassen
Fünf Fragen für Ihre Zielauswahl
1Welche Voraussetzungen sind tatsächlich verbindlich?
Erstellen Sie eine kurze Liste der verwendeten Funktionen und Abhängigkeiten. Dazu gehören Datenbanken, Jobs, Anmeldungen, Verbindungen zu weiteren Systemen und Zugriffe auf Dateien. Fragen Sie bei Standardsoftware nach der Freigabe des Herstellers für das konkrete Ziel.
Unterscheiden Sie dabei drei Fälle: Die Anwendung benötigt eine Funktion zwingend; ein vorhandener Betriebsablauf nutzt sie; oder die Funktion ist installiert, wird aber möglicherweise gar nicht gebraucht. Diese Unterscheidung kann den Spielraum für die Zielwahl erheblich verändern.
2Wo laufen Anwendung und Datenbank nach dem Umzug?
Eine Anwendung im eigenen Rechenzentrum kann eine Datenbank in Azure erreichen. Wie gut das funktioniert, hängt auch von den Datenbankaufrufen ab. Viele kleine, nacheinander ausgeführte Zugriffe reagieren empfindlich auf zusätzliche Round-trip-Zeit.
Zeichnen Sie deshalb den vollständigen Weg eines wichtigen Vorgangs auf: Benutzer, Anwendung, Datenbank und beteiligte Schnittstellen. Prüfen Sie außerdem Netzwerkzugriff, Namensauflösung und Authentifizierung. Ein erfolgreicher Verbindungstest ist erst der Anfang.
3Welche Last muss das Ziel bewältigen?
Betrachten Sie typische Tageslast, Spitzen und periodische Verarbeitung. Wichtig sind sowohl die insgesamt benötigten Ressourcen als auch der Aufwand einzelner Geschäftsvorgänge und deren Gleichzeitigkeit.
Eine niedrige durchschnittliche CPU-Auslastung schließt einen kritischen Engpass beim Import oder Tagesabschluss nicht aus. Dass zwei Umgebungen dieselbe Zahl an vCores anbieten, garantiert ebenfalls keine identischen Antwortzeiten. Für die Auswahl sind Messwerte und ein geeigneter Test auf dem Ziel aussagekräftiger.
4Welche Verantwortung soll Ihr Team tragen?
Ein verwalteter Dienst nimmt Ihnen Plattformarbeit ab. Ihre Daten, Zugriffsregeln, Abfragen und Anwendungsabläufe benötigen weiterhin Betreuung. Auch passende Wiederherstellungsziele und die Reaktion auf Verbindungsunterbrechungen müssen festgelegt und getestet werden.
Halten Sie fest, welche Aufgaben Microsoft übernimmt, welche Ihr Team trägt und wo ein Dienstleister unterstützt. So lässt sich auch der betriebliche Nutzen einer Plattform bewerten.
5Welche Gesamtkosten gehören in den Vergleich?
Vergleichen Sie Zielvarianten, die dieselben fachlichen und betrieblichen Anforderungen erfüllen. Berücksichtigen Sie benötigte Leistung, Speicher, Verfügbarkeit, Datentransfer und Betriebsaufwand. Vorhandene Lizenzrechte und Vertragsannahmen müssen passend zum konkreten Angebot geprüft werden.
Ein Preisvergleich bei unterschiedlich geplanter Ausfallvorsorge beantwortet die Wirtschaftlichkeitsfrage nur unvollständig. Dokumentieren Sie deshalb, welche Leistungen und Annahmen in jeder Variante enthalten sind.
Alle fünf Fragen: zwölf offene Prüfungen für Ihre engere Auswahl.
Alle fünf Fragen: zwölf offene Prüfungen für Ihre engere Auswahl.
Frage 1: Welche Voraussetzungen sind tatsächlich verbindlich?
Frage 2: Wo laufen Anwendung und Datenbank nach dem Umzug?
Frage 3: Welche Last muss das Ziel bewältigen?
Frage 4: Welche Verantwortung soll Ihr Team tragen?
Frage 5: Welche Gesamtkosten gehören in den Vergleich?
NotizblattDiese Punkte bestimmen Ihre Auswahl
- 1Verwendete Funktionen und Abhängigkeiten auflisten: Datenbanken, Jobs, Anmeldungen, Verbindungen, Dateizugriffe
- 1Je Funktion unterscheiden: zwingend, von einem Betriebsablauf genutzt oder nur installiert
- 1Herstellerfreigabe für das konkrete Ziel erfragen
- 2Weg eines wichtigen Vorgangs aufzeichnen: Benutzer, Anwendung, Datenbank, Schnittstellen
- 2Netzwerkzugriff, Namensauflösung und Authentifizierung prüfen
- 3Tageslast, Spitzen und periodische Verarbeitung betrachten, nicht nur den Durchschnitt
- 3Messwerte erheben und auf dem Ziel testen
- 4Aufgaben zuordnen: Microsoft, Ihr Team, Dienstleister
- 4Wiederherstellungsziele und Reaktion auf Verbindungsunterbrechungen festlegen und testen
- 5Nur Varianten mit denselben fachlichen und betrieblichen Anforderungen vergleichen
- 5Lizenzrechte und Vertragsannahmen zum konkreten Angebot prüfen
- 5Leistungen und Annahmen je Variante dokumentieren
Ergebnis: Prüfkandidaten und offene Fragen. Kein automatischer Sieger.
Drei typische Ausgangslagen
Die folgenden Situationen sind illustrative Beispiele, keine PSG-Kundenreferenzen und keine fertigen Architekturempfehlungen.
-
Gewachsene Anwendung mit lokaler Zusatzsoftware
Prüfkandidat Azure-VM
noch zu klären
- Datenträger, Wartung, Verfügbarkeit
- für einen verwalteten Dienst: Zusatzsoftware, Dateien, Herstellerfreigabe
-
Mehrere Datenbanken mit gemeinsamen Jobs
Prüfkandidat Managed Instance
noch zu klären
- konkrete Jobs, externe Zugriffe, Administrationsverfahren
- gemeinsame Last und Instanzausstattung
-
Anwendung mit klar begrenztem Datenbankbedarf
Engere Auswahl SQL Database
noch zu klären
- geeignetes Leistungsmodell
- Elastic Pool oder Serverless nur, wenn das Lastprofil passt
Gewachsene Anwendung mit lokaler Zusatzsoftware
Eine Anwendung nutzt SQL Server, zusätzliche Software auf demselben Rechner und einen Prozess, der Dateien auf lokalen Pfaden verarbeitet. Der Hersteller unterstützt zunächst nur eine vollständige SQL-Server-Installation.
Hier ist die Azure-VM ein naheliegender Prüfkandidat. Für einen verwalteten Dienst müssten Zusatzsoftware, Dateien und Herstellerfreigabe vorher geklärt werden. Zum VM-Vergleich gehören weiterhin geeignete Datenträger, Wartung und Verfügbarkeit.
Mehrere Datenbanken mit gemeinsamen Jobs
Ein System besteht aus mehreren Datenbanken. Prozeduren greifen auf andere Datenbanken der Instanz zu, SQL-Agent-Jobs koordinieren die Verarbeitung. Lokale Zusatzsoftware wird nicht benötigt.
Managed Instance ist dafür ein wichtiger Prüfkandidat. Zu untersuchen bleiben die konkret verwendeten Jobs, externen Zugriffe und Administrationsverfahren. Außerdem muss die gemeinsame Last der Datenbanken zur gewählten Instanzausstattung passen.
Anwendung mit klar begrenztem Datenbankbedarf
Eine Anwendung verwendet eine einzelne Datenbank und kann wiederkehrende Aufgaben außerhalb von SQL Server Agent ausführen. Verbindungen, Berechtigungen und Fehlerbehandlung lassen sich passend zum Dienst gestalten.
Hier kommt Azure SQL Database in die engere Auswahl. Danach folgt die Wahl des geeigneten Leistungsmodells. Elastic Pools oder Serverless können für bestimmte Lastprofile interessant sein; ihr Nutzen muss zu Auslastung, Antwortzeitzielen und Betriebsanforderungen passen.
Hyperscale, Serverless und Elastic Pools gezielt prüfen
Hyperscale ist eine Dienstebene mit eigener Architektur, keine eigene Plattform. Für die Auswahl zählen dieselben Fragen wie bei jeder Dienstebene: Funktionen, Last, Verfügbarkeit und Kosten. Zwei Punkte gehören zusätzlich in die Prüfung. Wer aus einer anderen Dienstebene nach Hyperscale wechselt, kann laut Microsoft nur innerhalb von 45 Tagen und unter Bedingungen zu General Purpose zurückkehren. Und mehrere Neuerungen, die Microsoft im September 2026 vorgestellt hat, etwa die automatische Pause für Hyperscale Serverless und größere Hyperscale-Pools, sind zum Stand 27.10.2026 Preview.
Für bestehende, fest bereitgestellte Hyperscale-Datenbanken nennt Microsoft Dezember 2026 als Ende des Azure Hybrid Benefit. Das gehört in eine laufende Kostenbetrachtung.
Serverless kann Rechenleistung innerhalb konfigurierter Grenzen an die Last anpassen. Bei unterstützter und aktivierter automatischer Pause kann eine Datenbank nach einer Ruhephase erst wieder anlaufen müssen. Das beeinflusst die ersten Verbindungen und Vorgänge. Für eine Anwendung mit strikten Antwortzeitzielen ist dieses Verhalten Teil der Prüfung.
Elastic Pools geben mehreren Datenbanken einen gemeinsamen Ressourcenrahmen. Dafür müssen die Lastprofile zusammenpassen. Zusätzlich ist zu berücksichtigen, welche Grenzen für die einzelne Datenbank und welche für den Pool gelten.
Beide Modelle sind konkrete Werkzeuge für passende Lastbilder. Prüfen Sie Verhalten und Kosten an Ihrer Nutzung. Microsoft beschreibt Voraussetzungen und Grenzen im Serverless-Überblick und bei der Ressourcenverwaltung in Elastic Pools. Zu Hyperscale: Überblick über die Dienstebene, Rückkehr aus Hyperscale und automatische Pause.
Hybridbetrieb und Azure Arc einordnen
Die Plattformentscheidung kann auch ergeben, die Datenbank vorerst am bisherigen Standort zu belassen oder nur einen Teil der Umgebung zu verlagern. Dann werden Schnittstellen, Verwaltungsaufgaben und Netzwerkwege besonders wichtig.
SQL Server enabled by Azure Arc bindet vorhandene SQL Server außerhalb von Azure an Azure-Verwaltungsdienste an. Dazu können Inventarisierung und Assessments gehören. Der Server wechselt durch diese Anbindung seinen Standort nicht. Arc steht deshalb im Abschnitt zur Verwaltung und zu hybriden Umgebungen; die Hostingentscheidung für die drei hier verglichenen Azure-Ziele bleibt eine eigene Frage.
Aus dem Arc-Portal heraus bietet Microsoft inzwischen auch einen Migrationsablauf nach Azure SQL Database an, zum Stand 27.10.2026 als Preview und nur offline. Er unterstützt Assessment und Datenübertragung; die Prüfung von Abhängigkeiten, Umschaltung und Abnahme ersetzt er nicht.
Quelle: Microsofts Überblick zu SQL Server enabled by Azure Arc und Migration aus Azure Arc. Andere Arc-Produkte werden in diesem Vergleich nicht bewertet. Welche Daten bei der Anbindung an Azure übertragen werden, ist vor einer Einführung zu klären.
Vor dem produktiven Wechsel: sechs Dinge vorbereiten
- 01
Bestand und Abhängigkeiten festhalten. Datenbanken, Anwendungen, Jobs, Zugriffe und beteiligte Teams dokumentieren. Herstellerfreigaben für das Ziel einholen.
- 02
Ausgangslast und Ziele bestimmen. Repräsentative Zeitfenster und relevante Geschäftsvorgänge auswählen. Antwortzeiten, Durchsatz, Fehler und Wiederherstellungsziele festlegen.
- 03
Kompatibilität und Zielkonfiguration prüfen. Ein Assessment liefert Hinweise auf Anpassungsbedarf und geeignete Ausstattung. Diese Hinweise mit dem tatsächlichen Funktionsbedarf abgleichen.
- 04
Eine Testmigration durchführen. Daten und benötigte Objekte übertragen und fachliche Abläufe prüfen. Auch Jobs, Identitäten, Schnittstellen und Fehlererholung testen.
- 05
Umschaltung und Rückweg planen. Zuständigkeiten, Schreibstopp, Synchronisierung, Freigabe und Abbruchkriterien festlegen. Einen Rückweg nach neuen Schreibzugriffen am Ziel gesondert behandeln.
- 06
Abnahme und Betrieb vorbereiten. Festlegen, welche Messwerte und fachlichen Prüfungen die Freigabe tragen. Dokumentation, Überwachung und Wiederherstellung in den Betrieb übergeben.
Microsoft dokumentiert in SSMS einen Migrationsworkflow mit Assessment und Zielvergleich. Solche Werkzeuge unterstützen die Planung. Die Verantwortung für eine passende Anwendungslösung und deren Abnahme bleibt beim Projektteam.
Häufige Fragen
Ist Managed Instance mit jedem SQL Server austauschbar?
Managed Instance unterstützt viele vertraute Instanzfunktionen. Unterschiede bei einzelnen Features und Betriebsverfahren müssen trotzdem geprüft werden. Ein Test mit Ihrer Anwendung ist besonders wichtig, wenn externe Zugriffe, spezielle Jobs oder zusätzliche Komponenten beteiligt sind.
Können wir Jobs aus SQL Server Agent nach SQL Database übernehmen?
SQL Database hat keinen SQL Server Agent. Zuerst muss geklärt werden, was ein Job tut und welche Berechtigungen und Abhängigkeiten er benötigt. Anschließend kann eine passende Automatisierung gewählt werden. Eine unveränderte Übernahme ist kein allgemeiner Migrationsweg.
Sind bei SQL Database alle Zugriffe auf andere Datenbanken ausgeschlossen?
Die gewohnten nativen Zugriffe über Drei-Teil-Namen stehen nicht zur Verfügung. Für bestimmte Aufgaben gibt es gesonderte Verfahren, etwa Elastic Query, mit eigenen Grenzen. Prüfen Sie den konkreten Zugriff einschließlich Transaktionsanforderungen, statt eine bestehende Anwendung als automatisch kompatibel einzustufen.
Übernimmt Microsoft bei PaaS auch das Performancetuning der Anwendung?
Der Dienst übernimmt Plattformaufgaben und bietet Diagnose- und Automatisierungsfunktionen. Datenmodell, Abfragen, Transaktionen und Datenbankaufrufe Ihrer Anwendung bleiben wesentliche Einflussgrößen. Dort kann weiterhin gezielte Analyse und Optimierung nötig sein.
Was tun, wenn wir bereits migriert haben und die Anwendung langsamer ist?
Grenzen Sie zunächst einen betroffenen Vorgang und Zeitraum ein. Vergleichen Sie anschließend Anwendungsantwortzeit, Datenbankarbeit und Plattformauslastung. Unser Performance-Ratgeber für den Umstieg nach Azure führt durch die nächsten Schritte.
Quellen und Stand
Produktgrenzen ändern sich mit der Zeit. Diese Seite gibt den Stand vom 27.10.2026 wieder; prüfen Sie für eine konkrete Entscheidung die dann aktuellen Microsoft-Angaben. Eigene Messungen oder Migrationen in Azure liegen dieser Seite nicht zugrunde. Die Abbildungen sind Strukturmodelle oder ausdrücklich gekennzeichnete Lehrbeispiele. Sie enthalten keine Messwerte, Preise oder Bewertungen. Elastic Query führt Microsoft im Funktionsvergleich derzeit als Preview.
Quellen von Microsoft (Dokumentationsstand geprüft am 27.10.2026): Überblick über die Azure-SQL-Familie · Funktionsvergleich SQL Database und Managed Instance · Serverless-Überblick · Ressourcenverwaltung in Elastic Pools · Überblick über die Hyperscale-Dienstebene · Rückkehr aus Hyperscale · Automatische Pause · SQL Server enabled by Azure Arc · Migration aus Azure Arc · Migrationsworkflow in SSMS
Aus Anforderungen eine begründete Wahl machen
Halten Sie für Ihre engere Auswahl fest: benötigte Funktionen, notwendige Anpassungen, Betriebsaufgaben, Kostenannahmen und die noch fehlenden Nachweise. So wird aus einer Produktpräferenz eine prüfbare Entscheidung.
PSG unterstützt Sie dabei, diese Grundlage zu erarbeiten und den Umstieg mit Ihrem Team vorzubereiten. Mehr zur Azure-SQL-Beratung und Migration.