Ein Wechsel des Dienstleisters scheitert fast nie am Programmcode. Er scheitert daran, dass niemand das Passwort für den Server hat, dass die Domain auf eine Agentur läuft, die es nicht mehr gibt, oder dass eine Anwendung von einem Dienst abhängt, dessen Rechnung bisher jemand anderes bezahlt hat.
Deshalb ist die nützlichste Vorbereitung kein Anwaltsschreiben, sondern eine Liste. Was gehört Ihnen, und was liegt nur bei Ihnen?
Sechs Posten, die den Besitzer wechseln
Der Quellcode, mit vollständiger Historie. Ein Archiv vom Stichtag genügt nicht. Die Historie erzählt, warum eine Stelle so aussieht, wie sie aussieht, und ist bei der Einarbeitung mehr wert als jede Dokumentation. Lassen Sie sich das Repository übertragen, nicht ein Abbild davon.
Die Zugangsdaten. Server, Datenbank, Domain, Zertifikate, Mailversand, Zahlungsanbieter, Fehlerüberwachung. Hier klemmt es am häufigsten, weil solche Konten über Jahre auf persönliche Adressen beim Dienstleister angelegt wurden. Prüfen Sie das, bevor Sie kündigen, nicht danach.
Der Weg nach draußen. Wie kommt eine Änderung auf den Server? Wenn die Antwort ein Skript auf dem Rechner eines einzelnen Entwicklers ist, geht dieses Wissen mit ihm. Der Auslieferungsweg gehört ins Repository, damit er übertragbar ist.
Die Abhängigkeiten mit Rechnung. Bezahlte Bibliotheken, Kartendienste, SMS-Versand, Lizenzschlüssel. Jede dieser Positionen hat einen Vertrag und einen Zahler. Steht dort der alte Dienstleister, hört sie irgendwann auf zu funktionieren, und zwar ohne Vorwarnung.
Die Daten in lesbarer Form. Ein Datenbankabzug im Format der Datenbank ist gut. Ein zusätzlicher Export der wichtigsten Bestände in einem Format, das sich ohne Spezialwerkzeug öffnen lässt, ist besser. Er ist Ihr Rückweg, falls die Übernahme länger dauert als geplant.
Das Wissen, das nirgends steht. Welcher nächtliche Lauf darf nicht ausfallen. Warum ein bestimmter Kunde eine Sonderbehandlung hat. Welche Stelle im Code man besser nicht anfasst. Eine Stunde Gespräch dazu ist mehr wert als hundert Seiten Dokumentation.
Wie eine Übernahme abläuft
Sinnvoll ist eine Reihenfolge, die früh Sicherheit schafft und spät erst Verantwortung überträgt.
Zuerst die Bestandsaufnahme: Was ist da, was fehlt, wie ist der Zustand. Das dauert wenige Tage und ist auch dann nützlich, wenn Sie sich danach gegen den Wechsel entscheiden.
Dann die Zugänge einsammeln und auf Konten Ihres Unternehmens umstellen. Erst danach die Kündigung, weil ein gekündigter Vertrag die Bereitschaft zur Mitarbeit selten erhöht.
Anschließend eine kleine, echte Änderung durch das neue Team, vollständig bis auf den Server. Das ist die eigentliche Probe. Sie zeigt, ob der Auslieferungsweg vollständig übergeben wurde, und sie kostet fast nichts.
Zum Schluss die laufende Betreuung, und zwar mit einer Liste dessen, was das neue Team in den ersten Wochen aufräumt. Diese Liste sollte aus der Bestandsaufnahme stammen und nicht aus dem Bauch.
Damit es beim nächsten Mal leichter geht
Die drei Punkte, die einen späteren Wechsel entschärfen, kosten am Anfang fast nichts.
Alle Konten laufen auf Adressen Ihres Unternehmens, nicht auf die des Dienstleisters. Das Repository liegt bei Ihnen, und der Dienstleister bekommt Zugriff darauf. Und im Vertrag steht, was bei Vertragsende herausgegeben wird, in welchem Format und innerhalb welcher Frist.
Ein Anbieter, der das mitträgt, ist nebenbei ein gutes Zeichen. Wer eine Übergabe von vornherein einplant, baut anders, weil er damit rechnet, dass jemand anderes den Code lesen wird.
Ob ein Wechsel überhaupt nötig ist, lässt sich vorher prüfen. Ein Software-Audit sagt Ihnen, ob die Anwendung in einem Zustand ist, der die Mühe lohnt. Manchmal ist das Ergebnis, dass nicht der Dienstleister das Problem ist, sondern eine Zusammenarbeit, die sich reparieren lässt. Wie eine Übernahme in den laufenden Betrieb übergeht, steht unter Wartung und Support.
