Ein Firmenumzug ist selten nur eine logistische Frage. Wer Server und die gesamte IT-Infrastruktur verlagert, bewegt sich in einem Hochrisiko-Projekt mit direktem Business-Impact. Fällt die IT-Sicherheit in dieser Phase, steht das Unternehmen still – und das oft zu einem Zeitpunkt, an dem ohnehin schon alle Ressourcen am Limit sind. Welche fünf Risiken wirklich zählen und wie du sie konkret vermeidest, zeigen wir dir hier.
Welche Aspekte sind bei der Server- und IT-Übersiedlung zu beachten?
Viele Unternehmen unterschätzen den Umfang einer IT-Übersiedlung. Der Umzug von Büromöbeln folgt klaren Regeln. Ein Rechenzentrumsumzug hingegen bringt eine Schicht an technischen, organisatorischen und rechtlichen Abhängigkeiten mit, die sich gegenseitig beeinflussen.
Aus unserer Erfahrung scheitern Projekte nicht am Willen, sondern an fehlender Planung. Wer erst am Umzugstag merkt, dass drei Applikationen auf denselben internen DNS-Eintrag zeigen, der jetzt nicht mehr stimmt, verliert Stunden – manchmal Tage. Die WKO Österreich hält fest: „Der erste Schritt einer erfolgreichen IT-Übersiedelung ist die detaillierte Erfassung und Dokumentation aller in Betrieb befindlichen Geräte, Softwarelizenzen und Schnittstellen.“
Konkret geht es um folgende Kernbereiche:
- Inventarisierung aller physischen und virtuellen Komponenten – nicht als Liste, sondern als Abhängigkeits-Graph aus echter Netzwerkkommunikation
- Dokumentation aller Schnittstellen, Firewall-Regeln, DNS-Einträge und Zertifikate vor dem ersten Gerät, das abgebaut wird
- Koordination zwischen IT, Netzwerk, Security, Applikationsteams und externen Dienstleistern mit klaren Verantwortungsgrenzen
- Prüfung aller Compliance-Anforderungen, insbesondere wenn der Serverstandort oder Provider wechselt
- Festlegung messbarer Abnahmekriterien (RTO/RPO) vor Projektstart – nicht nach dem Cutover
Für Unternehmen in Wien gilt ein zusätzlicher Aspekt: Wer im 1. Bezirk oder in gründerzeitlichen Gebäuden sitzt, muss Zugang, Aufzugmaße und Etappenplanung frühzeitig abstimmen. Unsere Erfahrung mit Übersiedlungen im 7. Bezirk Wien zeigt, dass bauliche Gegebenheiten den Zeitplan eines IT-Umzugs massiv beeinflussen können.
Umzugsstrategie festlegen: Big Bang vs. Move-Wellen
Bevor du das erste Rack anfasst, braucht es eine Grundsatzentscheidung: Alles auf einmal oder gestaffelt?
Big Bang
- Gesamte Infrastruktur zieht an einem Wochenende um
- Enges Zeitfenster, maximaler Druck auf alle Beteiligten
- Kein Parallelbetrieb nötig – aber kein Puffer bei Problemen
- Rollback praktisch unmöglich, sobald Systeme am neuen Standort angebunden sind
Move-Wellen
- Systeme werden in Gruppen migriert – zuerst Infrastruktur, dann Applikationen
- Längere Übergangsphase mit Alt-/Neusystem parallel
- Fallback bleibt realistisch, solange Altsystem noch läuft
- Mehr Koordinationsaufwand, aber deutlich geringeres Gesamtrisiko
Entscheidungshilfe: Big Bang oder Move-Wellen?
Big Bang passt, wenn die Infrastruktur klein und gut dokumentiert ist, ein klares Wartungsfenster existiert und alle Systeme unabhängig voneinander laufen. Für komplexe Umgebungen mit vielen Abhängigkeiten ist das ein Hochrisiko-Szenario.
Move-Wellen sind die risikoärmere Wahl für Unternehmen mit gewachsenen Systemlandschaften. Wir migrieren dabei nicht nach IT-Komponenten, sondern nach Wertstrom: zuerst Identity, DNS und Netzwerkpfade, dann erst Applikationen. Wer „Apps zuerst“ macht, produziert Domino-Ausfälle.
Risiko 1 – Downtime und Betriebsunterbrechung
Ursachen: Cutover, Parallelbetrieb und Abhängigkeiten
Downtime beim IT-Umzug entsteht selten durch einen einzigen Fehler. Meistens ist es eine Kette: Der Cutover-Zeitpunkt passt nicht zur Datenbankreplikation, eine Applikation zeigt noch auf die alte IP, und der DNS-Cache braucht 48 Stunden zum Propagieren. Jeder dieser Punkte kostet Stunden.
Besonders tückisch: die Übergangsphase, in der Alt- und Neusystem parallel laufen. Hier entstehen Prozessprobleme und Kommunikationsprobleme fast zwangsläufig. Wer schreibt wohin? Welche Daten sind aktuell? Welches System ist das führende? Ohne klare Antworten auf diese Fragen vor dem Umzugstag wird der Cutover zur Fehlersuche.
CERT.at empfiehlt ausdrücklich vollständige Testläufe und Funktionstests vor dem endgültigen Umzug, um Betriebsunterbrechung und Fehlfunktionen zu minimieren. Wir ergänzen das um Pilot-Cutovers mit messbaren Stabilisierungskriterien – keine Freigabe ohne grünes Signal aus dem Monitoring.
Maßnahmen: Migrationsplan, Testfenster, Kommunikationsplan
- Dependency-Graph vor dem Umzug aus echten Netzwerkdaten erstellen, nicht aus Dokumenten
- Cutover-Reihenfolge nach Wertstrom festlegen: Identity und DNS zuerst, Applikationen danach
- Write-Freeze-Fenster definieren, in dem keine Daten mehr auf Altsysteme geschrieben werden
- Testfenster mit kontrollierter Abschaltung einzelner Systeme vor dem echten Move-Tage Termin
- Kommunikationsplan mit klaren Eskalationswegen für alle Beteiligten – auch für externe Dienstleister
- Backups validieren: Rücksicherung muss nachweisbar getestet sein, nicht nur vorhanden
Change-Kommunikation und gute Vorbereitung reichen aus, um Widerstände und Ausfälle zu vermeiden. Wenn alle informiert sind, läuft es schon.
Wir behandeln Widerstand als Symptom technischer Unsicherheit. Technische Proben – Pilot, Staging, Cutover-Test – sind der einzige harte Gegenbeweis gegen „wird schon klappen“. Wenn Systeme wackeln, kippt Akzeptanz sofort.
Risiko 2 – Sicherheitslücken und Datenabfluss
Patching und Hardening vor dem Umzug
Ein Firmenumzug ist ein Sicherheitsereignis mit erhöhter Angriffsfläche. Wir erleben das regelmäßig: Während alle mit Logistik beschäftigt sind, laufen Altsysteme mit veralteten Patches weiter, Berechtigungen werden provisorisch erweitert und Sicherheitslücken bleiben offen, weil „das nach dem Umzug geregelt wird“.
Genau das ist die Falle. Ransomware verschlüsselt Daten und Systeme oft dann, wenn Monitoring-Lücken bestehen und niemand schnell reagieren kann. Phishing ist der häufigste Einstiegspunkt – und beim Firmenumzug besonders gefährlich, weil Mitarbeitende kognitiv überlastet sind, Prozesse sich täglich ändern und externe Dienstleister neu auftreten. Perfekte Tarnkulisse für Social Engineering.
Das BSI ist klar: Phishing zielt darauf ab, Passwörter und Anmeldedaten abzugreifen. Wir gehen weiter: Während des Umzugs sperren wir Identitäts- und Berechtigungsänderungen stärker ab, härten MFA und frieren Admin-Rechte ein, weil genau dann besonders viele „ungewöhnliche“ Mails und Prozesse auftreten.
Für Unternehmen, die Cloud-Dienste nutzen oder in die Public Cloud wechseln, gelten noch strengere Anforderungen. Mehr dazu in unserer Analyse zur Sicherheit einer Shared Responsibility Cloud-Infrastruktur.
Datenschutz, DSGVO und Compliance
Wechselt der Serverstandort oder der Provider, greifen DSGVO-Pflichten unmittelbar. Die Datenschutzbehörde Österreich hält fest: Personenbezogene Daten müssen gemäß DSGVO Art. 32 während und nach der Übersiedlung abgesichert werden. Alle Zwischenschritte sind zu protokollieren.
Praktisch bedeutet das: Neue Auftragsverarbeitungsverträge prüfen, Datensicherheit am Zielstandort dokumentieren, Compliance-Anforderungen an ISO-Zertifizierungen des neuen Rechenzentrums abklären. Ein Providerwechsel kann technisch reibungslos laufen und trotzdem DSGVO-Probleme produzieren, wenn der Datenstandort sich ändert und das nicht sauber dokumentiert ist.
- Alle Altsysteme vor Migration auf Schwachstellen prüfen und dokumentieren – keine ungepatchten Systeme umziehen
- Change-Freeze für Admin-Rechte während der Umzugsphase einrichten
- MFA auf allen kritischen Systemen vor dem Cutover aktivieren und testen
- E-Mail-Filter und Anti-Phishing-Tools auf erhöhte Sensitivität stellen
- Mitarbeitende gezielt auf Umzugs-Phishing sensibilisieren: URLs und Absenderadressen prüfen vor jedem Klick
- Netzwerksegmentierung am Zielstandort vor dem Umzug designen, nicht danach
- Firewall-Regeln zwischen Segmenten dokumentieren und testen
Segmentierung wird als Security-Kapitel behandelt, das man nach dem Umzug „ordentlich macht“. Temporäre Any-Any-Freischaltungen im Netz sind halt nötig, damit alles läuft.
Wir behandeln den Umzug als Segmentierungs-Reset. Zuerst das Ziel-Netzwerk designen, dann den Umzug so bauen, dass keine provisorischen Workarounds nötig werden. Netzwerksegmentierung ist eine technische Randbedingung des Migrationsdesigns – kein nachträgliches Security-Thema.
Die Forschung zur Digitalen Souveränität und IT-Risiken zeigt deutlich: Unternehmen, die Sicherheitsarchitektur als integralen Bestandteil des Migrationsprojekts behandeln, verzeichnen signifikant weniger Sicherheitsvorfälle in der kritischen Umzugsphase.
Risiko 3 – Fehlende Rollback-Strategie (Fallback)
Rollback-Plan: Kriterien, Zeitfenster, Verantwortlichkeiten
Fast jedes IT-Projekt hat eine Rollback-Strategie auf dem Papier. Nur wenige haben eine, die in der Praxis funktioniert. Der Unterschied liegt in einem Detail: Hat sich der Datenstand geändert, seit der Umzug gestartet hat?
Sobald Systeme parallel schreiben oder Abhängigkeiten übersehen wurden, entsteht Dateninkonsistenz, die sich nicht einfach „zurückrollen“ lässt. Ein Rollback bringt dich nur dann wirklich zurück, wenn sich Daten und abhängige Systeme eindeutig in den Ursprungszustand zurückführen lassen. Wir planen deshalb nicht nur Rollback – wir verhindern den Rollback-Zwang durch beweisbare Datenkonsistenz.
Konkret: Write-Freeze-Fenster definieren, in denen keine Transaktionen mehr auf Altsysteme geschrieben werden. Validierungschecks nach jeder Migrationswelle. Und klare Rollback-Kriterien, die vor dem Cutover festgelegt werden – nicht im Stress danach.
Fallback beim Cutover: Zurückschalten statt Stillstand
Ein Fallback ist beim Tech-Refresh deutlich realistischer als beim Lift & Shift. Beim Tech-Refresh läuft die neue Hardware parallel auf, Daten werden migriert und das Altsystem bleibt bis zur erfolgreichen Validierung aktiv. Beim Lift & Shift ist das Altsystem bereits abgebaut, wenn Probleme auftauchen.
Unsere Empfehlung: Fallback-Zeitfenster explizit einplanen. Bis wann ist ein Zurückschalten noch möglich? Wer entscheidet das? Welche Metriken lösen den Fallback aus? Ohne Antworten auf diese drei Fragen ist die Rollback-Strategie nur eine Beruhigung, keine echte Absicherung.
- Write-Freeze-Zeitpunkt und Transaktionsgrenzen vor dem Cutover schriftlich festlegen
- Validierungschecks nach jeder Move-Wellen-Phase durchführen
- Fallback-Kriterien (Metriken, Zeitfenster, Entscheidungsträger) dokumentieren
- Datensicherung vor dem Cutover testen – Rücksicherung muss nachweisbar funktionieren
- Parallelbetrieb von Alt- und Neusystem nur mit klarer Führungssystem-Definition
Risiko 4 – Lift & Shift ohne Tests (Hardware- und IT-Landschaft-Risiken)
Lift & Shift vs. Tech-Refresh
Beim Lift & Shift wandert die bestehende Hardware physisch an den neuen Standort. Klingt einfach. Ist es aber nicht, wenn Server seit Jahren im Dauerbetrieb laufen, ohne je heruntergefahren worden zu sein.
Festplatten mit mechanischen Köpfen, die jahrelang rotiert haben, zeigen beim ersten Kaltstart nach dem Transport eine erhöhte Ausfallrate. Netzteile unter Dauerlast reagieren empfindlich auf Spannungsschwankungen nach dem Wiederanschluss. Wir haben in Projekten erlebt, dass genau diese Komponenten nach dem Transport versagen – nicht wegen des Transports selbst, sondern wegen des ersten Hochfahrens nach Jahren Laufzeit.
Der Tech-Refresh vermeidet dieses Risiko: Neue Hardware am Zielstandort aufbauen, Daten migrieren, Altsystem erst danach abbauen. Mehr Vorlaufzeit, aber deutlich weniger Überraschungen am Umzugstag.
Risiken minimieren: Test-Run, Ersatzteile, Checklisten
Wenn Lift & Shift die einzige Option ist, dann mit Vorbereitung. Kritische Ersatzteile – Festplatten, Netzteile, Netzwerkkarten – müssen vor dem Umzugstag bereitliegen. Nicht bestellt, bereitliegen. Der Versicherungsverband Österreich bestätigt: Server und Backup-Medien sollten ausschließlich von zertifizierten Fachfirmen transportiert werden, und die Transportversicherung muss vorab geprüft werden.
Beim Rechenzentrumsumzug kommt das Rack-Handling dazu. Racks sind schwer, sperrig und empfindlich gegenüber Erschütterungen. Verkabelung muss vor dem Abbau fotografiert und dokumentiert werden – nicht wegen Ordnungsliebe, sondern weil der Wiederaufbau sonst zum Rätsel wird.
Wien-spezifisch
Das Wiener Kopfsteinpflaster – besonders im 1. Bezirk – erzeugt Mikrovibrationen, die in Standard-Transportern ohne Luftfederung direkt auf Festplatten wirken. Wir nutzen luftgefederte Spezial-LKW und antistatische Klimaboxen für den IT-Transport. Ein gewöhnlicher Möbeltransporter ist für Server-Hardware schlicht nicht geeignet.
- Kritische Ersatzteile (Festplatten, Netzteile) vor dem Umzugstag bereitstellen
- Verkabelung vor dem Abbau vollständig fotografieren und beschriften
- Transportversicherung für IT-Hardware prüfen und abschließen
- Luftgefederte Transportmittel für Server und Storage-Systeme verwenden
- Alle Altsysteme auf bekannte Sicherheitslücken prüfen, bevor sie umziehen
- Test-Run: Systeme vor dem echten Umzugstag einmal kontrolliert herunterfahren und hochfahren
Eine umfangreiche Inventarliste stellt sicher, dass keine nachgelagerten Systeme abgeschnitten werden. Gut in Luftpolsterfolie verpackt passiert Servern im LKW nichts.
Wir akzeptieren keine Listen-Inventur. Der Dependency-Graph aus echter Netzwerkkommunikation zeigt, was wirklich mit was spricht. Und für den Transport: luftgefederte Spezial-LKW mit antistatischen Klimaboxen, weil das Wiener Kopfsteinpflaster Festplatten durch Mikrovibrationen beschädigt.
Risiko 5 – Transport, Verkabelung und physische Sicherheit
Herausforderungen beim Transport (Route, Zeitplan, Handling)
Transport ist ein eigenständiges Risikofeld – nicht nur eine logistische Aufgabe. Die Route muss vorab geprüft werden: Baustellen, Staus, Engstellen und Zufahrtsbeschränkungen können den Zeitplan eines IT-Umzugs zerstören. Besonders in Wien, wo Halteverbotszone und Zufahrtsregelungen komplex sind.
Beim Handling von Servern und Storage-Systemen gelten klare Anforderungen: antistatische Verpackung, Erschütterungsschutz, kontrollierte Temperatur. Hardware, die im Serverraum jahrelang bei 18 Grad läuft, reagiert empfindlich auf Temperaturschwankungen beim Transport. Das ist kein theoretisches Risiko – das ist ein praxisbelegter Ausfallgrund.
Physische Sicherheit wird oft unterschätzt
Physische Sicherheit endet nicht mit dem Schloss am Serverraum. Während des Umzugs sind Server außerhalb der gesicherten Umgebung – im LKW, auf der Laderampe, im Korridor. Wer hat zu welchem Zeitpunkt Zugang? Sind externe Transporteure in die Sicherheitsrichtlinien eingewiesen?
Dazu kommt ein oft übersehenes Risiko: Datenträger, die beim Transport verloren gehen oder gestohlen werden. Backup-Medien im selben LKW wie die primären Server – das ist kein Backup, das ist ein Single Point of Failure. Backups müssen getrennt transportiert werden, idealerweise auf einem anderen Fahrzeug zu einem anderen Zeitpunkt.
Die Forschung zu Cloud-Migration und IT-Infrastruktur Risiken unterstreicht, dass physische Sicherheitsmaßnahmen während Migrationen systematisch unterschätzt werden und zu einem der häufigsten unkontrollierten Risikofaktoren zählen.
- Route vorab prüfen: Baustellen, Engstellen, Halteverbotszone für Wien beantragen
- Luftgefederte Transportmittel mit antistatischer Klimabox für Server-Hardware
- Backup-Medien separat vom Primärsystem transportieren
- Zugangsprotokoll während des Transports: Wer hat wann Zugang zur Hardware?
- Externe Transporteure in Sicherheitsrichtlinien einweisen und dokumentieren
- Datensicherung vor dem Transport vollständig validieren – Rücksicherung testen
- Temperaturkontrolle während des Transports sicherstellen
Best Practice: Server-Übersiedlung sauber umsetzen
Wir haben in den letzten Jahren zahlreiche IT-Umzüge in Wien und österreichweit begleitet. Das Muster bei erfolgreichen Projekten ist immer dasselbe: Planung vor Ausführung, Beweise statt Annahmen, klare Verantwortungen statt Multi-Dienstleister-Pingpong.
Ein Umzug ist der seltene Moment, an dem du Sicherheits-Schulden entweder tilgst oder fest einbetonierst. Überbreite Netze, gemeinsam genutzte Ressourcen ohne eigenes Segment, ungepatchte Altsysteme – all das wird im Zeitdruck eines Umzugs gerne „mitgenommen“. Wir empfehlen das Gegenteil: Erst Security-Refactoring, dann Umzug. Altlasten raus, dann ziehen.
Für Unternehmen, die SaaS-Dienste oder Public Cloud nutzen, gilt ein weiterer Prüfpunkt: Lock-in-Risiken und Cloud-Kosten können nach einem Providerwechsel erheblich steigen, wenn Abhängigkeiten nicht vorab analysiert wurden. Virtuelle Maschinen in Shared-Infrastruktur bringen eigene Isolationsrisiken mit. Wer den Umzug als Anlass nimmt, diese Abhängigkeiten zu durchleuchten, gewinnt strategische Flexibilität. Mehr zu den technologischen Implikationen findet sich in der Analyse zu Innovativen Technologien und IT-Risiken.
Für Anwendertrainings gilt: Wir reduzieren den Schulungsbedarf, wo immer möglich, durch Interface- und Integrations-Kompatibilität. Wenn Mitarbeitende in gewohnten Arbeitsoberflächen bleiben können, entstehen weniger Fehler und weniger Widerstände gegen Veränderungen. Trainings sind kein Ersatz für gutes Prozess-Design.
Beim Thema Datenlecks und abgeschriebene Daten: Nutze den Umzug als Anlass für geordnete Archivierung. Aufbewahrungspflichten regeln, was wie lange aufbewahrt werden muss. Alles andere kann kontrolliert aussortiert werden – aber geregelt, nicht im Chaos des Umzugstags. Datensilos entstehen genau dann, wenn alte Daten unkontrolliert mitgenommen werden.
Häufige Fragen zum IT-Umzug beim Firmenumzug
Was ist der Unterschied zwischen Lift & Shift und Tech-Refresh beim Serverumzug?
Beim Lift & Shift wird die bestehende Hardware physisch transportiert – mit allen Risiken durch jahrelangen Dauerbetrieb und Festplattenalterung. Beim Tech-Refresh wird neue Hardware am Zielstandort aufgebaut, Daten werden migriert und das Altsystem erst danach abgebaut. Das reduziert Hardware-Ausfallrisiken erheblich, erfordert aber mehr Vorlaufzeit.
Warum ist eine Rollback-Strategie beim IT-Umzug so kritisch?
Eine Rollback-Strategie funktioniert nur, wenn Daten und abhängige Systeme eindeutig in den Ursprungszustand zurückführbar sind. Sobald Systeme parallel schreiben, entsteht Inkonsistenz, die sich nicht rückgängig machen lässt. Wir planen Write-Freeze-Fenster und Validierungschecks vor jedem Cutover – damit der Fallback eine echte Option bleibt.
Warum ist Phishing beim Firmenumzug besonders gefährlich?
Während eines Umzugs sind Mitarbeitende kognitiv stark belastet, Prozesse ändern sich täglich und externe Dienstleister treten neu auf. Das schafft eine ideale Tarnkulisse für Social Engineering. Wir empfehlen einen Change-Freeze für Admin-Rechte und verstärkte MFA-Härtung während der gesamten Umzugsphase.
Welche DSGVO-Pflichten gelten beim Serverumzug in Österreich?
Gemäß DSGVO Art. 32 müssen personenbezogene Daten während und nach der Übersiedlung technisch abgesichert werden. Die Datenschutzbehörde Österreich fordert vollständige Protokollierung aller Zwischenschritte. Wechselt der Datenstandort oder der Provider, sind neue Auftragsverarbeitungsverträge und Compliance-Prüfungen notwendig.
IT-Umzug in Wien geplant?
Wir begleiten Firmenumzüge mit IT-Infrastruktur von der ersten Planung bis zum validierten Cutover. Luftgefederte Spezial-LKW für Server-Transport, antistatische Klimaboxen und ein erfahrenes Team – das ist unser Standard für jeden IT-Umzug in Wien und österreichweit. Ruf uns an oder schick uns deine Anfrage.
Jetzt Beratung anfragen
