Software-Dienstleister wechseln: Lassen Sie das neue Team die Anwendung einmal wirklich ausliefern

Der bisherige Dienstleister stellt den Quellcode bereit. Das neue Team kann ihn lesen, aber nicht bauen. Eine private Bibliothek fehlt, ein Veröffentlichungsschritt läuft nur auf einem alten Rechner und niemand weiß, welchem Konto die Domain gehört. Formal sind Dateien übergeben worden. Praktisch besteht die Abhängigkeit weiter.

Deutsche Unternehmen sollten eine Softwareübernahme deshalb als überprüfbare Betriebsübergabe beauftragen. Der wichtigste Nachweis ist eine begrenzte Probe: Das neue Team erstellt aus dem vereinbarten Ausgangsstand eine kleine Änderung, prüft sie und liefert sie in eine geeignete Umgebung aus. Dabei werden fehlende Informationen sichtbar, solange der bisherige Ansprechpartner noch verfügbar ist.

Klären Sie zuerst den Gegenstand der Übernahme

Eine Anwendung besteht häufig aus mehreren Repositories, Hintergrunddiensten, Datenbanken und externen Konten. Sammeln Sie diese Bestandteile und ihre Beziehungen. Halten Sie fest, welche Version tatsächlich produktiv läuft und welche Entwicklungsstände daneben existieren.

Ergänzen Sie nichttechnische Abhängigkeiten wie Lizenzen, Dienstverträge und Zuständigkeiten. Ein vorhandener Zugang beweist nicht automatisch, dass ein Konto oder eine Lizenz künftig wie geplant genutzt werden darf. Offene Rechte- und Vertragsfragen müssen von den zuständigen Personen geklärt werden.

Definieren Sie den ersten Übernahmeumfang bewusst. Vielleicht soll zunächst nur die Wartung einer Anwendung übernommen werden, während ein anderes Team die Infrastruktur weiter betreibt. Eine unklare Grenze führt später dazu, dass Störungen zwischen Beteiligten hin- und hergereicht werden.

Prüfen Sie den Weg vom Repository zum Ergebnis

Die GitHub-Dokumentation zur Repository-Übertragung beschreibt den Wechsel der Verwaltung und weist auf mögliche Unterschiede durch Konten und Funktionen hin. Ein Repository-Transfer ist somit ein relevanter Schritt, aber nicht die gesamte technische Übergabe.

Das neue Team benötigt die passenden Laufzeiten, Paketquellen, Konfigurationen und Build-Schritte. Geheimnisse sollten über ein kontrolliertes Verfahren zugänglich gemacht werden, nicht in einer ungeschützten Sammlung von Dateien. Dokumentieren Sie, welche Werte pro Umgebung benötigt werden und welche Dienste sie verwenden.

Lassen Sie den Build in einer frischen geeigneten Umgebung ausführen. Ein Erfolg auf einem langjährig verwendeten Entwicklerrechner kann auf nicht dokumentierten Voraussetzungen beruhen. Die Probe soll gerade diese versteckten Abhängigkeiten aufdecken.

Verbinden Sie die laufende Version mit ihrem Ursprung

Das übergebene Repository sollte nachvollziehbar zu den ausgelieferten Dateien oder Images passen. Andernfalls weiß das neue Team nicht sicher, ob es die tatsächlich verwendete Anwendung untersucht. Halten Sie Commit, Build-Konfiguration und Ergebnis zusammen fest.

Die SLSA-Spezifikation zur Build-Herkunft beschreibt Informationen darüber, wo, wann und wie ein Softwareartefakt erzeugt wurde. Für die Übernahme ist dieses Prinzip hilfreich: Die Herkunft eines Ergebnisses soll nachvollziehbar sein. Daraus entsteht nicht automatisch eine bestimmte Sicherheitsstufe oder Zertifizierung.

Bei einem fiktiven Kundenportal wurde ein Fehler kurzfristig auf dem Server korrigiert, ohne die Änderung in den normalen Entwicklungsweg zurückzuführen. Eine bloße Repository-Übergabe würde diese Abweichung übersehen. Die Bestandsaufnahme muss deshalb bekannte manuelle Eingriffe und Unterschiede zwischen Umgebung und Quellcode berücksichtigen.

Nehmen Sie Daten und Wiederherstellung in die Probe auf

Eine laufende Oberfläche ohne passende Daten beweist wenig. Das neue Team braucht ein Verfahren, um eine geeignete Testumgebung mit zulässigen Daten aufzubauen. Es muss verstehen, welche Migrationen nötig sind und welche Hintergrundprozesse dabei ausgelöst werden.

Verhindern Sie, dass eine kopierte Umgebung versehentlich echte Kunden benachrichtigt oder produktive Schnittstellen anspricht. Trennen Sie Testkonten, E-Mail-Ausgabe und externe Aktionen ausdrücklich. Diese Grenze gehört zur Vorbereitung der Übernahmeprobe.

Prüfen Sie auch, ob Sicherungen tatsächlich wiederhergestellt werden können. Klären Sie die zuständigen Personen, Speicherorte und benötigten Schlüssel. Eine Sicherungsdatei, deren Entschlüsselung nur über ein persönliches Konto des früheren Dienstleisters möglich ist, bleibt eine operative Abhängigkeit.

Wählen Sie eine kleine Änderung mit echtem Auslieferungsweg

Die Probe sollte überschaubar, aber aussagekräftig sein. Eine kleine fachliche Korrektur kann genügen, wenn sie die relevanten Prüfungen, das Review und den vorgesehenen Veröffentlichungsweg durchläuft. Ein lediglich lokal geänderter Text zeigt dagegen nicht, ob die Auslieferung beherrscht wird.

Lassen Sie das neue Team erklären, welche Tests die Änderung absichern und wie ein Problem nach der Veröffentlichung erkannt würde. Eine Rücknahme oder alternative Wiederherstellung sollte im passenden Umfang ebenfalls beschrieben und geübt werden.

Dokumentieren Sie alle Punkte, bei denen Unterstützung des bisherigen Teams nötig war. Daraus entsteht eine konkrete Restliste: fehlende Konfiguration, unklare Geschäftsregel, nicht übertragener Zugang oder undokumentierter manueller Schritt. Diese Liste ist wesentlich hilfreicher als eine pauschale Aussage, die Dokumentation sei unvollständig.

Übergeben Sie Verantwortung mit einem klaren Zeitpunkt

Nach der technischen Probe müssen Support und Entscheidungswege geregelt werden. Wer reagiert auf Störungen, wer genehmigt Änderungen und wer verwaltet die externen Konten? Mitarbeiter im Unternehmen sollten wissen, welchen Ansprechpartner sie nach dem Wechsel nutzen.

Planen Sie den Entzug alter Zugänge nach Rollen und Abhängigkeiten. Persönliche Konten, technische Konten, Schlüssel und Integrationsberechtigungen sind unterschiedlich zu behandeln. Ein unkoordinierter Entzug kann die Anwendung unterbrechen; ein nie abgeschlossener Entzug lässt unnötige Zugriffe bestehen.

Prüfen Sie das Ergebnis tatsächlich. Kann das neue Team eine notwendige Aufgabe ohne fremde Unterstützung ausführen? Sind vereinbarte alte Zugriffe gesperrt? Sind offene Punkte einem Verantwortlichen und einem nächsten Schritt zugeordnet? Erst diese Nachweise machen die Übergabe belastbar.

Nutzen Sie die Übernahme als begrenzte Entscheidungsgrundlage

Eine Bestandsaufnahme kann Modernisierungsbedarf zeigen, rechtfertigt aber nicht automatisch einen vollständigen Neubau. Trennen Sie akute Betriebsprobleme von späteren Verbesserungen. Das Unternehmen braucht zuerst Klarheit darüber, wie die bestehende Anwendung zuverlässig weitergeführt wird.

Unsere Beiträge zu vertrauenswürdigen CI/CD-Pipelines und wiederherstellbaren Backups ergänzen die Vorbereitung. Innovation T unterstützt mit Softwareentwicklung und Cloud-Betrieb. Besprechen Sie Ihre Softwareübernahme mit dem heutigen Auslieferungsweg und den Abhängigkeiten, die Ihr eigenes Team noch nicht kontrolliert.

Häufige Fragen

Reicht der Quellcode für einen Dienstleisterwechsel?

Nein. Zusätzlich werden unter anderem passende Zugänge, Build-Konfiguration, Abhängigkeiten, Datenverfahren und Betriebswissen benötigt. Eine praktische Probe zeigt, ob diese Bestandteile zusammen funktionieren.

Muss das neue Team sofort Produktion verändern?

Nein. Beginnen Sie in einer geeigneten isolierten Umgebung mit einer kleinen nachvollziehbaren Änderung. Der Produktivwechsel folgt erst auf die vereinbarten Prüfungen und eine klare Verantwortungsübergabe.

Wann sollten alte Zugänge entzogen werden?

Nach einem abgestimmten Übergabeplan, der benötigte technische Konten und laufende Aufgaben berücksichtigt. Prüfen Sie anschließend den tatsächlichen Entzug, statt nur eine Kontenliste abzuhaken.