Nutanix AHV Ersteinrichtung: Das Fundament für die Zeit nach VMware

Willkommen bei IT for Business. Ich bin Mirko Peters.

Wir arbeiten als IT-Dienstleister für den Mittelstand. Hier geht es nicht um Marketing-Hype oder bunte Produktbroschüren, sondern um echte Entscheidungen in den Bereichen Infrastruktur, Cloud und Security. Wenn Sie in Ihrem Unternehmen IT-Verantwortung tragen oder Dienstleister bewerten müssen, sind Sie hier genau richtig. Vernetzen Sie sich für einen Austausch aus der Praxis auch gerne mit mir auf LinkedIn.

Die meisten Unternehmen machen bei Nutanix AHV den ersten Fehler nicht erst während der Installation, sondern schon viel früher im Kopf. Sie nehmen alte VMware-Muster und kleben diese einfach auf eine neue Plattform. Später wundern sie sich dann über eine völlig unnötige Komplexität im täglichen Betrieb.

Klartext: Eine schnelle und vermeintlich günstige Ersteinrichtung sieht im Projektplan oft sauber aus. Die echte Rechnung erhalten Sie jedoch erst später in den Day-2-Operations. Das rächt sich bei jedem Upgrade, bei der Fehlersuche oder wenn Sie an Kapazitätsgrenzen stoßen.

Heute schauen wir uns an, welche Entscheidungen Sie bei AHV von Anfang an sauber treffen müssen, damit die Plattform langfristig tragfähig bleibt. Wir klären, welche Abkürzungen Sie besser gar nicht erst nehmen sollten. Bevor wir über Details wie Netzwerk oder Storage sprechen, müssen wir zuerst das Denkmodell geradeziehen.

Abschnitt 1: AHV ist kein neues VMware, und genau da beginnt der Fehler

Seien wir ehrlich: Viele Teams öffnen die AHV-Konsole und suchen instinktiv nach dem, was sie seit Jahren von vSphere kennen. Sie fragen nach Datastores, suchen Portgruppen oder wollen wissen, wie der einzelne Host tickt. Das ist menschlich verständlich, aber genau hier beginnt die Fehlplanung. AHV wurde nicht dafür gebaut, nur bekannte Begriffe an einer neuen Stelle anzuzeigen.

Das Betriebsmodell folgt einer völlig anderen Logik. Sie verwalten hier nicht mehr isoliert einen Hypervisor mit angebundenem Storage, sondern eine integrierte Plattform. Compute, Storage und Management hängen bei Nutanix untrennbar zusammen. Das klingt zunächst nach einer kleinen Verschiebung der Perspektive, bedeutet in der Praxis aber eine völlig andere Art, Infrastruktur zu entwerfen. Wenn Sie versuchen, AHV wie ein vertrautes vSphere mit neuem Logo zu behandeln, bauen Sie sich ein System, das operativ ständig Reibung erzeugt.

Besonders deutlich wird das beim Thema Storage. In der VMware-Welt denken viele historisch in LUNs und einer feinen Aufteilung nach starren Mustern. Bei Nutanix ist ein Container jedoch nicht einfach ein anders benannter Datastore. Ein Container fungiert vielmehr als Policy- und Schutzdomäne. Dort setzen Sie Eigenschaften, die später direkte Auswirkungen auf das Verhalten und die Kapazität Ihrer Daten haben. Wer das ignoriert, erschafft kein sauberes Design, sondern lediglich eine fehleranfällige Übersetzungstabelle aus der alten Welt.

Dann kommt die CVM ins Spiel, die oft unnötig schief erklärt wird. Betrachten Sie die CVM bitte nicht als lästigen Ballast, den man für ein hübsches Angebot kleinrechnen sollte. Sie ist ein fester Anker der Architektur, da dort die gesamte Storage-Intelligenz der Plattform sitzt. Das hat konkrete Folgen für Ihre RAM-Planung und die CPU-Reserven. Wer die CVM nur als Overhead betrachtet, plant schlicht am eigentlichen System vorbei.

Überlegen Sie mal, was das für Ihren späteren Betrieb bedeutet. Das Monitoring bleibt gedanklich an der alten Host-Sicht hängen und das Storage-Verständnis erstarrt in veralteten SAN-Kategorien. Im Team trennt dann weiterhin einer die Virtualisierung vom Storage, obwohl die Plattform diese Grenzen längst aufgelöst hat. So entstehen diese typischen Frankenstein-Integrationen, die technisch irgendwie laufen, für die aber niemand die Gesamtverantwortung übernimmt.

Was bedeutet das konkret für Sie? Betrachten Sie die AHV-Ersteinrichtung niemals als reine Installationsaufgabe. Es ist eine fundamentale Architekturentscheidung. Die relevante Frage ist nicht, wie schnell der Assistent durchläuft, sondern welches Betriebsmodell Sie für die nächsten Jahre zementieren. Wenn diese Grundhaltung fehlt, wird fast immer auch der nächste Bereich falsch aufgesetzt, und das ist das Netzwerk.

Abschnitt 2: Das Netzwerk ist bei AHV keine Randnotiz, sondern die Bodenplatte

Hier ist die eigentliche Frage, die sich viele erst stellen, wenn es zu spät ist: Welcher Teil Ihres aktuellen Netzwerkdesigns ist fachlich noch sinnvoll und was steht dort nur noch als Altlast, weil sich seit Jahren niemand herangetraut hat? In vielen Migrationsprojekten fehlt genau diese kritische Bestandsaufnahme. Das Ergebnis ist dann kein echter Entwurf, sondern ein bloßes Übertragen alter Fehler. Man gibt Portgruppen in der Zielplattform neue Namen, legt ein paar VLANs an und hofft darauf, dass die Logik schon irgendwie mitwandert. Seien wir ehrlich: Das tut sie fast nie von allein.

In der VMware-Welt sind wir an vDS, Portgruppen und oft auch NSX-Segmente gewöhnt, die auf einer gewachsenen Menge an impliziten Annahmen basieren. Bei AHV arbeiten Sie stattdessen mit Bridges, VLAN-basierten Netzen und Open vSwitch. Das ist nicht kompliziert, es wird oft nur unnötig kompliziert erklärt. Entscheidend ist hierbei, dass Architektur Tools schlägt. Sie brauchen kein exaktes Abbild der alten Struktur, sondern ein sauberes Zielbild, das technisch klar definiert und vor allem operativ beherrschbar bleibt.

Der häufigste Fehler, den ich in der Praxis sehe, ist erstaunlich banal. Die Namen der Portgruppen werden zwar sauber gemappt, aber niemand prüft die technischen Grundlagen mit der nötigen Disziplin. Welche VLAN-ID hängt dort wirklich dran und sind die Trunks auf den Uplinks korrekt freigeschaltet? Stimmt die MTU durchgängig vom Host über den Switch bis zu den betroffenen Netzen? Solche Fragen wirken trocken, aber genau da versteckt sich das Risiko. Eine Bezeichnung wie „Server-Prod“ hilft Ihnen am Ende des Tages nicht weiter, wenn das VLAN falsch konfiguriert ist oder das Gateway bisher stillschweigend in einer alten NSX-Logik vergraben war.

Damit kommen wir zu einem Punkt, der regelmäßig unterschätzt wird: die NSX-Altlasten. Viele Umgebungen nutzen verteilte Firewalls oder Security-Gruppen, die im Alltag kaum noch sichtbar sind, weil sie einfach im Hintergrund laufen. Das rächt sich beim Cutover. Die VM startet zwar sauber und die virtuelle Netzkarte sieht gut aus, aber die Anwendung kommt trotzdem nicht hoch. Warum? Weil die eigentliche Kommunikationslogik nie im Hypervisor saß, sondern an Stellen, die bei der Migration schlicht vergessen wurden.

Das betrifft nicht nur das Routing, sondern auch die IP-Konservierung. Wenn ein Migrationswerkzeug eine VM technisch sauber verschiebt, bedeutet das noch lange nicht, dass alle Abhängigkeiten intakt bleiben. DNS-Einträge, Firewall-Regeln und Lizenzbindungen hängen oft an einer ganz spezifischen Adresse. Wenn Sie die IP-Konservierung als Selbstverständlichkeit behandeln, statt sie als kritischen Prüfpunkt einzuplanen, wird aus der Migration schnell ein fachlicher Ausfall mit Ansage.

Schauen wir uns das physische Netz an, über das in Virtualisierungsprojekten erstaunlich gern hinweggeredet wird. AHV läuft nicht im luftleeren Raum, weshalb LACP, Uplinks und die tatsächliche Switch-Konfiguration darüber entscheiden, ob Ihr Design stabil bleibt oder in Grenzbereichen schlingert. Wenn das Virtualisierungs-Team und die Netzwerk-Abteilung aneinander vorbeireden, entstehen gefährliche Lücken. Der eine verlässt sich auf erlaubte VLANs, der andere auf dokumentierte Anforderungen, und am Ende übernimmt niemand die Verantwortung für das Gesamtbild. Genau dann wird aus einem Cutover ein teures Suchspiel.

Was bedeutet das konkret für Sie? Nutzen Sie bei der Einrichtung einen nüchternen Prüfrahmen. Erstens brauchen Sie eine vollständige VLAN-Matrix mit Zweck und Trunk-Freigabe. Zweitens ist eine Gateway-Liste Pflicht, damit klar ist, wo die Layer-3-Verantwortung künftig liegt. Drittens muss die MTU-Konsistenz von Ende zu Ende sichergestellt sein, nicht nur auf dem Papier. Viertens sollten Sie Test-VMs einsetzen, die echte Kommunikationspfade wie DNS und Applikationsports prüfen. Planen Sie die Cutover-Reihenfolge bewusst und verlassen Sie sich nicht auf Ihr Bauchgefühl.

Ein Punkt wird dabei gern übersehen, weil er im Projektstatusbericht gut aussieht: Eine VM kann erfolgreich migriert sein und trotzdem fachlich komplett ausfallen. Das passiert, wenn zwar Layer 2 steht, aber die Anwendung an Routing- oder Security-Hürden scheitert. Dann meldet das Protokoll einen Erfolg, während der Fachbereich bereits den Stillstand beklagt. Für den Betrieb ist nicht entscheidend, ob die VM läuft, sondern ob der Dienst für den Nutzer wieder erreichbar ist.

Wenn das Netzwerk an dieser Stelle sauber konfiguriert ist, haben Sie eine tragfähige Bodenplatte für alles Weitere geschaffen. Der nächste Denkfehler folgt jedoch oft direkt bei der Ressourcenplanung, wenn AHV wie ein einfacher Hypervisor-Block gerechnet wird und die CVM nur als Randnotiz auftaucht.

Abschnitt 3: Ressourcen richtig rechnen, sonst planen Sie sich die Plattform schön

Beim Ressourcenmodell wird aus einem Architekturprojekt oft sehr schnell eine geschönte Kalkulation. Klartext: Auf einem AHV-Node steht Ihnen niemals die komplette physische Host-Ressource für Ihre VMs zur Verfügung. Die Controller VM, kurz CVM, muss pro Node fest eingeplant werden. Wer in Präsentationen nur mit der Brutto-Kapazität rechnet und den Abzug in einer Fußnote versteckt, verkauft ein Bild, das im echten Betrieb nicht trägt.

Der Unterschied zum klassischen ESXi-Denken ist simpel, hat aber enorme Folgen. Sie haben hier keinen separaten Storage-Controller, der irgendwo außerhalb der Plattform Ressourcen verbraucht, ohne dass man es sieht. Die Storage-Intelligenz sitzt direkt im Cluster und beansprucht pro Node ihren festen Anteil an RAM und CPU. Das ist kein Schönheitsfehler, sondern ein integraler Bestandteil des Modells. Sie bezahlen also nicht nur für reine Rechenleistung, sondern auch für die Stabilität der Storage-Dienste und der internen Betriebslogik.

Viele Teams tappen hier in dieselbe Falle, indem sie die bisherige VMware-RAM-Dichte fast eins zu eins auf AHV übertragen. Auf dem Papier wirkt das wirtschaftlich und vernünftig. In der Praxis fehlt Ihnen dann aber genau der Puffer, den Sie für Wartungsfenster oder unerwartete Lastspitzen dringend gebraucht hätten. Dieses Problem zeigt sich selten am ersten Tag, sondern erst dann, wenn die Umgebung unter echter Last steht und die Planung von der Realität eingeholt wird.

Die Größe der CVM ist keine akademische Spielerei für Architekten, sondern bestimmt direkt Ihre nutzbare Kapazität. Je nach Workload und aktivierten Funktionen ändert sich, wie viel Reserve pro Node wirklich sinnvoll ist. Wer diesen Anteil zu knapp kalkuliert, reduziert nicht nur die VM-Dichte, sondern gefährdet im schlimmsten Fall die N+1-Fähigkeit. Sobald ein Node ausfällt oder für Wartungsarbeiten aus dem Betrieb genommen wird, muss der Rest des Clusters die Last auffangen und gleichzeitig die Plattformdienste stabil weiterführen.

Das wird noch deutlicher, wenn Sie zusätzliche Funktionen wie Deduplizierung oder Kompression nutzen möchten. Auch die Entscheidung zwischen klassischen All-Flash-Workloads und NVMe-Profilen bleibt nicht ohne Folgen für den Ressourcenhunger. Sie können einen Node nicht einfach als neutralen CPU-Block betrachten, auf dem ein bisschen Hypervisor läuft. So rechnen vielleicht Verkäufer in ihren Angeboten, aber so plant kein erfahrener IT-Leiter einen stabilen Betrieb.

Ein weiterer Punkt, der in Beschaffungsrunden gern untergeht, ist die Betrachtung des gesamten Clusters unter Ausfallbedingungen. Überlegen Sie mal, was bei einem Failover oder während eines Rolling Upgrades passiert. Wenn Ressourcen temporär gebunden sind und das Tagesgeschäft gleichzeitig weiterläuft, darf das System nicht in die Knie gehen. Wenn diese Fragen erst nach Projektabschluss gestellt werden, ist das Design meist schon viel zu eng gestrickt. Dann beginnt das hektische Nachkaufen und Rechtfertigen vor der Geschäftsführung.

Für Sie als Verantwortliche bedeutet das: Rechnen Sie grundsätzlich mit der nutzbaren Kapazität und niemals mit Brutto-Werten. Bewerten Sie den Cluster sowohl im Normalbetrieb als auch im N+1-Szenario. Planen Sie nicht nur für die durchschnittliche Last, sondern für Betriebszustände, in denen ein Node fehlt oder interne Dienste mehr Ressourcen ziehen. Erst dann sehen Sie schwarz auf weiß, ob das Angebot wirklich tragfähig ist oder nur auf den ersten Blick günstig wirkte.

Seien wir ehrlich: Eine zu knapp geplante AHV-Umgebung sieht in der Anschaffung zwar ordentlich aus, wird aber im laufenden Betrieb extrem teuer. Fehlende Puffer führen dazu, dass die Performance unter Druck gerät und jede Erweiterung zum Stressfaktor wird. Die Plattform wird dann nicht mehr nach ihrer technischen Qualität bewertet, sondern nur noch nach den Kompromissen, zu denen sie Ihr Team täglich zwingt.

Wenn die Ressourcen auf diese Weise falsch eingeschätzt werden, folgt der nächste Fehler meist automatisch. Das Storage-Design wird aus einer veralteten LUN-Logik heraus gebaut, statt die Policies und operativen Folgen der neuen Plattform wirklich zu nutzen.

Abschnitt 4: Storage-Container sauber aufsetzen, statt Datastore-Denken zu kopieren

Schauen wir uns den Storage-Teil einmal genauer an. Hier entscheidet sich oft, ob Sie eine moderne Plattform bauen oder nur alte Gewohnheiten in ein neues Gewand stecken. Ein Nutanix-Container ist nämlich keine umbenannte VMware-Struktur, die man einfach nur an einer anderen Stelle anklickt, und er ist auch nicht bloß ein optisch schönerer Datastore. Im Kern ist ein Container eine Policy-Domäne. Das bedeutet, dass jede Entscheidung bei der Anlage direkte Folgen für Ihren Datenschutz, die Kapazität und die Effizienz im späteren Betrieb hat.

Bei VMware hing das Denken meistens an dem, was physisch darunter als Block-Storage oder SAN bereitstand, wobei der Datastore lediglich als sichtbare Arbeitsfläche für die VMs diente. Bei Nutanix liegt die Logik völlig anders, da die Daten im gesamten Cluster verteilt werden. Die Eigenschaften, mit denen Sie diese Daten betreiben, hängen fest an den Policies des jeweiligen Containers. Sie definieren hier also nicht nur einen Speicherort, sondern legen fest, unter welchen Bedingungen Daten geschützt, repliziert oder komprimiert werden. Wenn Sie das wie eine reine Ordnungsfunktion behandeln, planen Sie an der eigentlichen Wirkung der Technologie vorbei.

Ein typischer Fehler im Mittelstand passiert oft aus einem Reflex heraus. Aus alter SAN-Gewohnheit werden unzählige Container angelegt, weil sich das für das Team sauber anfühlt. Da gibt es dann einen für die Produktion, einen für jede Fachanwendung und zur Sicherheit noch einen pro Abteilung. Auf den ersten Blick wirkt das zwar strukturiert, doch im Alltag erzeugt dieser Wildwuchs meist nur unnötige Komplexität. Wenn diese Container nämlich keinen echten Unterschied bei der Replikation oder den Data Services abbilden, produzieren sie lediglich Verwaltungsaufwand ohne jeden betrieblichen Nutzen.

Die Gegenrichtung ist allerdings genauso wenig ratsam. Ein einziger Container für alles ist nicht automatisch das bessere Design, denn wenn völlig unterschiedliche Workloads in derselben Policy landen, wird es später ungemütlich. Eine VDI-Umgebung tickt nun mal anders als allgemeine Server-VMs, und ein Archiv folgt einem ganz anderen Lastprofil als ein transaktionsreiches Datenbanksystem. Test- und Entwicklungsumgebungen brauchen oft nicht dieselbe strenge Replikationslogik wie Ihre produktiven Dienste. Wer hier alles in einen Topf wirft, spart am Anfang vielleicht Zeit bei der Entscheidung, handelt sich aber später faule Kompromisse ein.

Sinnvoll wird es erst, wenn Sie die Container nach echter Betriebslogik schneiden. Orientieren Sie sich nicht am Organigramm, sondern an den technischen Anforderungen. Ein Container für die allgemeine Produktion ist oft richtig, während ein separater für VDI sinnvoll sein kann, wenn sich das Lastverhalten dort klar unterscheidet. Backup-Daten oder Archive verdienen eine eigene Behandlung, weil Sie dort Kapazität und Latenz völlig anders gewichten müssen. Auch für Testumgebungen lassen sich getrennte Zonen führen, in denen Schutz und Replikation bewusst niedriger ausfallen dürfen, um Ressourcen zu schonen.

Jetzt wird es bei den Data Services konkret. Funktionen wie Kompression, Deduplizierung oder Erasure Coding setzen Sie nicht ein, nur weil der Hersteller ein Häkchen in der Software anbietet. Das muss wirtschaftlich und operativ zum jeweiligen Workload passen. Manche Daten profitieren massiv davon, während andere kaum einen Effekt zeigen. Während einige Workloads eine hohe Kapazitätseffizienz gut vertragen, benötigen andere vor allem Vorhersagbarkeit und ein ruhiges Verhalten unter Last. Werden solche Entscheidungen pauschal für den ganzen Cluster getroffen, landet man schnell in einem Mischbetrieb, der weder richtig schlank noch wirklich stabil läuft.

Ein Punkt wird dabei oft als technisches Detail abgetan, obwohl er direkt über Kosten und Resilienz entscheidet: der Replication Factor. Das ist keine Einstellung, die man einmal für das Protokoll festlegt und dann vergisst. Dieser Faktor bestimmt, wie schnell Ihre Kapazität schrumpft, wie widerstandsfähig der Cluster auf Hardware-Ausfälle reagiert und wie viel Spielraum Sie für spätere Erweiterungen haben. Wenn Sie diesen Punkt falsch einschätzen, sehen das Angebot und die Rohkapazität am Anfang zwar freundlich aus, aber später merken Sie schmerzhaft, dass der Schutzpfad nicht zu Ihren Erwartungen passt.

Lassen Sie es mich einfach sagen: Storage-Container in AHV sind kein Mittel zum kosmetischen Aufräumen in der Prism-Oberfläche. Sie sind ein Werkzeug, um das Verhalten Ihrer Infrastruktur berechenbar zu machen. Wenn Sie das ernst nehmen, bleibt Ihr Storage überschaubar und tragfähig. Kopieren Sie dagegen nur alte Datastore-Muster, bauen Sie eine Struktur auf, die zwar vertraut aussieht, aber das eigentliche Potenzial der Plattform komplett verfehlt. Selbst wenn Netzwerk und Storage an dieser Stelle sauber stehen, ist die Arbeit noch nicht getan, denn der teuerste Denkfehler zeigt sich oft erst bei den Day-2-Operations.

Abschnitt 5: Day-2-Operations müssen in der Ersteinrichtung eingebaut werden

An diesem Punkt trennt sich ein technisch lauffähiges Setup von einer Plattform, die Sie auch in einem Jahr noch sicher beherrschen können. Seien wir ehrlich: Die echten Kosten stehen nicht im ersten Projektplan für die Migration. Sie tauchen erst später auf, wenn es um Upgrades, Alerts oder den ersten ernsthaften Restore geht. Die Stunden, die Ihr Team in die Fehlersuche steckt, weil Zusammenhänge am Anfang nicht sauber definiert wurden, sind der eigentliche Preistreiber.

Betrachten Sie Prism, den Health-Check NCC und das Lifecycle Management LCM deshalb nicht als nette Zusatzfunktionen, die man irgendwann mal ausprobiert. Diese Werkzeuge müssen Teil Ihres Zielbilds sein, noch bevor die erste produktive VM übergeben wird. Wenn die Plattform später über ihre eigenen Mechanismen gewartet werden soll, müssen diese Abläufe von Anfang an geprüft und organisatorisch verankert werden. Das gilt besonders für Upgrades, bei denen viele zwar über den Go-Live sprechen, aber kaum jemand über die Abhängigkeiten oder Wartungsfenster unter realer Last.

Genau hier wird es riskant für den Betrieb. Wenn Sie erst Monate nach der Inbetriebnahme feststellen, dass Prozesse für Vorabprüfungen oder Rückfalloptionen fehlen, zahlen Sie am Ende mit der Stabilität Ihres Systems. Ähnlich nüchtern sollten Sie das Monitoring angehen. Es reicht nicht aus, die alte vCenter-Sicht nachzubauen und zu hoffen, dass der Rest von allein funktioniert. In einer AHV-Umgebung müssen Sie die Signale der Plattform ernst nehmen, was konkret bedeutet, dass Sie Cluster-Health, Kapazitätstrends und das Verhalten der CVMs im Blick behalten müssen. Das ist keine Kür für Spezialisten, sondern die Basis, damit Ihr Team Störungen erkennt, bevor sie zum Problem werden.

Ein weiterer Punkt, der regelmäßig auf später verschoben wird, ist das Thema Backup und Wiederanlauf. Das ist ein gefährlicher Fehler. Klären Sie unbedingt vor dem produktiven Betrieb, ob Ihre Backup-Software AHV in der nötigen Tiefe unterstützt und wie die Restore-Pfade im Detail aussehen. Ein gesichertes System ist nämlich noch lange kein wiederherstellbares System. Dieser feine Unterschied zeigt sich oft erst unter massivem Druck, und dann ist es für Grundsatzfragen definitiv zu spät.

Dazu kommt der organisatorische Teil, über den Anbieter im Verkaufsgespräch ungern sprechen, weil er nicht nach glänzender Technik aussieht. Ihre Administratoren brauchen nicht einfach nur ein neues Logo auf dem Monitor, sondern ein angepasstes Betriebsmodell. Zuständigkeiten müssen klar definiert sein: Wer bewertet den Zustand des Clusters, wer trägt die Verantwortung für die Upgrades und wer hält die Dokumentation aktuell? Bleiben diese Fragen offen, landet jede Störung im Niemandsland zwischen den Teamgrenzen, weil niemand mehr das Gesamtbild besitzt. Erst wenn diese operativen Hausaufgaben erledigt sind, wird aus einer bloßen Installation eine echte, strategische Plattformentscheidung.

Schluss: Architektur zuerst, sonst zahlen Sie später im Betrieb

Das war IT for Business für heute.

Wenn Sie aus diesem Gespräch einen Gedanken mitnehmen, dann diesen: Gute IT entscheidet sich niemals am Tool, sondern immer an der Architektur und den harten Entscheidungen im Vorfeld.

Bei Nutanix AHV bedeutet das ganz konkret, dass Sie das alte VMware-Denken konsequent ablegen müssen. Das Netzwerk muss sauber übersetzt werden, während Sie die CVM und die Kapazitäten von Anfang an ehrlich durchrechnen. Planen Sie Container bewusst ein und bauen Sie den späteren Betrieb direkt in die Ersteinrichtung ein, statt ihn erst später dranzustricken.

Meine Empfehlung für Ihr nächstes Projekt ist deshalb denkbar schlicht. Erstellen Sie vor der Freigabe eine belastbare Prüfliste für das Netzwerkdesign, das Ressourcenmodell und die Backup-Prozesse. Sprechen Sie mit Ihrem Team, bevor Sie unterschreiben, und stellen Sie zuerst die harten Fragen, nicht die bequemen.

Wenn Ihnen dieser Einblick geholfen hat, abonnieren Sie den Podcast, damit Sie keine weiteren Praxistipps für IT-Entscheider verpassen. Falls Sie gerade selbst vor einer Modernisierung stehen, stellen Sie die richtigen Fragen lieber früh als erst im laufenden Betrieb.

Wir hören uns in der nächsten Folge.

Unterschrieben ist schnell, aber aufgeräumt wird immer erst später im Betrieb.