Netzwerk-Migration im laufenden Betrieb

Die ComConsult wurde beauftragt, diesen Teil des Rechenzentrums zu erneuern. Die Verkabelungsplanung und -umsetzung der neuen Switches war dabei bereits in einem vorangegangenen Projekt der ComConsult erfolgt. Das hier beschriebene Projekt knüpft daran an und gliederte sich grob in zwei große Phasen: zunächst in die Auswahl und Beschaffung einer neuen Netzwerk-Infrastruktur, anschließend in die physische und logische Migration sämtlicher angeschlossener Server vom alten auf das neue Netzwerk. Und zwar im laufenden Betrieb, ohne den Geschäftsbetrieb zu gefährden. Dieser Artikel beschreibt den gesamten Weg: von der strukturierten Anbieterauswahl über die Architekturentscheidung bis hin zur kleinteiligen, oft mühsamen Praxis der eigentlichen Migration, bei der ich als mitverantwortlicher Berater die Planung und Steuerung übernommen habe.

Das Projekt eignet sich gut als Fallbeispiel, weil es zwei Dinge zeigt, die selten zusammen betrachtet werden: die strategische Entscheidungsebene, also welche Technologie und welcher Anbieter zum Einsatz kommen, und die operative Realität danach. Wie bekommt man hunderte Server ohne nennenswerten Ausfall auf eine neue Plattform? Gerade Letzteres wird in Projektplänen oft unterschätzt. Dabei steckt genau dort der größte Teil des tatsächlichen Aufwands.

Ausgangslage und Zielsetzung

Die bestehende Cisco-Infrastruktur war über Jahre gewachsen und entsprechend heterogen. Mit dem nahenden Lebensende der Hardware stand der Kunde vor der Entscheidung, entweder erneut auf bekannte Technologie zu setzen oder den Wechsel zu einem moderneren Architekturansatz zu wagen. Schnell war klar, dass eine reine Eins-zu-eins-Erneuerung der alten Struktur die eigentlichen Probleme nicht lösen würde: mangelnde Skalierbarkeit, komplexe Fehlersuche, unklare Redundanzpfade. Stattdessen wurde der Anspruch formuliert, eine moderne, hochverfügbare Spine-Leaf-Architektur aufzubauen, die beide Rechenzentren des Kunden möglichst gleichwertig bedient und im Falle eines kompletten Ausfalls eines Standorts den Betrieb über das jeweils andere Rechenzentrum aufrechterhalten kann.

Damit war der Rahmen für das Projekt gesteckt. Es ging nicht um einen reinen Hardwaretausch, sondern um eine grundlegende Neuordnung der Netzwerk- und Serverlandschaft, inklusive eines zusätzlichen Wunsches des Kunden: Im Zuge der Migration sollte gleich ein sogenanntes POD-Design eingeführt werden, bei dem Server gleichen Typs künftig physisch zusammenstehen, statt wie bisher über viele Schränke verteilt zu sein. Wenn gleichartige Server in denselben oder benachbarten Schränken stehen, lassen sich Verkabelung, Netzwerkkonfiguration und Wartung deutlich strukturierter und effizienter gestalten. Fehler sind schneller zu lokalisieren, Erweiterungen einfacher zu planen, und die Übersichtlichkeit im Rechenzentrum steigt spürbar.

Der Auswahlprozess: Von der Ausschreibung zum Proof of Concept

Am Anfang des Projekts stand keine Technologieentscheidung, sondern eine strukturierte Anforderungsanalyse. Gemeinsam mit verschiedenen Fachbereichen des Kunden wurden die Anforderungen an die neue Infrastruktur erhoben. Diese Anforderungen wurden bewusst priorisiert und in zwei Kategorien unterteilt: A-Kriterien als unverzichtbare Muss-Anforderungen, etwa bestimmte Redundanzmechanismen, Mindestdurchsatz oder die Unterstützung bestimmter Protokolle, sowie B-Kriterien als wünschenswerte, aber nicht zwingende Zusatzfunktionen. Diese Trennung erwies sich später als äußerst hilfreich, weil sie die Bewertung der eingehenden Angebote objektivierbar und damit von subjektiven Präferenzen einzelner Beteiligter unabhängig machte.

Der fertige Anforderungskatalog wurde an mehrere Hersteller beziehungsweise Bieter verschickt, die jeweils schriftlich angeben mussten, in welchem Umfang sie die einzelnen Kriterien erfüllen. Die eingehenden Antworten wurden anschließend von einem mehrköpfigen Bewertungsteam sorgfältig ausgewertet und gegeneinander abgewogen, nicht nur hinsichtlich der reinen Erfüllungsquote, sondern auch mit Blick auf Plausibilität, Referenzen und strategische Ausrichtung der Hersteller.

Aus dieser Vorauswahl wurde eine engere Gruppe von Bietern zu einem praktischen Proof of Concept eingeladen. Das ist ein Schritt, der in vielen Projekten aus Zeit- oder Kostengründen übersprungen wird. Hier wurde bewusst Wert darauf gelegt, weil ein reiner Papiervergleich von Datenblättern erfahrungsgemäß nicht ausreicht, um die tatsächliche Praxistauglichkeit einer Lösung zu beurteilen. Jeder Bieter erhielt fünf Tage Zeit, in einer Testumgebung einen Aufbau zu realisieren, der typische Einsatzszenarien des Kunden möglichst realitätsnah abbildete. Dazu gehörten unter anderem Failover-Tests, das VLAN-Handling über mehrere Switch-Ebenen hinweg, die Konfigurationskomplexität im Alltag sowie das Verhalten der Lösung unter simulierten Fehlerbedingungen.

Während jedes PoCs wurde detailliert dokumentiert, welche der zuvor festgelegten A- und B-Kriterien tatsächlich in der Praxis erfüllt wurden und wo es Abweichungen zwischen dem schriftlich Zugesagten und dem real Gezeigten gab. Diese Differenz war in einigen Fällen aufschlussreich. Anforderungen, die auf dem Papier problemlos erfüllbar schienen, erwiesen sich im praktischen Testbetrieb teils als deutlich aufwendiger umzusetzen, während andere Anbieter durch pragmatische, im Datenblatt nicht sichtbare Zusatzfunktionen positiv auffielen.

Am Ende dieses mehrstufigen Verfahrens fiel die gemeinsame Entscheidung auf Arista-Switches. Sowohl die Erfüllung der zuvor festgelegten Kriterien als auch der Gesamteindruck aus dem Proof of Concept sprachen für diese Lösung.

Die Architektur: Spine-Leaf über zwei Rechenzentren

Die neue Infrastruktur basiert auf einer klassischen Spine-Leaf-Topologie, wie sie heute in vielen modernen Rechenzentren Standard ist. Statt einer klassischen dreistufigen Architektur mit Core-, Distribution- und Access-Ebene kommt eine flachere, zweistufige Struktur zum Einsatz. In jedem Serverschrank stehen in der Regel zwei Leaf-Switches, die die Access-Ebene bilden und direkt mit den Servern verbunden sind. Diese Leaf-Switches sind redundant an die zentralen Spine-Switches angeschlossen, die das Rückgrat der gesamten Netzwerkarchitektur bilden und für eine verlustfreie, performante Kommunikation zwischen allen angeschlossenen Schränken sorgen. Für ein Rechenzentrum ist das besonders passend. Im Unterschied zu einem klassischen Campus-Netzwerk, wo der Verkehr hauptsächlich zwischen Clients und Servern fließt, reden im Rechenzentrum vor allem die Server miteinander. Dieser sogenannte Ost-West-Traffic läuft in einer Spine-Leaf-Topologie immer über genau drei Hops, egal wo die beteiligten Server stehen. Das hält die Latenzen stabil und macht das Netz außerdem deutlich einfacher skalierbar als eine klassische hierarchische Architektur.

Ein zentrales Thema war von Anfang an die Verteilung auf die beiden Rechenzentren des Kunden. Beide Standorte sollen möglichst gleichwertig mit Hardware ausgestattet sein, sodass jedes für sich alleine lauffähig ist. Fällt ein Rechenzentrum komplett aus, soll der Betrieb im anderen weiterlaufen. Das klingt einfach, zieht sich aber durch das gesamte Projekt: Jedes VLAN muss an beiden Standorten verfügbar sein, und die gesamte Netzwerkplanung muss diese Redundanz von Anfang an mitdenken. Technisch wurde das nicht über einfaches L2-VLAN-Tagging gelöst, sondern über ein VXLAN-Overlay mit MP-BGP-EVPN als Control-Plane. VXLAN kapselt Layer-2-Segmente in UDP-Pakete und transportiert sie so über eine geroutete IP-Infrastruktur, während MP-BGP-EVPN die Verteilung der Erreichbarkeitsinformationen zwischen den Switches übernimmt. Das Ergebnis ist eine deutlich stabilere und skalierbarere Lösung als klassische Ansätze auf Basis von Spanning Tree.

Diese Entscheidung für eine moderne, skalierbare Architektur war zugleich die Grundlage für die eigentliche Aufgabe im Projekt. Sobald die neuen Switches physisch verbaut und grundkonfiguriert waren, begann die deutlich aufwendigere Phase: die Migration sämtlicher Bestandsserver von der alten auf die neue Infrastruktur.

Die Migrationsherausforderung: Mehr als nur ein Portwechsel

Mit dem Einbau der neuen Switches begann die nächste Phase des Projekts: die Migration aller Server, die bislang an der alten Cisco-Infrastruktur hingen, auf die neue Arista-Umgebung. Im laufenden Betrieb, mit dem Anspruch, Ausfallzeiten für die jeweiligen Anwendungen so gering wie möglich zu halten.

Diese Aufgabe wäre für sich genommen bereits anspruchsvoll genug gewesen. Erschwerend kam jedoch hinzu, dass der Kunde im Zuge der Migration gleichzeitig das bereits erwähnte POD-Design einführen wollte. Konkret unterschied der Kunde dabei mehrere Servertypen, unter anderem Server für virtuelle Maschinen, klassische Dienste-Server und Server für viele weitere spezialisierte Gruppen.

Das bedeutete, dass die Migration nicht nur ein Wechsel der Netzwerkanbindung war, sondern in sehr vielen Fällen auch ein physischer Umzug des Servers selbst, inklusive Ausbau, Transport zum neuen Schrank, Einbau und Neuverkabelung. Damit potenzierte sich die Komplexität gegenüber einer reinen Plug-and-Play-Migration erheblich, denn jeder einzelne Server musste individuell betrachtet werden. Wo steht er aktuell? Wo soll er nach POD-Logik künftig stehen? Welche Abhängigkeiten und Wartungsfenster sind zu berücksichtigen? Und wie wird sichergestellt, dass währenddessen kein produktiver Dienst ausfällt?

Methodik: Die dreistufige Planung pro Servertyp

Um diese Komplexität beherrschbar zu machen, wurde die Planung in mehreren Schritten aufgebaut, bevor ein einziges Kabel angefasst wurde. Der erste Schritt, die Schrank- und Standortplanung, wurde dabei bewusst für die gesamte Serverlandschaft auf einmal durchgeführt und nicht nach einzelnen Servertypen getrennt, da hier vor allem die übergeordnete POD-Struktur für das gesamte Rechenzentrum festgelegt werden musste. Erst ab dem zweiten Schritt, der Portplanung, erfolgte die Bearbeitung iterativ, jeweils für einen Servertyp nach dem anderen.

In der Schrank- und Standortplanung wurde für jeden Server erfasst, in welchem Schrank er sich aktuell befindet und in welchen Zielschrank er gemäß der neuen POD-Logik idealerweise umziehen sollte. Dabei lag von Anfang an ein besonderes Augenmerk darauf, die Anzahl der tatsächlich notwendigen physischen Umzüge so gering wie möglich zu halten. Jeder Umzug bedeutet schließlich ein zusätzliches Risiko, zusätzlichen Aufwand und potenzielle Ausfallzeit. Stand ein Server bereits im richtigen Zielschrank für seinen Typ, entfiel der physische Umzug; erforderlich war lediglich eine Neuverkabelung. Da diese Gesamtplanung auf Basis der vorhandenen, teils veralteten Bestandsdaten erstellt wurde, mussten einzelne Zuordnungen im weiteren Projektverlauf immer wieder nachjustiert werden, etwa wenn sich beim genaueren Hinsehen herausstellte, dass ein geplanter Zielschrank aus technischen oder räumlichen Gründen doch nicht passte.

Im zweiten Schritt, der Portplanung, wurde für jeden Server eines betrachteten Servertyps exakt dokumentiert, welche physischen Anschlüsse er besitzt. Also wie viele Netzwerkports, in welcher Geschwindigkeit, mit welcher Funktion (Produktiv-Traffic, Management, Storage-Anbindung und so weiter). Diese Bestandsaufnahme war deshalb so wichtig, weil die vorhandene Dokumentation des Kunden in manchen Fällen veraltet oder unvollständig war. Erst auf Basis dieser sauber erfassten Ist-Anschlüsse konnte anschließend jeder einzelne Serveranschluss einem konkreten Zielport auf den neuen Leaf-Switches zugeordnet werden.

Ein weiterer Teil der Planung war die VLAN-Planung im dritten Schritt, ebenfalls jeweils für einen Servertyp. Für jeden Server mussten sämtliche benötigte VLANs erfasst werden. Bei manchen Servertypen, insbesondere im Umfeld der VM-Hosts, waren das schnell mehrere Hundert VLANs pro Server. Jedes dieser VLANs musste anschließend exakt auf dem jeweiligen Ziel-Switchport konfiguriert werden, damit der Server nach dem Umzug wieder mit allen benötigten Netzwerksegmenten kommunizieren konnte. Zusätzlich musste jedes einzelne VLAN konsistent bis zum Spine durchgereicht und, aufgrund der gewünschten Standortredundanz, auch im jeweils anderen Rechenzentrum verfügbar gemacht werden. Ein einziges vergessenes oder falsch konfiguriertes VLAN konnte im schlimmsten Fall dazu führen, dass ein Server nach der Migration nicht mehr erreichbar war.

Ab der Portplanung wird also bewusst nicht die gesamte Serverlandschaft auf einmal durchgeplant, sondern jeweils nur ein Servertyp. Erst wenn die Planung für einen Typ vollständig abgeschlossen ist, beginnen die eigentlichen Umzüge. Dieses iterative Vorgehen ist bewusst gewählt, um aus den Erfahrungen der ersten Migrationswelle zu lernen und die Planung für die nächsten Servertypen entsprechend zu verfeinern, bevor sie in Angriff genommen werden.

Zusätzlich zur eigentlichen Planung und Umsetzung sorgen zwei weitere Faktoren immer wieder für zusätzlichen Koordinationsaufwand. Zum einen werden parallel zur laufenden Migration neue Server geliefert, die ebenfalls eingebaut und angeschlossen werden müssen. Das kann dazu führen, dass bereits geplante Umzüge bestehender Server zugunsten der Neulieferungen zeitlich nach hinten verschoben werden müssen. Zum anderen kommen aus den Fachbereichen immer wieder spontane Anfragen, bestimmte Server vorgezogen und schneller als ursprünglich geplant zu verlagern, etwa weil sich betriebliche Prioritäten kurzfristig ändern. Solche Sonderwünsche müssen jeweils gegen die bestehende Planung abgewogen werden, ohne die übergeordnete Logik der POD-Struktur und die Reihenfolge der Servertypen zu gefährden.

Eine besondere Herausforderung über alle Planungsschritte hinweg war die ständige Abstimmung mit unterschiedlichen Abteilungen und Zuständigkeiten auf Kundenseite. Anders als in kleineren Organisationen gab es hier keine einzelne Ansprechperson, die alle relevanten Informationen besaß. Wissen über Serverstandorte, Netzwerkanforderungen einzelner Applikationen und betriebliche Wartungsfenster verteilte sich auf verschiedene Teams, die nicht immer untereinander abgestimmt waren. Ein wesentlicher Teil der Beratungsleistung bestand daher darin, diese verteilten Informationen zusammenzuführen, Lücken in der bestehenden Dokumentation zu identifizieren und gemeinsam mit den Fachbereichen zu schließen.

Operative Umsetzung: Der wöchentliche Migrationsrhythmus

Sobald die Planung für einen Servertyp abgeschlossen war, wurde das konkrete Vorgehen gemeinsam mit dem für die physische Verkabelung zuständigen Team besprochen. Daraus entstand ein fester wöchentlicher Rhythmus: An bestimmten, vorab festgelegten Tagen wurde jeweils eine definierte Anzahl an Umzügen beziehungsweise Umverkabelungen eingeplant. Diese Taktung war notwendig, um die Komplexität handhabbar zu halten und gleichzeitig genug Pufferzeit für unerwartete Probleme einzuplanen.

Der eigentliche Migrationsablauf folgte dabei stets demselben, klar definierten Muster. Meist bereits mehrere Tage vor dem eigentlichen Umzugstermin beschaltete ein dediziertes Team auf Kundenseite die jeweiligen Ziel-Switchports mit den zuvor geplanten VLANs, setzte also die in Schritt drei erarbeitete VLAN-Planung in die tatsächliche Konfiguration der Arista-Switches um. Auf diese Weise war am Umzugstag selbst bereits alles vorbereitet, sodass sich die eigentliche Migration nicht durch offene Konfigurationsarbeiten verzögerte.

Am Umzugstag wurde der zu migrierende Server dann vom fachlich Verantwortlichen in den Wartungsmodus versetzt. Hierbei war besondere Vorsicht geboten, da die einzelnen Server-Cluster unterschiedlich stark ausgelastet waren. Bei manchen Clustern konnte problemlos eine größere Anzahl von Servern gleichzeitig gewartet werden, ohne dass die Anwendungsleistung spürbar beeinträchtigt wurde. Bei anderen, stärker ausgelasteten Clustern durften hingegen nur ein oder maximal zwei Server gleichzeitig in den Wartungsmodus versetzt werden, um die Verfügbarkeit der dahinterliegenden Dienste nicht zu gefährden. Diese Einschränkung beeinflusste maßgeblich, wie viele Migrationen pro Woche tatsächlich durchführbar waren.

Im Anschluss wurde der Server entweder physisch ausgebaut und im geplanten Zielschrank wieder eingebaut und verkabelt, oder, sofern er bereits im richtigen Schrank stand, lediglich neu verkabelt. Gerade bei diesem Schritt zeigten sich in der Praxis häufig kleinere, aber zeitraubende Probleme. Geplante Kabellängen passten nicht mehr exakt zur neuen Position des Servers, oder vorhandene Kabel erwiesen sich beim Umstecken als beschädigt und mussten kurzfristig ersetzt werden. Solche scheinbar kleine Vorfälle, summierten sich über die Vielzahl an Migrationen hinweg zu einem nicht zu unterschätzenden Zeitfaktor.

Nach abgeschlossener Verkabelung prüfte der jeweils Verantwortliche, ob der Server wieder vollständig erreichbar und funktionsfähig war. Erst nach erfolgreicher Prüfung wurde der Server final wieder in den produktiven Betrieb übernommen und der Wartungsmodus beendet. Danach konnte der nächste geplante Umzug in Angriff genommen werden.

Den Abschluss jeder einzelnen Servermigration bildete die Dokumentation. Im kundeneigenen Dokumentationstool wurden für jeden migrierten Server die neue Höheneinheit im Zielschrank, die verwendete Kabelnummer sowie der genaue Kabelweg festgehalten. Diese konsequente Nachdokumentation war nicht nur für den laufenden Betrieb wichtig, sondern auch deshalb, weil ein zentrales Ziel des Projekts darin bestand, die zuvor teils veraltete und lückenhafte Bestandsdokumentation des Kunden grundlegend zu erneuern und auf einen aktuellen, verlässlichen Stand zu bringen.

Stolpersteine in der Praxis

Trotz der sorgfältigen, mehrstufigen Planung verlief in der Praxis selbstverständlich nicht jede Migration reibungslos. Verschiedene Fehlerquellen traten dabei wiederkehrend auf und mussten jeweils zügig analysiert und behoben werden, um die Ausfallzeit der betroffenen Server möglichst gering zu halten.

Ein häufiges Problem war ein nicht erreichbarer Server nach Abschluss der Verkabelung. Die Ursachenforschung folgte dabei meist einem ähnlichen Schema. Zunächst wurde geprüft, ob das Kabel tatsächlich am korrekt geplanten Port angeschlossen wurde. Verwechslungen durch das Verkabelungsteam, insbesondere bei sehr eng getakteten Migrationstagen mit vielen parallelen Steckvorgängen, kamen ab und zu vor. War die Verkabelung korrekt, lag die Ursache häufig in Abweichungen zwischen der ursprünglichen, teils veralteten Kundendokumentation und der tatsächlichen Verkabelung des Altsystems. Wurde etwa ein Server fälschlich an einem anderen physischen Port als dokumentiert betrieben, führte dies zwangsläufig zu falschen Annahmen in der neuen Planung. Eine weitere, ebenfalls dokumentationsbedingte Fehlerquelle war eine unvollständige VLAN-Konfiguration auf dem Zielport. Fehlte ein einzelnes, für eine bestimmte Anwendung notwendiges VLAN in der ursprünglichen Erfassung, blieb der Server zwar grundsätzlich erreichbar, einzelne Funktionen oder Anbindungen funktionierten jedoch nicht. Daneben zeigte sich vereinzelt auch, dass die Planung selbst bei einzelnen Servern lückenhaft war, etwa wenn ein selten genutzter Anschluss oder ein Sonderfall in der ursprünglichen Erfassung schlicht übersehen wurde. Solche Fälle waren in der Praxis nicht vollständig zu vermeiden und wurden jeweils im Nachgang in die Planung der folgenden Migrationen eingearbeitet.

Diese wiederkehrenden Fehlerbilder verdeutlichen ein zentrales Spannungsfeld solcher Migrationsprojekte: Die Qualität der Planung steht und fällt mit der Qualität der zugrunde liegenden Bestandsdaten. Und genau diese Bestandsdaten sind in gewachsenen IT-Landschaften erfahrungsgemäß selten vollständig korrekt. Ein wesentlicher, wenn auch in klassischen Projektplänen selten explizit ausgewiesener Teil der Beratungsleistung bestand daher darin, im laufenden Migrationsprozess kontinuierlich Dokumentationslücken aufzudecken, zu validieren und zu schließen.

Zwischenfazit und Lessons Learned

Das Projekt zeigt exemplarisch, wie weit der Bogen in der IT-Beratung von der strategischen bis zur operativen Ebene reichen kann. Am Anfang stand ein strukturierter, mehrstufiger Auswahlprozess mit klar priorisierten Anforderungen und einem praxisnahen Proof of Concept, der eine fundierte, von allen Beteiligten getragene Entscheidung für eine moderne Spine-Leaf-Architektur auf Basis von Arista-Switches ermöglichte. Aktuell befindet sich das Projekt mitten in der kleinteiligen, oft mühsamen Realität der eigentlichen Migration: Hunderte Server, Tausende VLANs, unzählige Einzelentscheidungen über Schränke, Ports und Kabelwege. Und das alles bei laufendem Betrieb, unter Berücksichtigung höchst unterschiedlicher Belastungsgrenzen einzelner Server-Cluster und parallel zu Neulieferungen sowie spontanen Priorisierungswünschen aus den Fachbereichen.

Schon aus dem bisherigen Projektverlauf lassen sich mehrere Erkenntnisse ableiten, die sich auf vergleichbare Vorhaben übertragen lassen. Erstens zahlt sich ein praktischer Proof of Concept nahezu immer aus. Die Differenz zwischen schriftlich zugesagter und tatsächlich gezeigter Leistung war in diesem Projekt mehrfach entscheidungsrelevant. Zweitens ist die Qualität der Bestandsdokumentation der mit Abstand größte Risikofaktor bei Migrationsprojekten dieser Größenordnung. Wer hier zu Beginn investiert, spart im späteren Verlauf deutlich mehr Aufwand bei der Fehlersuche. Drittens lohnt sich eine konsequente Aufteilung nach Servertypen mit jeweils eigenständigem Planungs- und Umsetzungszyklus. Statt die gesamte Serverlandschaft in einem einzigen großen Schritt umzustellen, lässt sich so aus jeder Migrationswelle lernen und die Vorgehensweise für die jeweils nächste verbessern. Diese Lernkurve zeigt sich bereits jetzt: Die Erfahrungen aus der laufenden Migration des ersten Servertyps fließen direkt in die Feinplanung der nächsten Typen ein. Viertens zahlt sich die Investition in sorgfältige, strukturierte Planung im Projektverlauf mehrfach aus. Zeit, die vorab in Konzeption und Dokumentation gesteckt wird, reduziert Fehler, verkürzt Ausfallzeiten und spart am Ende mehr Aufwand, als sie gekostet hat. Und nicht zuletzt zeigt das Projekt, wie wertvoll ein externer Berater in solchen Vorhaben sein kann. Als projektfokussiertes Team agiert ComConsult unabhängig vom Tagesgeschäft und quer durch alle internen Hierarchien. So entsteht neben der gewohnten Organisationsstruktur ein schlankes Projektteam, in dem Themen schnell und pragmatisch vorangetrieben werden können, ohne in internen Abstimmungsschleifen zu versanden.

Für den Kunden zeichnet sich schon jetzt ab, wohin das Projekt führt: eine deutlich modernisierte, hochverfügbare und nach klaren POD-Prinzipien strukturierte Rechenzentrumsumgebung sowie eine vollständig aktuelle, verlässliche Dokumentation als Grundlage für künftige Erweiterungen und Migrationen. Bis dahin liegt jedoch noch ein erheblicher Teil der eigentlichen Umzugsarbeit vor dem Projektteam.