01
Erster Plan
Was bleibt, was sich ändert
Neu aufsetzen, kapseln oder stilllegen, je Komponente entschieden. Was identisch bleiben muss, steht schriftlich. Jede gewollte Änderung auch.
Modernisierung
Ein neuer Kern unter den Oberflächen, die Ihre Kunden schon nutzen.
Das Geschäft darf nicht stehenbleiben. Das System muss sich trotzdem ändern. Ein Schwarm setzt den Kern parallel neu auf, ein verantwortlicher Ingenieur stellt sicher, dass nichts bricht, worauf Ihre Kunden angewiesen sind.
Warum Neuimplementierungen stocken.
Das Team wächst, der Termin rutscht, das Altsystem läuft weiter – weil dem neuen niemand traut.
Produktiv
Das System verdient jeden Tag Geld. Ein klassisches Vorhaben verlangt, dass es achtzehn Monate wartet.
Regression
Niemand kann aufzählen, was nicht brechen darf. Also wird alles von Hand getestet – oder gar nicht.
Drift
Die Neuimplementierung wird zum zweiten Produkt mit eigenem Backlog. Das Alte ist weiter das, was Kunden nutzen.
Während der Laufzeit
Was Sie jederzeit sehen.
Wo es liegt
Ihre Cloud. Ihr Repository.
- 01 Anwendung Web, Mobile und Berichte laufen in Ihren Konten.
- 02 Repository Der erste Commit gehört bereits Ihnen.
- 03 Hosting Wir hosten nie. Es gibt nichts aufzulösen, wenn wir gehen.
Die Arbeit
Der Ablauf, in der Reihenfolge.
02
Schnittstellen
Schnittstellen festlegen
APIs, Ereignisse und Berichte stehen zuerst. Der Schwarm baut danach. Der neue Kern darf sie später nicht erfinden.
03
Paralleler Neuaufbau
Höchstes Risiko zuerst
Die Abläufe, deren Bruch Sie am meisten bereuen würden, kommen zuerst – jeweils mit Tests, die das alte Verhalten belegen.
04
Wechsel
Den alten Kern abschalten
Der Verkehr wandert Komponente für Komponente. Der alte Pfad geht erst aus, wenn Ihr Team die Dateien abgenommen hat.
01
Prüfungen
Was nicht brechen darf, ist ein Test, keine Hoffnung.
Jeder benannte Kundenablauf bekommt einen Test, bevor der Schwarm den Kern anfasst. Die Tests laufen bei jeder Änderung. Ein Fehlschlag stoppt das Release, egal was der Termin sagt.
Prüfungen
Was eine fehlgeschlagene Prüfung blockiert
- 01 Release Ein fehlgeschlagener Build geht nicht raus. Auch nicht auf Staging.
- 02 Produktiv Eine fehlgeschlagene Sicherheits- oder Leistungsprüfung geht nicht live.
- 03 Umschaltung Keine Umschaltung ohne schriftlichen, geprobten Rollback.
02
Risiko
Weder führen Sie die Neuimplementierung, noch tragen Sie dann jeden Fehlschlag.
Ein verantwortlicher Ingenieur trägt das Ergebnis, bis Ihr Team abnimmt. Kein Projekt, das Sie steuern, kein Anbieter, dem Sie hinterherlaufen.
Wer trägt es
Das Lieferrisiko hat einen Verantwortlichen
- 01 Stunden Viele Anbieter, viele Hände. Jeder Fehlschlag liegt bei Ihnen.
- 02 UNIT01 Ein verantwortlicher Ingenieur trägt das Ergebnis, bis Sie abnehmen.
- 03 Produktiv Sie entscheiden, wann der Verkehr wechselt. Wir stellen sicher, dass Sie das können.
03
Abnahme
Der alte Kern bleibt, bis Ihr Team abnimmt.
Ein Deployment ist keine Übergabe. Betriebshandbücher, Monitoring und offene Risiken liegen zuerst in Ihrem Repository. Dann geht der alte Kern aus.
Abnahme
Was vor der Unterschrift in Ihrem Repository liegt
- 01 Tests Zusammen mit dem Code geschrieben. Laufen in Ihrer Pipeline.
- 02 Betriebshandbücher Wie man es betreibt. Wen man anruft. Wie man zurückrollt.
- 03 Risiken Jeder offene Punkt hat einen Verantwortlichen. Nichts taucht später auf.
Im ersten Plan
Was vor dem Start festgehalten ist.
Der erste Plan benennt jeden dieser Punkte. Es ist ein Dokument: Sie können es annehmen, ändern oder ablehnen.
Zuordnung
Neu aufsetzen / kapseln / stilllegen
Je Komponente im ersten Plan entschieden. Nicht erst im sechsten Monat entdeckt.
Prüfungen
Was weiter funktionieren muss
Benannte Abläufe haben Bestehenskriterien, bevor wir den Kern anfassen. Das sind Tests, keine Liste.
Änderungen
Liste der gewollten Änderungen
Die Abnahme benennt, was neu ist. Eine nicht gelistete Änderung ist ein Defekt.
Verantwortlicher Ingenieur
Eine namentlich benannte Person
Der Ingenieur, der führt, steht im Vertrag. Sie lernen diese Person kennen, bevor Sie unterschreiben.
Dateien
In Ihrem Repository
Code, Tests, Betriebshandbücher, Monitoring und offene Risiken. Vor der Abnahme da.
IP
Code und Marke bleiben bei Ihnen
Im Vertrag übertragen. Wir hosten das Produkt nie und behalten es nicht.
Fragen, die uns gestellt werden
Häufige Fragen.
01
Warum ist das schneller, als wenn unser eigenes Team es macht?
Ihr Team hat ein Tagesgeschäft. Ein Schwarm nicht. Er setzt Komponenten parallel neu auf und schreibt ihre Tests, und der verantwortliche Ingenieur hält ihn im Rahmen der Schnittstellen, die Sie festgelegt haben.
02
Ist das eine Auffrischung der Oberfläche?
Nur wenn das Risiko in der Oberfläche liegt. Meist liegt es in Diensten und Daten. Der erste Plan sagt, was gilt.
03
Behalten Sie jedes Verhalten?
Wir behalten, was Sie benennen, und belegen es mit Tests. Alles andere ist eine gelistete Änderung, die Sie abnehmen.
04
Können Teile des Altsystems bleiben?
Ja. Kapseln und stilllegen sind gleichrangige Optionen, kein Scheitern.
05
Was, wenn der bisherige Anbieter bleibt?
In Ordnung, solange das Ergebnis einen Verantwortlichen hat. In der ersten Woche sagen wir, ob die Aufteilung unsicher ist.
06
Wann übernimmt der Betrieb?
Wenn er die Dateien in Ihrem Repository abnimmt. Nicht wenn ein Deployment durch ist.
Andere Leistungen
Dieselbe Arbeitsweise, an einem anderen System.
Nächster Schritt
Sagen Sie uns, was live gehen muss – und wann.
Sie erhalten einen ersten Plan: was fertig bedeutet — in Ihren Worten —, was es kostet und wann. Die Entscheidung liegt bei Ihnen.