Die meisten Ratgeber handeln davon, wie man einen Softwarepartner auswählt. Nur wenige davon, wie man sich von einem trennt, obwohl das oft die schwierigere Entscheidung ist. Das System läuft bereits produktiv, Menschen arbeiten jeden Tag damit, und das einzige Team, das es vollständig versteht, ist genau das, bei dem Sie sich nicht mehr sicher sind. Wir übernehmen solche Projekte regelmäßig, und die gut verlaufenen haben eines gemeinsam: Der Auftraggeber hat den Ausstieg geplant, bevor er ihn angekündigt hat.
Anzeichen, dass es Zeit für einen Partnerwechsel ist
Jede Zusammenarbeit hat einen schlechten Monat. Entscheidend ist, ob Probleme erklärt und behoben oder einfach wiederholt werden. Diese Muster bedeuten, wenn sie über zwei oder drei Quartale anhalten, meist, dass sich die Beziehung nicht mehr erholt:
Verpasste Termine ohne Begründung. Eine Verzögerung mit klarer Ursache und neuem Plan ist normal. Verzögerungen, die als Überraschung kommen, ohne dass sich an der Steuerung der Arbeit etwas ändert, sind ein Managementproblem, das der Dienstleister nicht löst.
Nur der Dienstleister kann deployen. Wenn für das Ausrollen einer Änderung eine bestimmte Person beim Dienstleister nötig ist, gehört Ihnen Ihr System nicht vollständig - und je länger das so bleibt, desto teurer wird der Ausstieg.
Jede Änderung kostet mehr als die letzte. Steigende Schätzungen für vergleichbare Arbeit sind das deutlichste Zeichen für eine Codebasis, die sich immer schwerer ändern lässt, und für ein Team, das diese Schulden nicht abbaut.
Das Team wechselt ständig. Jedes Quartal neue Gesichter und keine Dokumentation bedeuten, dass mit jeder Person Wissen das Haus verlässt. Fragen Sie, wer aus dem ersten Monat noch an Ihrem Projekt arbeitet.
Treffen zwei oder mehr davon zu, wenden Sie die Checkliste zur Wahl eines Software-Entwicklungspartners auf Ihren jetzigen Dienstleister an, als würden Sie ihn zum ersten Mal treffen. Manchmal lösen ein ehrliches Gespräch und eine veränderte Aufstellung das Problem. Oft bestätigt sich, was Sie ohnehin vermutet haben.
Was Sie sichern sollten, bevor Sie es jemandem sagen
Die Reihenfolge zählt mehr als der neue Dienstleister. Bevor Sie den Wechsel ankündigen - sogar bevor Sie ernsthafte Gespräche mit einem Nachfolger führen -, stellen Sie sicher, dass Ihr Unternehmen Folgendes in der Hand hat, auf eigenen Namen:
- Admin-Zugriff auf jedes Code-Repository, auch auf die, die nur die CI des Dienstleisters nutzt
- Eigentum an Cloud-Konten, Domains, DNS und App-Store-Einträgen - auf den Namen Ihres Unternehmens
- Alle Secrets und Zugangsdaten: API-Schlüssel, Datenbankpasswörter, Signaturzertifikate, Logins bei Drittanbietern
- Datenbank-Backups, die Sie mindestens einmal selbst wiederhergestellt haben
- Jede vorhandene Dokumentation - Architekturnotizen, Runbooks, Deployment-Schritte, so dünn sie auch sein mag
- Eine Liste aller Drittanbieterdienste, von denen das System abhängt, und wer sie bezahlt
Das meiste davon sollte Ihnen laut Vertrag ohnehin gehören. Prüfen Sie die Vereinbarung auf Klauseln zu geistigem Eigentum, Übergabepflichten und Kündigungsfristen, und bleiben Sie im Ton professionell: Sie brauchen die Mitarbeit des scheidenden Teams noch Wochen nach der Entscheidung.
Der günstigste Moment, sich den Zugriff auf das eigene System zu sichern, ist, bevor irgendjemand weiß, dass Sie gehen.
Ein Plan für die gestaffelte Übergabe
Der riskanteste Weg, den Partner zu wechseln, ist ein einziger Stichtag für die Umstellung. Eine gestaffelte Übergabe hält das System am Laufen und gibt dem neuen Team Zeit, es kennenzulernen, solange das alte Team noch Fragen beantworten kann.
Woche 1-2: Zuschauen. Das neue Team liest den Code, richtet eigene Umgebungen ein und schaut dem scheidenden Team bei Deployments und bei der Behebung von Störungen über die Schulter. Ziel ist eine schriftliche Landkarte des Systems: Komponenten, Datenflüsse, Integrationen und die Teile, die niemand versteht.
Woche 3-4: Änderungen unter Aufsicht. Das neue Team nimmt kleine, echte Änderungen vor und rollt sie aus, das alte Team prüft. Jetzt zeigen sich fehlende Dokumentation und fragile Build-Schritte - besser jetzt als während eines Ausfalls.
Woche 5-8: Verantwortung nach Bereichen. Die Verantwortung wandert Bereich für Bereich - zuerst die Teile mit der besten Testabdeckung, zuletzt die mit dem größten Risiko. Der scheidende Dienstleister bleibt erreichbar, idealerweise über einen kleinen Retainer, bis der letzte Bereich übergeben ist.
Widerstehen Sie dem Drang, alles neu zu schreiben, sobald das neue Team da ist. Ein neuer Partner, der den kompletten Neuaufbau vorschlägt, bevor er das System versteht, wiederholt genau den Fehler, dem Sie entkommen wollen. Erst stabilisieren, dann Modul für Modul verbessern - so, wie wir es in Altsysteme modernisieren, ohne alles neu zu schreiben beschreiben.
Den nächsten Partner wählen
Die zweite Wahl sollte strenger ausfallen als die erste. Fragen Sie den Kandidaten, wie er Systeme schon früher übernommen hat, und lassen Sie sich einen geschwärzten Übergabeplan aus einem echten Projekt zeigen. Vereinbaren Sie eine Abrechnung nach Meilensteinen statt eines offenen Stundenvertrags, und machen Sie Dokumentation zum Liefergegenstand statt zum Gefallen. Vor allem aber: Prüfen Sie, ob es leicht wäre, sich auch vom neuen Partner wieder zu trennen - denn der beste Schutz davor, diesen Beitrag je wieder lesen zu müssen, ist eine Zusammenarbeit, die Sie günstig beenden könnten.
Häufige Fragen
Wann sollte ich meinen Software-Entwicklungspartner wechseln?
Wenn Probleme nicht mehr erklärt, sondern nur noch wiederholt werden: verpasste Termine ohne Begründung, ein System, das nur der Dienstleister deployen kann, steigende Kosten pro Änderung und ständige Wechsel im Team. Ein schlechter Monat ist normal; ein Muster über zwei oder drei Quartale ist ein Signal.
Wie wechsle ich den Softwaredienstleister, ohne mein Projekt zu verlieren?
Sichern Sie Code, Infrastruktur, Zugangsdaten und Backups, bevor Sie den Wechsel ankündigen, und übergeben Sie dann in Stufen: Das neue Team schaut zunächst zu, deployt dann unter Aufsicht und übernimmt schließlich Bereich für Bereich die Verantwortung, während der bisherige Dienstleister noch erreichbar ist.
Wie lange dauert eine Softwareübergabe?
Bei einem typischen Geschäftssystem vier bis acht Wochen Überlappung zwischen altem und neuem Team. Systeme ohne Dokumentation oder ohne Tests dauern länger, weil das neue Team dieses Wissen erst wieder aufbauen muss.
Muss ich die Software beim Partnerwechsel neu schreiben?
Als ersten Schritt fast nie. Ein neuer Partner sollte das System zuerst stabilisieren und verstehen, bevor er Änderungen vorschlägt. Ersetzen Sie Teile nur dort, wo es einen klaren Grund gibt, ein Modul nach dem anderen.