IT-Dienstleister wechseln: Übergangsmanagement für Ihre Software
Sie wechseln den Dienstleister. Das Wissen des bisherigen dürfen Sie dabei nicht verlieren.
Wenn Sie Ihren IT-Dienstleister wechseln oder die Entwicklung von extern nach intern holen, steuern wir den Übergang strukturiert: Schutz Ihres geistigen Eigentums, Wissenstransfer, Planung der Kontinuität und technische Aufsicht, damit der Wechsel nicht zur Krise wird.
Sie müssen wechseln. Doch ein schlecht gemachter Wechsel kostet mehr, als zu bleiben.
Die Zusammenarbeit mit dem aktuellen Dienstleister funktioniert nicht mehr, sei es wegen Kosten, Qualität, unterschiedlicher Vorstellungen oder fehlenden Vertrauens. Wer aber ohne strukturierten Übergang wechselt, riskiert Unterbrechungen in der Lieferung, Wissensverlust und technische Schulden, die entstehen, wenn niemand für die Kontinuität verantwortlich ist.
Wir wollen den Dienstleister wechseln, aber das ganze Wissen liegt bei ihm.
Ihre Ausgangslage
Ein Dienstleister, der nicht liefert, aber den Code, das Architekturwissen und womöglich die Anbindung an die Systeme Ihrer Kunden in der Hand hat. Wechseln Sie zu schnell, droht sein Wissen verloren zu gehen. Wechseln Sie zu langsam, verlängern Sie eine Zusammenarbeit, die nicht mehr funktioniert.
Was Sie brauchen
Einen strukturierten Übergang, der das Wissen des bisherigen Dienstleisters sichert, Ihr geistiges Eigentum schützt, die Lieferung während der Übergabe am Laufen hält und den neuen Dienstleister oder Ihr internes Team vom ersten Tag an produktiv macht.
Was Sie sich nicht leisten können
Code, den nur der scheidende Dienstleister versteht. Eine Lieferung, die während des Wechsels wochen- oder monatelang stillsteht. Einen neuen Dienstleister, der Architekturprobleme erst entdeckt, wenn der alte weg ist und niemand mehr Fragen beantworten kann.
Was das Übergangsmanagement liefert
Eine kontrollierte Übergabe: Wissen gesichert und dokumentiert, geistiges Eigentum geschützt, Lieferung aufrechterhalten und das neue Team eingearbeitet, mit einem klaren Bild von Architektur, technischen Schulden und den Risiken, die es übernimmt.
Sichern. Stabilisieren. Übergeben.
Wir steuern den Übergang in drei kontrollierten Phasen. Jede senkt das Risiko von Wissensverlust und hält die Lieferung am Laufen. Das neue Team übernimmt ein dokumentiertes System statt eines undokumentierten Altbestands.
Bestandsaufnahme vor dem Wechsel
Audit des Codes, Prüfung der Architekturdokumentation und Erfassung der Wissenslücken. Wir ermitteln, was der aktuelle Dienstleister weiß, aber nirgends aufgeschrieben ist, und was gesichert werden muss, bevor die Zusammenarbeit endet. Das Inventar von geistigem Eigentum und Zugängen wird vollständig erstellt.
5 bis 10 Werktage · Fester Umfang
Wissen sichern
Strukturierter Wissenstransfer vom scheidenden Dienstleister: Architektur-Walkthroughs, Runbooks für den Betrieb, die Historie der Incidents und die undokumentierten Entscheidungen, die den Code geprägt haben. Die Lieferung läuft in dieser Phase weiter.
2 bis 6 Wochen · Gesteuerte Parallelphase
Einarbeitung des neuen Teams
Der neue Dienstleister oder Ihr internes Team wird mit der Dokumentation aus der vorherigen Phase eingearbeitet: Architekturleitfaden, bekannte technische Schulden, Playbook für den Betrieb und die offenen Fragen, die der vorherige Dienstleister ungeklärt gelassen hat. Der erste Sprint läuft unter unserer Aufsicht.
2 bis 4 Wochen · Abnehmende Beteiligung
Alles, was das neue Team braucht, um ohne Rückfragen beim alten zu starten.
Architekturdokumentation
Ein vollständiger Architekturleitfaden auf Basis des Codes und der Interviews mit dem Dienstleister: Systemdesign, Datenflüsse, Schnittstellen, Deployment-Topologie und die Entscheidungen hinter jedem dieser Punkte.
Register der technischen Schulden
Jede bekannte technische Altlast: Abkürzungen im Code, aufgeschobene bekannte Probleme, Integrationsrisiken und alles, was der vorherige Dienstleister intern gehandhabt, aber nie offengelegt hat. Sortiert nach Auswirkung auf das Geschäft.
Runbook für den Betrieb
Abläufe für Deployments, Konfiguration des Monitorings, Playbook für Incidents und das Betriebswissen, das das aktuelle Team im Kopf hat und das nie aufgeschrieben wurde.
Inventar von geistigem Eigentum und Zugängen
Eine vollständige Aufstellung von geistigem Eigentum, Zugangsdaten, Repository-Zugängen, Konten bei Drittanbietern und Domain-Registrierungen. Dazu eine Checkliste für die Übergabe, die sicherstellt, dass der scheidende Dienstleister nichts zurückbehält.
Was, wenn der aktuelle Dienstleister beim Wechsel nicht mitspielt?
Das kommt vor. Wir steuern den Übergang mit und ohne Mitwirkung des Dienstleisters: Was sich direkt aus dem Code holen lässt, sichern wir selbst, und was das neue Team noch herausfinden muss, dokumentieren wir. Das Inventar von geistigem Eigentum und Zugängen ist fertig, bevor die Zusammenarbeit offiziell endet, ganz gleich, wie kooperativ der Dienstleister ist.
Fallstudien
- Bis zu €220k Umsatzverlust pro Monat durch Lieferprobleme aufgedecktBei einem Softwarekunden lief die Entwicklung, Releases kamen regelmäßig, und die Zusammenarbeit am Produkt war langfristig angelegt. Doch Probleme bei der Lieferung begannen, den wirtschaftlichen Wert dieses Kunden zu gefährden. Kritische Bugs, Releases als Stückwerk und Arbeit ohne Bezug zu Geschäftszielen trieben die Kosten schlechter Qualität immer weiter nach oben. Wir haben einen Business Case erstellt: was die schwache Lieferung kostet und was sich gewinnen lässt, wenn man sie in Ordnung bringt.B2B-SaaS-Unternehmen, Europa
Wirkung:
- Geschätzter Umsatzverlust durch Lieferprobleme: €50k bis €220k pro Monat
- Modellierte mögliche Gesamtwirkung pro Monat: rund €315k
- Aus einer kleinen Effizienzanfrage wurde eine selbstfinanzierende Roadmap über €4,19 Mio.Hinter dem bescheidenen Wunsch, Zeit zu sparen, steckte ein viel größerer struktureller Engpass im Tagesgeschäft. Wir haben die tatsächliche Chance erfasst und eine Roadmap in Phasen aufgebaut, die sich während der Umsetzung selbst bezahlt, statt alles auf eine einzige große Wette zu setzen.Baumanagement-Beratung, Deutschland
Wirkung:
- Modellierter Wert der Roadmap in Phasen: €4,19 Mio.
- Jede Phase finanziert die nächste
- Aus einem Routine-Review wurde ein Business Case für Ausfallsicherheit über €1,05 Mio.Ein deutscher Finanzierungsvermittler mit solidem Tech-Stack und einem schlanken Team von 24 Personen hatte einen systemischen Engpass: Für acht miteinander verbundene Systeme gab es keine getestete Wiederherstellung. Eine einzige WordPress-Datenbank war die maßgebliche Datenquelle für alle acht. Eine überschaubare Prüfung der Umgebung deckte ein modelliertes jährliches Risiko von €508K bis €1,05 Mio. auf. Es war nirgends eingepreist und blieb unsichtbar, bis die Zahlen auf dem Papier standen. Ausfallsicherheit war unbemerkt zum eigentlichen Produkt geworden.Fördermittler für Energieeffizienz, Deutschland
Wirkung:
- Modellierter erwarteter Jahresverlust, beziffert und schrittweise abgebaut: €508K bis €1,05 Mio.
- Geplante Wiederherstellungszeit, vorher ohne getesteten Restore: < 4 Std.
Was Führungskräfte vor der Beauftragung fragen.
Wie steuern Sie den Wechsel eines IT-Dienstleisters?
Ein strukturierter Wechsel umfasst vier Phasen: Wissenssicherung (dokumentieren, was der aktuelle Dienstleister weiß), eine Due Diligence des neuen Dienstleisters, einen Kontinuitätsplan, der Lücken im Produktionssupport verhindert, und ein Übergabeprotokoll, das die Verantwortung überträgt, ohne Architekturentscheidungen zu verlieren. Das größte Risiko ist der Verlust von Wissen, nicht der Zeitplan.
Welche Risiken gibt es, wenn wir den IT-Dienstleister wechseln?
Die wichtigsten Risiken: Wissensverlust (der bisherige Dienstleister versteht das System auf eine Weise, die nirgends dokumentiert ist), Lücken in der Lieferung während des Wechsels, nachlassende Stabilität, während sich der neue Dienstleister in den Code einarbeitet, und vertragliche Risiken, wenn der bisherige Dienstleister ein Druckmittel hat. Ein gut gesteuerter Übergang entschärft jedes davon systematisch.
Wie lange dauert ein Dienstleisterwechsel in der Softwareentwicklung?
Ein typischer Wechsel dauert 60 bis 90 Tage für die formale Übergabe, plus 30 bis 60 Tage Parallelbetrieb, bis klar ist, dass der neue Dienstleister stabil arbeitet. Größere, komplexere Systeme mit schwacher Dokumentation brauchen länger. Der Zeitplan hängt von der Komplexität des Codes, der Qualität der Dokumentation und davon ab, wie schnell sich der neue Dienstleister einarbeitet.
Was gehört in einen Plan für den Dienstleisterwechsel?
Ein Übergangsplan sollte enthalten: ein Protokoll zur Wissenssicherung, einen dokumentierten Ausgangsstand des Systems, einen Kontinuitätsplan für die Übergangszeit, einen Zeitplan für den Parallelbetrieb, Abnahmekriterien für den neuen Dienstleister, ein Risikoregister und einen Kommunikationsplan für die Stakeholder. Der Plan stützt sich auf Belege, nicht auf Annahmen.
Wann sollten wir mit der Planung beginnen, wenn wir den IT-Dienstleister wechseln wollen?
Bevor Sie es dem aktuellen Dienstleister sagen. Die Bestandsaufnahme vor dem Wechsel sollte stattfinden, solange die Zusammenarbeit formal noch besteht. Zugang und Mitwirkung bekommen Sie leichter, bevor der Dienstleister weiß, dass die Zusammenarbeit endet. Wir helfen Ihnen, Reihenfolge und Zeitpunkt dieser Mitteilung zu planen.
Was, wenn wir noch keinen neuen Dienstleister ausgewählt haben?
Die Phase der Wissenssicherung kann beginnen, bevor der neue Dienstleister feststeht. Manchmal verbessert es sogar die Auswahl, wenn Architekturdokumentation und Register der technischen Schulden zuerst fertig sind: Sie können den Kandidaten ein genaues Bild davon geben, was sie übernehmen, und ihre Antworten verraten viel über ihre Fähigkeiten.
Bestandsaufnahme vor dem Wechsel
Fünf bis zehn Werktage. Eine schriftliche Bewertung, was beim aktuellen Dienstleister liegt und was gesichert werden muss, bevor die Zusammenarbeit endet, dazu ein Übergangsplan.
Die Bewertung umfasst
- Audit des Codes: Zustand der Architektur, Lücken in der Dokumentation, undokumentierte Abhängigkeiten
- Erfassung der Wissenslücken: was nur in den Köpfen beim Dienstleister existiert
- Inventar von geistigem Eigentum und Zugängen: Repositories, Zugangsdaten, Konten, Domain-Registrierungen
- Unterstützung bei der Vertragsprüfung: Rechte am geistigen Eigentum, Pflichten bei Kündigung, Übergangsklauseln
- Schriftlicher Übergangsplan mit der Reihenfolge der Wissenssicherung und dem Vorgehen bei der Einarbeitung des neuen Teams
5 bis 10 Werktage · Remote oder vor Ort · Festpreis
Zeigen Sie uns das Projekt, das Ihnen Sorgen macht
Retten Sie das Projekt, bevor aus Lieferproblemen Umsatzprobleme werden.
Ihr Ansprechpartner
Yurii Kotula
CEO und Engineering-Leiter
Das erste Gespräch führen Sie mit Yurii. Schicken Sie das Formular oder wählen Sie direkt einen Termin in seinem Kalender.
Termin mit Yurii buchen