ERP-Umzug in die Public Cloud: Identität, Ausfallverhalten und Wiederanlauf vor der Migration
Ein mittelständischer Handelsbetrieb (300 Benutzer, zwei Standorte, 24/7-Lagerlogistik) migriert sein Warenwirtschaftssystem in eine europäische Public-Cloud-Region. Derzeit laufen ERP-Datenbank und Fileserver im eigenen Keller; ein VPN mit Split-Tunneling verbindet die Standorte. Die Geschäftsführung will „kein eigenes Rechenzentrum mehr“. Anforderungen aus dem Fachbereich: Die Lager-Scanner müssen auch bei Internetausfall weiterarbeiten; die Buchhaltung braucht monatliche Auswertungen über acht Jahre; der Datenschutz verlangt, dass Personaldaten die EU nicht verlassen. Ein Ransomware-Vorfall bei einem Wettbewerber (vier Tage Stillstand) hat die Diskussion ausgelöst. Es gibt kein Inventar der Datenklassifizierung; Backups laufen nächtlich auf ein NAS im selben Raum, eine Wiederherstellung wurde seit zwei Jahren nicht getestet. Die IT besteht aus fünf Personen, davon zwei mit Netzwerkkenntnissen. Budget: 250.000 Euro für zwei Jahre, davon 90.000 Euro für den Betrieb.
1. Bewerten Sie die Migrationsentscheidung aus Architektursicht und benennen Sie mindestens vier Entscheidungen, die vor dem Umzug getroffen werden müssen – jeweils mit Begründung und Konsequenz.
Read the worked answer
Bewertung: Die Entscheidung ist tragfähig, aber die Reihenfolge ist falsch. Wer ohne Datenklassifizierung und ohne definierte Wiederanlaufziele migriert, verlagert das Problem lediglich in das Rechenzentrum des Anbieters – und verliert dabei die Eingriffsmöglichkeiten, die er heute hat.
Entscheidungen vor dem Umzug (je als Architecture Decision Record):
- Identität: Zentrales Identitätsverzeichnis mit Mehrfachfaktor und bedingtem Zugriff statt lokalem AD als Schatten. Konsequenz: standortübergreifende Anmeldung, aber der Identitätsanbieter wird zum Single Point of Failure – Notfallzugang für Administratoren einplanen.
- Netzwerk und Ausfallverhalten: Die Lager-Scanner benötigen eine lokale Pufferung mit Offline-Warteschlange und definierter Nachsynchronisation. Konsequenz: Edge-Komponente mit eigenem Betriebsaufwand, dafür kein Verfügbarkeitsrisiko im Kernprozess.
- Datenklassifizierung: Inventar mit vier Klassen (öffentlich, intern, vertraulich, personenbezogen) vor jeder Migration. Ohne dieses Inventar ist die Forderung des Datenschutzes nicht prüfbar und die Aussage „Personaldaten bleiben in der EU“ nicht belegbar.
- Backup und Wiederanlauf: RTO und RPO mit dem Fachbereich vereinbaren (Vorschlag: RPO 15 Minuten für Wareneingang, RTO 4 Stunden für die Kommissionierung), unveränderliche Sicherungen, monatlicher Restore-Test.
- Exit-Strategie: Datenexport im offenen Format, Vertragslaufzeit, Rückführungsszenario. Ohne Exit ist die Entscheidung nicht umkehrbar.
Empfehlung zur Reihenfolge: Klassifizierung, dann Wiederanlauf, dann Identität, dann Netzwerk, dann Migration. Die ersten beiden Punkte kosten wenig Geld und verhindern die teuren Fehler.
2. Der Datenschutzbeauftragte fordert, dass Personaldaten die EU nicht verlassen. Welche technischen und organisatorischen Maßnahmen schlagen Sie vor, und wo bleibt ein unvermeidbares Restrisiko?
Read the worked answer
Zuerst präzisieren: Die Forderung betrifft Personaldaten, nicht alle Daten. Also Datenklassifizierung, dann Zuordnung der Systeme. Ohne diese Trennung wird die Diskussion pauschal und teuer – bis hin zur Forderung, gar nicht zu migrieren.
Technisch:
- Region-Pinning für die betroffenen Dienste, vertraglich zugesichert und nicht nur Standardeinstellung im Portal.
- Verschlüsselung mit kundenseitig gehaltenen Schlüsseln, sodass der Anbieter ohne Kundenschlüssel nicht entschlüsseln kann.
- Bedingter Zugriff, Mehrfachfaktor und Protokollierung jedes administrativen Zugriffs.
- Personaldaten in einem getrennten Mandanten oder zumindest getrennten Bereich, damit der Zugriff nicht über die allgemeine ERP-Rolle läuft.
Organisatorisch:
- Auftragsverarbeitungsvertrag mit Liste der Unterauftragnehmer und Vorabgenehmigung bei Wechsel.
- Kritischer Punkt: Support-Zugriffe. Ein Anbieter-Support aus einem Drittland kann Daten einsehen, auch wenn die Daten in der EU gespeichert sind. Regelung: Support nur über kundenseitig gesteuerte Sitzungen, mit Genehmigung und Protokoll, Personal nur im Notfall.
- Löschkonzept mit Nachweis, nicht nur Zusicherung.
Restrisiko: Die rechtliche Bewertung von Drittlandzugriffen und die Frage, ob der Anbieter seine Unterauftragnehmer wechselt, bleiben bestehen. Dieses Restrisiko ist zu dokumentieren und vom Datenschutzbeauftragten zu bewerten – es verschwindet nicht durch Technik, sondern wird lediglich kontrollierbar und damit entscheidbar.
3. Wie gehen Sie mit dem Ausfallrisiko der Lager-Scanner und den ungetesteten Backups um – was priorisieren Sie mit dem vorhandenen Budget?
Read the worked answer
Zuerst die Zahlen, dann die Technik. RTO und RPO sind keine IT-Werte, sondern Geschäftsentscheidungen. Ein Lager, das 24/7 kommissioniert, hat andere Anforderungen als die Buchhaltung. Ohne diese Festlegung ist jede Backup-Diskussion beliebig und endet beim günstigsten Anbieter.
Priorisierung – bewusst gegen die Erwartung „erst Technik kaufen“:
- Restore-Test (sofort, Kosten: Personalzeit). Ein ungetestetes Backup ist kein Backup. Erster Schritt: eine vollständige Wiederherstellung mit Stoppuhr, Ergebnis dokumentiert. Sehr wahrscheinlich zeigt sich, dass die Wiederherstellung länger dauert als der tolerierbare Ausfall – das ist die eigentliche Botschaft an die Geschäftsführung und die Grundlage jeder weiteren Investition.
- Offline-Fähigkeit der Scanner. Direkt am Kernprozess, größter Schaden pro Ausfallstunde. Lokale Warteschlange, definierte Nachsynchronisation, getesteter Wiedereintritt.
- Unveränderliche, räumlich getrennte Sicherung. Adressiert genau das Ransomware-Szenario des Wettbewerbers: Die Sicherung darf vom kompromittierten Netz aus nicht löschbar sein.
- Wiederanlaufplan mit Rollen. Wer entscheidet, wer ruft an, in welcher Reihenfolge wird gestartet.
- Erst dann Cloud-Migration mit den definierten Zielen.
Budgetaussage: 90.000 Euro Betriebsbudget für zwei Jahre ist für diesen Zuschnitt knapp. Die Punkte 1 bis 4 sind überwiegend Personal- und Organisationsaufwand und aus dem laufenden Budget finanzierbar. Reicht das nicht, ist nicht die Migration das Problem, sondern ihre Reihenfolge.