Softwareanbieter wechseln: So gelingt die Übergabe einer bestehenden Anwendung

Ein Softwareanbieterwechsel beginnt häufig mit einem fachlichen Problem: Weiterentwicklungen dauern zu lange, Kommunikation funktioniert nicht mehr, der bisherige Entwickler ist nicht verfügbar oder das Unternehmen möchte technisch neue Wege gehen.

Die eigentliche Herausforderung ist jedoch selten die Auswahl des neuen Dienstleisters. Sie liegt in der sauberen Übergabe des bestehenden Systems.

Das wichtigste Ziel eines Anbieterwechsels ist zunächst nicht Veränderung, sondern Kontrolle: Das Unternehmen muss Zugriff auf seine Software, Daten und Betriebsgrundlagen behalten.

Warum ein Anbieterwechsel bei Software anders ist als bei vielen anderen Dienstleistungen

Bei einer laufenden Anwendung hängen zahlreiche technische Bestandteile zusammen:

• Quellcode
• Versionsverwaltung
• Datenbank
• Server und Cloud-Accounts
• Domains und DNS
• Deployment
• API-Zugänge
• Secrets
• Backups
• Drittanbieter-Lizenzen
• Dokumentation und Fachwissen

Wenn diese Bestandteile auf verschiedene Accounts verteilt sind oder ausschließlich vom alten Dienstleister kontrolliert werden, entsteht Abhängigkeit.

Vor der Kündigung: Erst inventarisieren

Ein häufiger Fehler ist, einen Anbieterwechsel organisatorisch zu starten, bevor klar ist, welche technischen Assets überhaupt übergeben werden müssen.

• Welche Anwendungen gehören zum Projekt?
• Wo liegt der Quellcode?
• Wer besitzt die Repository-Organisation?
• Wo läuft Produktion?
• Gibt es Staging?
• Wo liegt die Datenbank?
• Welche Domains und DNS-Zonen werden verwendet?
• Welche Drittanbieter sind angebunden?
• Welche Accounts laufen auf den Namen des Dienstleisters?

Diese Übersicht bestimmt anschließend, was tatsächlich übertragen werden muss.

1. Quellcode und Repository sichern

Der neue Anbieter benötigt einen vollständigen und aktuellen Quellcode-Stand. Optimal ist nicht nur ein Export, sondern der kontrollierte Zugriff auf das eigentliche Repository.

• Commit-Historie
• Branches
• Tags und Releases
• Issues
• Pull Requests
• teilweise Webhooks und Deployment-Konfigurationen

GitHub dokumentiert für Repository-Transfers ausdrücklich, dass neben den eigentlichen Dateien weitere Projektinformationen und Einstellungen relevant sein können.

2. Eigentum an Accounts klären

Idealerweise gehören zentrale Infrastruktur-Accounts dem Unternehmen und der Dienstleister erhält lediglich die notwendigen Berechtigungen.

• Domain-Registrar
• Cloud-Account
• Hosting
• Repository-Organisation
• Monitoring
• E-Mail-Dienste
• Payment Provider
• Analytics
• API-Anbieter

Liegt ein Account beim bisherigen Anbieter, sollte geklärt werden, ob er übertragen werden kann oder neu eingerichtet werden muss.

3. Datenbank und Backups sichern

Vor jeder größeren Übergabe sollte ein aktueller Datenbestand verfügbar sein. Ebenso wichtig ist zu wissen, wie dieser wiederhergestellt werden kann.

• aktuelles Backup
• Backup-Historie
• Restore-Anleitung
• Datenbankversion
• Migrationen
• Verschlüsselung
• Zugriffsrechte

4. Secrets und Zugangsdaten kontrolliert übergeben

API Tokens, SSH Keys, Datenbankpasswörter und Zertifikate sollten nicht unkontrolliert per E-Mail weitergereicht werden.

OWASP empfiehlt eine zentrale Verwaltung und kontrollierte Rotation von Secrets. Nach einem Dienstleisterwechsel sollte bewertet werden, welche Zugangsdaten geändert werden müssen und welche alten Berechtigungen entzogen werden können.

5. Deployment verstehen, bevor etwas verändert wird

Der neue Anbieter sollte mindestens einmal nachvollziehen können, wie eine Version vom Repository in Produktion gelangt.

• Build-Prozess
• CI/CD
• Staging
• Freigaben
• Datenbankmigrationen
• Rollback
• Logs und Monitoring

Erst wenn dieser Weg beherrscht wird, sollte produktiver Code verändert werden.

6. Abhängigkeiten und externe Komponenten prüfen

Nicht jede Komponente einer Anwendung gehört dem Unternehmen. Open-Source-Pakete, kommerzielle Libraries, Themes, Plugins und SaaS-Dienste können eigene Lizenz- oder Accountbedingungen besitzen.

OWASP empfiehlt ein vollständiges Inventar direkter und indirekter Softwarekomponenten. Für einen Dienstleisterwechsel ist das praktisch, weil sichtbar wird, welche externen Bestandteile weiter betrieben werden müssen.

7. Wissen vom alten Anbieter aktiv sichern

Die wertvollste Übergabe ist oft kein Dokument, sondern ein strukturiertes Gespräch mit dem bisherigen Entwickler.

• Welche Bereiche sind besonders empfindlich?
• Welche technischen Schulden sind bekannt?
• Welche Jobs laufen zeitgesteuert?
• Welche manuellen Schritte gehören zu Releases?
• Welche Funktionen sind fachlich ungewöhnlich?
• Welche Fehler treten wiederkehrend auf?
• Welche Abhängigkeiten sollten nicht ohne Prüfung aktualisiert werden?

Dieses Wissen spart dem neuen Team später Reverse Engineering.

8. Verträge und Rechte rechtzeitig prüfen

Unternehmen sollten vor einem Wechsel wissen, welche Nutzungs-, Bearbeitungs- und Herausgaberechte für die Software vereinbart wurden. Das betrifft insbesondere individuell entwickelten Code und kommerzielle Drittkomponenten.

Die technische Übergabe ersetzt keine rechtliche Prüfung. Wenn Eigentums- oder Nutzungsrechte unklar sind, sollte das fachkundig geklärt werden, bevor ein neuer Anbieter Änderungen vornimmt.

9. Einen Übergabezeitraum einplanen

Der sicherste Wechsel ist selten ein harter Stichtag.

Ein kleines erstes Deployment ist besonders wertvoll. Es zeigt, ob der neue Dienstleister den vollständigen technischen Weg beherrscht, bevor eine größere Funktion umgesetzt wird.

10. Nicht sofort alles umbauen

Ein Anbieterwechsel ist bereits eine Veränderung. Gleichzeitig Architektur, Hosting, Framework, Datenbank und Fachlogik umzubauen, erhöht das Risiko unnötig.

übernehmen → stabil verstehen → priorisieren → gezielt modernisieren.

Erst wenn die Anwendung kontrolliert betrieben werden kann, sollte entschieden werden, welche technischen Veränderungen tatsächlich notwendig sind.

Checkliste für den Softwareanbieterwechsel

• aktueller Quellcode und Repository-Zugang vorhanden
• Repository-Eigentum geklärt
• Produktiv- und Staging-Umgebung dokumentiert
• Datenbankzugang vorhanden
• aktuelles Backup verfügbar
• Restore-Prozess bekannt
• Domains und DNS geklärt
• Cloud- und Hosting-Accounts geklärt
• API- und Drittanbieter-Accounts inventarisiert
• Secrets und Keys kontrolliert verwaltet
• Deployment-Prozess nachvollziehbar
• Dependencies und Lizenzen geprüft
• technische Dokumentation übernommen
• bekannte Bugs und technische Schulden erfasst
• alte Zugänge nach Übergabe entzogen

Fazit

Ein Softwareanbieterwechsel funktioniert dann gut, wenn der Übergang als eigenes technisches Projekt behandelt wird.

Quellcode allein reicht nicht. Erst wenn Repository, Daten, Infrastruktur, Zugänge, Secrets, Deployment und fachliches Wissen kontrolliert übergeben wurden, besitzt das Unternehmen eine belastbare Grundlage für die nächste Entwicklungsphase.