Referenzen

Erst validieren, dann bauen: eine Multi-Site-Residency für Hyper-V & SCVMM

Für den Endkunden eines globalen IT-Dienstleisters aus der Verwaltung eines US-Bundesstaats · geliefert im Rahmen eines Dell-Residency-Vertrags

Die Engineers des Kunden hatten die schwere Arbeit bereits geleistet: Hosts ausgerollt, Failover-Cluster aufgebaut, das Netzwerk über zwei Standorte gespannt. Gefragt war kein Neubau — gefragt war Gewissheit. Ist sauber gebaut worden? Hält es im Betrieb? Und wie soll die Management-Ebene aussehen?

Genau um diese Frage haben wir die Residency strukturiert. Die ersten drei Wochen waren reine Validierung: Host-Konfiguration, Cluster-Verhalten, Storage- und Netzwerkpfade — methodisch geprüft, jeder Befund laufend dokumentiert. Keine übernommenen Annahmen, kein „wird schon passen".

Auf diesem validierten Fundament haben wir den SCVMM-Zielzustand entworfen und über beide Standorte hinweg aufgebaut — gefolgt von Enablement-Sessions, damit das Team des Kunden die Plattform selbst betreiben kann.

Der Moment, für den wir diese Geschichte erzählen, kam mitten im Engagement: Das Engineering-Team des Kunden nahm unser Zieldesign in den Review — und stellte eine Kernentscheidung infrage: Wo verläuft die Verantwortungsgrenze zwischen Network ATC und SCVMM für die Netzwerkkonfiguration? Der Einwand war berechtigt. Wir haben das Design überarbeitet; Version 1.1 trägt die Handschrift dieses Reviews — eine sauberere Aufteilung der Zuständigkeiten, Zeile für Zeile abgestimmt mit den Menschen, die die Plattform betreiben.

Manche Beratung würde das Scope-Reibung nennen. Für uns ist es das Engagement, das genau so funktioniert wie vorgesehen: Wir engineeren mit dem Kunden — nicht an ihm vorbei. Ein Design, das dem Review der Kunden-Engineers standhält, ist mehr wert als eines, das nie hinterfragt wurde.

Was nach unserem Abschied blieb: Validierungsberichte, das überarbeitete Zieldesign, Build-Dokumentation — und ein Team, das die Plattform beherrscht. Jede Stunde der Residency hat ein Artefakt hinterlassen.

Applikationsmigration, industrialisiert: aus einer Methodik wird eine Fabrik

Aktives Application-Migration-Engagement mit Dell · B2B2B-Delivery

Applikationsmigrationen scheitern selten am Werkzeug. Sie scheitern in den Lücken — zwischen Discovery und Planung, zwischen dem Runbook im Kopf eines Kollegen und dem, das nachts um zwei ausgeführt wird, zwischen „wir können zurückrollen" und einem tatsächlich getesteten Rollback-Plan.

In unserem Engagement mit Dell haben wir Dells 3-Phasen-Migrationsmethodik industrialisiert: kein Folien-Framework, sondern eine gesteuerte Migrationsfabrik.

So arbeitet die Fabrik:

• Phase-Gates. Jede Phase endet an einem Gate mit definierten Eingangs- und Ausgangskriterien. Nichts rutscht aus reinem Schwung in die nächste Phase.
• Generierte Runbooks — und generierte Rollback-Pläne. Für jede Move Group erzeugt die Fabrik den Hinweg und den Rückweg, in konsistenter, prüfbarer Form. Der Rollback-Plan ist kein nachgereichtes Dokument; er entsteht zusammen mit dem Runbook — jedes Mal.
• Menschliches Go/No-Go. KI-Agenten bereiten die Entscheidungsgrundlage auf: Discovery-Synthese, Abhängigkeits-Mapping, Validierungschecks, Dokumentation. Die Gate-Entscheidung trifft ein Mensch. Kein Migrationsschritt läuft auf Zuruf eines Agenten.
• Lückenlose Nachvollziehbarkeit. Jede Entscheidung und jede Aktion ist protokolliert und zuordenbar: was, wann, durch wen, mit wessen Freigabe.

Wir sind bewusst zurückhaltend mit dem, was diese Seite behauptet. Dies ist eine Methodik- und Fähigkeitsgeschichte: Die Fabrik ist in einem aktiven Dell-Engagement produktisiert und wird B2B2B an Dells Kunden geliefert. Ergebnisse veröffentlichen wir, wenn Kundenmigrationen abgeschlossen sind — nicht vorher.

Wenn Ihr Migrations-Backlog wie eine lange Reihe heroischer Einzelprojekte aussieht, ist das Fabrikmodell die Alternative: industrielle Konsistenz in den Artefakten, menschliches Urteil an jedem Gate.

Agentische Delivery, von Engineers verantwortet

Unser Delivery-Modell · so läuft jedes Engagement von Gus IT

Die erste Frage, die ein ernsthafter Einkäufer zu KI-gestützter Delivery stellt, ist die richtige: Ist es sicher, KI-Agenten in die Nähe produktiver Infrastruktur zu lassen?

Unsere Antwort ist eine strikte Arbeitsteilung — auf jedem Engagement.

Was unsere KI-Agenten tun: die repetitive Ingenieursarbeit, die Senior-Zeit frisst und menschliche Fehler begünstigt. Sie führen Discovery über ganze Umgebungen aus, verdichten Konfigurationen zu Dokumentation, generieren Runbooks samt Rollback-Plänen, fahren Validierungschecks und halten die Aktenlage aktuell — konsistent, zu jeder Stunde, ohne Ermüdung.

Was sie nie tun: ein Design freigeben. Unbeaufsichtigt ein Produktivsystem anfassen. Eine Go/No-Go-Entscheidung treffen.

Jedes Engagement hat einen benannten Senior Engineer, der die Designfreigabe und jede zustandsverändernde Aktion verantwortet. Unsere Automatisierung ist dry-run-sicher gebaut: Sie lässt sich proben, ohne Live-Systeme zu berühren, und jede Phase trägt einen Rollback-Plan, bevor sie eine Änderung trägt. Jede Aktion — ob von Mensch oder Agent — wird protokolliert und ist zuordenbar. Sie wissen immer, wer entschieden und wer gehandelt hat.

Warum das für Sie zählt: Sie bekommen die Konsistenz einer Fabrik in den Artefakten — Dokumentation, die wirklich vollständig ist, Runbooks, die wirklich aktuell sind —, ohne das Urteil an eine Maschine abzugeben. Der Engineer prüft nicht im Nachhinein die Hausaufgaben der KI; der Engineer ist das Gate, durch das die Arbeit muss.

Das ist kein Laborkonzept. So liefern wir heute unsere beauftragten Projekte — auch unter Partner- und Channel-Verträgen.

Wenn Sie abwägen, ob KI in Ihre Delivery-Kette gehört — oder wie Sie sie dort steuern —, bringen Sie Ihre härtesten Fragen mit ins Assessment. Dieses Modell ist dafür gebaut, hinterfragt zu werden.