Datenbank-Migration auf AWS, Azure, OCI – wie du erkennst, wer wirklich beteiligt war

Cloud Migration ist mehr als ein Umzug: Wer eine Datenbank wirklich in AWS, Azure oder OCI migriert hat, musste Architektur, Sicherheit und Ausfallsicherheit mitdenken. In diesem Artikel lernst du, wie du echte Projekterfahrung im Interview erkennst – und Scheinverantwortung entlarvst.

„Ich war verantwortlich für die Cloud-Migration unserer Datenbank“ – klingt gut, oder? Aber was bedeutet das konkret?
War es eine produktionsrelevante Migration mit Architekturverantwortung, Sicherheitskonzept, Replikationslogik und Downtime-Strategie – oder doch nur das Ausführen eines Scripts?

Gerade bei Datenbankmigrationen auf AWS, Azure oder Oracle Cloud zeigt sich sehr schnell, wer nur eine VM befüllt hat – und wer die Applikationslogik, Performance-Implikationen und Business Continuity durchdrungen hat.
Denn Migration heißt nicht: „Läuft jetzt woanders“. Migration heißt: neue Umgebung, neue Abhängigkeiten, neue Risiken.

In diesem Artikel lernst du, wie du im Interview innerhalb von Minuten erkennst, ob dein:e Kandidat:in diese Komplexität wirklich beherrscht – oder nur das Etikett „Cloud“ auf dem Lebenslauf klebt.

1. Cloud Migration: Lift & Shift vs. Replatforming im Vergleich

Zwei Schlagwörter, die oft synonym verwendet werden – aber fundamental verschieden sind.

Beim Lift & Shift wird die bestehende Datenbank nahezu 1:1 in die Cloud verschoben. Technisch häufig durch Tools wie:

• pg_dump / pg_restore bei PostgreSQL: ein Kommandozeilen-Tool, das Datenbankinhalte in eine Dump-Datei schreibt und zurückspielt – simpel, aber ohne Rücksicht auf Latenz, Applikationsverfügbarkeit oder Indexstrategie.

• expdp / impdp bei Oracle: Export/Import auf Dateiebene – effektiv, aber keine echte Plattformtransformation.

Ein solches Vorgehen läuft oft ohne größere Änderungen – aber auch ohne Architekturverantwortung.

Beim Replatforming hingegen wird die Datenbank auf eine neue, cloud-native Plattform überführt: z. B. von Oracle On-Prem auf PostgreSQL in AWS Aurora, inklusive Anpassung von Stored Procedures, Indexierung, Performance-Monitoring und oft auch IAM-Konzept.
Wer von Schema-Konvertierung, Trigger-Neuschreibung, Nutzung von Read Replicas und automatisierten Backups spricht, war deutlich tiefer beteiligt als jemand, der nur Dumps verschoben hat.

Ein klarer Indikator: Wenn du im Interview nicht hören kannst, was konkret geändert wurde – war es kein echtes Replatforming.

2. Wer hat entschieden – und wer durfte nur mitmachen?

Migrationsprojekte sind nie rein technische Vorhaben. Sie betreffen immer auch Compliance, Betriebskosten, Verfügbarkeiten und oft sogar ganze Lizenzmodelle.
Deshalb entscheidend: Wer war an der Strategie beteiligt?

Wer die folgenden Begriffe nicht einordnen kann, war nicht Teil der Architektur- oder Entscheidungsphase:

• RTO / RPO: Wie viel Datenverlust ist tolerierbar? Wie schnell muss ein System wieder online sein?

• Cloud Governance Modell: Gab es Vorgaben zu Zugriffsrechten, Mandantenfähigkeit, Datenspeicherung?

• Business Case: Ging es um Lizenzkostenreduktion (z. B. „Raus aus Oracle“), Konsolidierung oder strategische Cloud-Nutzung (z. B. Integration mit Data Lake)?

Wichtige Differenzierung: Teil eines Projektteams ≠ Teil der Steuerung. Cloud Migration

3. Rollen verstehen: Architekt, DBA, Projektmanager – wer hat was wirklich gemacht?

Wenn jemand sagt: „Ich war verantwortlich für die Migration“, solltest du präzisieren:

• Hat die Person die Zielarchitektur entwickelt?

• War sie für das IAM-Konzept zuständig?

• Hat sie Terraform-Module für das Provisioning geschrieben?

• Oder war sie primär Koordinator:in von Dienstleistern?

Wer wirklich tief drin war, kann beschreiben:

• Wie das Sizing der Zielsysteme erfolgte (CPU, Memory, IOPS)

• Wie die Ausfallsicherheit konzipiert wurde (z. B. Azure Availability Zones vs. AWS Multi-AZ)

• Wie Secrets und Zugangsdaten gesichert wurden (z. B. mit Azure Key Vault oder AWS Secrets Manager)

Nur wer das alles erklären kann, hat Migration nicht nur begleitet – sondern verantwortet.

4. Ausfallsicherheit – wurde sie geplant oder nur behauptet?

„Natürlich haben wir auf Hochverfügbarkeit geachtet.“
Aber was bedeutet das? Cloud Migration

Wer das Thema ernst genommen hat, kann beschreiben:

• Welche Backup-Strategie eingesetzt wurde (Point-in-Time-Recovery? Snapshots? Archivierung in Glacier?)

• Wie Desaster Recovery geplant war (andere Region? anderes Konto? Cold Standby?)

• Ob Failover-Szenarien getestet wurden – oder nur auf PowerPoint existierten

Ein Warnzeichen: Wenn jemand „Monitoring“ sagt, aber keine Tools wie CloudWatch, Azure Monitor oder OCI Metrics nennt – dann gab es vermutlich kein echtes operatives Konzept.

5. Interviewfragen, die Verantwortliche beantworten können – und andere nicht

Wenn du im Interview schnell Klarheit brauchst, stell diese Fragen:

• Wie genau wurde die Datenbank migriert – Tool, Format, Ausfallzeit?

• Wie wurde die Applikation vorbereitet – gab es Dual Writes, Freeze-Phasen, Delta-Sync?

• Wer hat die Zielumgebung definiert – und wie?

• Welche Security Policies wurden für die Datenbankzugriffe definiert?

• Gab es automatisierte Deployments – und mit welchem CI/CD-Tool?

Und ganz konkret: Was war der schwierigste Moment in der Migration – und wie wurde er gelöst?

Wer hier konkret antwortet, war beteiligt. Wer abbricht oder ausweicht, war nur dabei.

🎯 Download: Interviewfragebogen Datenbankmigration (PDF)

20 Profi-Fragen – je 10 zur Migrationsverantwortung & Ausfallsicherheit
Nutze unsere Vorlage, um im Interview oder Screening zuverlässig herauszufinden:

• Wer Architektur, Plattformwahl und Security mitverantwortet hat

• Wer Downtime, Disaster Recovery und Backup-Prozesse mitgeplant (und umgesetzt) hat

Du willst wissen, wer eine Cloud-Migration wirklich gemacht hat? Wir helfen dir.

Datenbankmigrationen auf AWS, Azure oder OCI sind keine Standardjobs – sie erfordern technisches Tiefenverständnis, präzise Rollenklarheit und echtes Delivery-Know-how.

Wenn du solche Rollen besetzen willst, unterstützen wir dich nicht nur mit qualifizierten Kandidat:innen, sondern auch mit:

• Technischer Bewertung echter Projekterfahrung

• Präzisen Interviewfragen, die den Unterschied machen

• Deep Dives in Tools, Plattformlogik und Sicherheitskonzepte

👉 Du willst nicht raten, sondern wissen? Dann sprich mit uns. Wir finden die, die nicht nur „Cloud“ sagen – sondern Cloud wirklich gemacht haben.