Individuelle Software übernehmen: Checkliste für den Wechsel

Wer individuelle Software übernehmen will, sollte nicht mit einem Serverumzug beginnen, sondern zuerst Kontrolle und Betriebsfähigkeit klären. Entscheidend sind ein vollständiger Zugang zu Code, Infrastruktur, Daten und Drittanbieter-Konten sowie ein nachvollziehbarer Weg, die Anwendung zu bauen, zu testen und zu betreiben. Fehlen diese Grundlagen, wird ein Agenturwechsel schnell zu einem schwer kalkulierbaren Rettungsprojekt statt zu einer geordneten Übergabe.

Wann eine Übernahme sinnvoll ist

Eine Übernahme ist sinnvoll, wenn die Anwendung einen wichtigen Prozess abbildet, aber die Zusammenarbeit mit dem bisherigen Dienstleister endet oder sich verändern soll. Das betrifft etwa Kundenportale, interne Auftrags- und Rechnungsprozesse, Integrationen zwischen Fachsystemen oder branchenspezifische Anwendungen, die sich nicht ohne Weiteres durch Standardsoftware ersetzen lassen.

Auch ohne akuten Konflikt kann es vernünftig sein, die Handlungsfähigkeit früh zu sichern. Abhängigkeit entsteht nicht nur durch fehlenden Quellcode. Sie entsteht ebenso, wenn nur eine Person Zugang zum Hosting hat, Passwörter in privaten Accounts liegen, Hintergrundjobs und Schnittstellen nicht dokumentiert sind oder niemand außerhalb des bisherigen Teams weiß, wie eine Störung eingegrenzt wird.

Nicht jede alte Anwendung sollte jedoch unverändert übernommen werden. Wenn zentrale Funktionen instabil sind, das technische Fundament nicht mehr zu den Anforderungen passt oder der Geschäftsprozess inzwischen anders funktioniert, kann eine begrenzte Stabilisierung mit anschließender Modernisierung die bessere Entscheidung sein. Die Übernahmeprüfung schafft genau diese Entscheidungsgrundlage: Sie trennt übertragbare Substanz von technischem und fachlichem Ballast.

Was bei einer Softwareübernahme tatsächlich übergeben werden muss

Ein Git-Repository allein reicht nicht aus. Eine Anwendung besteht aus mehreren Bausteinen, die zusammen betrieben werden müssen. Fehlt einer davon, ist der Code möglicherweise zwar vorhanden, aber nicht reproduzierbar lauffähig. Deshalb sollte die Übergabe als Paket geplant werden, nicht als einzelne Dateiablage.

• Quellcode einschließlich Versionshistorie, Abhängigkeiten, Build-Konfiguration und Informationen zu verwendeten Komponenten.
• Produktions-, Test- und Entwicklungsumgebungen einschließlich Hosting-Zugängen, Domains, DNS, E-Mail-Versand und verschlüsselter Sicherungen.
• Datenbankstruktur, Migrationsskripte, Import- und Exportprozesse sowie ein geklärter Zugang zu den betrieblich benötigten Daten.
• Konfiguration von Hintergrundjobs, Warteschlangen, Cronjobs, Webhooks, Schnittstellen und Fehlerbenachrichtigungen.
• Zugänge zu externen Diensten, etwa Zahlungs-, Versand-, Signatur-, Analyse- oder Kommunikationsdiensten. Konten sollten, soweit möglich, dem Unternehmen zugeordnet sein.
• Technische Betriebsdokumentation: Start der Anwendung, Deployment, Wiederherstellung, Monitoring, bekannte Risiken und Ansprechpartner.
• Fachliches Wissen zu Rollen, Freigaben, Sonderfällen und Prozessregeln, die nicht zuverlässig aus dem Code hervorgehen.
• Verträge und Vereinbarungen zu Nutzungsrechten, Lizenzen, Wartung sowie zur Verarbeitung personenbezogener Daten. Diese Punkte sollten bei Unklarheiten rechtlich geprüft werden.

Die technische Due Diligence vor dem Wechsel

Vor der Übergabe sollte ein unabhängiger technischer Überblick entstehen. Das ist keine Suche nach formaler Perfektion. Ziel ist eine ehrliche Antwort auf drei Fragen: Kann ein neues Team die Anwendung lokal oder in einer isolierten Umgebung starten? Kann es Änderungen kontrolliert ausliefern? Kann es einen Fehler im Betrieb nachvollziehen und zurückrollen?

Dafür wird zunächst die Architektur grob kartiert: Frontend, Backend, Datenbank, Dateien, externe APIs und asynchrone Prozesse. Danach werden die Lieferwege geprüft. Es sollte nachvollziehbar sein, welche Änderung in welcher Version produktiv ist und wie eine vorherige Version wiederhergestellt werden kann. Besonders kritisch sind manuelle Änderungen direkt auf Produktionsservern, nicht versionierte Konfigurationen und Zugangsdaten, die im Code oder in einzelnen Benutzerkonten hinterlegt sind.

Bei Anwendungen mit personenbezogenen Daten gehört auch der Betrieb in den Blick. Relevante Fragen sind: Wo liegen Daten und Sicherungen? Welche Personen und Systeme können darauf zugreifen? Wie werden Berechtigungen geändert, wenn Mitarbeitende oder Dienstleister wechseln? Die technische Analyse ersetzt keine Datenschutz- oder Rechtsberatung. Sie liefert aber die Informationen, die für organisatorische und rechtliche Entscheidungen benötigt werden.

Praxisbeispiel: Rechnungsprogramm ohne dokumentierten Betrieb

Ein internes Rechnungsprogramm erzeugt PDF-Rechnungen, versendet sie per E-Mail und verwaltet Artikel- sowie Kundendaten. Der bisherige Dienstleister stellt den Quellcode bereit. Bei der Prüfung zeigt sich jedoch, dass der PDF-Dienst nur über eine besondere Serverkonfiguration funktioniert, der E-Mail-Versand über ein Konto des Dienstleisters läuft und nächtliche Sicherungen außerhalb der Anwendung eingerichtet wurden.

Eine vorschnelle Migration würde hier unnötige Ausfallrisiken schaffen. Sinnvoller ist ein Übergabeplan in Etappen: Zuerst werden Zugänge und Eigentümerkonten geklärt. Anschließend wird eine Testumgebung aufgebaut und die Anwendung dort mit anonymisierten oder geeigneten Testdaten gestartet. Dann werden E-Mail-Versand, PDF-Erstellung, Sicherung und Wiederherstellung einzeln überprüft. Erst wenn diese Betriebsfunktionen nachvollziehbar sind, folgt der Wechsel der Produktivumgebung. So wird aus implizitem Wissen ein übernehmbarer Betrieb.

Ein kontrollierter Ablauf in sechs Schritten

1. Zielbild festlegen: Soll die Anwendung zunächst nur stabil weiterlaufen, gezielt weiterentwickelt oder mittelfristig abgelöst werden? Dieses Ziel bestimmt Umfang und Prioritäten der Prüfung.
2. Übergabepaket anfordern: Erstellen Sie eine schriftliche Liste der benötigten Repositories, Konten, Dokumente, Datenflüsse und Zugänge. Benennen Sie für jeden Punkt einen Verantwortlichen und einen Termin.
3. Bestandsaufnahme durchführen: Ein technisches Team bewertet Architektur, Abhängigkeiten, Lieferweg, Sicherheitsrisiken und fehlende Informationen. Offene Punkte werden nach Betriebsrisiko priorisiert.
4. Zugänge in Unternehmensverantwortung überführen: Legen Sie Rollen statt gemeinsamer Passwörter an. Ändern Sie Zugänge erst nach abgestimmter Übergabe, damit der laufende Betrieb nicht unterbrochen wird.
5. Wiederherstellbarkeit praktisch testen: Testen Sie Deployment, Rücknahme einer Version, Sicherung und Wiederherstellung in einer geeigneten Umgebung. Ein Dokument ohne Test ist kein belastbarer Notfallplan.
6. Übergang absichern: Vereinbaren Sie bei Bedarf eine begrenzte Begleitung für Rückfragen. Planen Sie erst danach größere Umbauten oder neue Funktionen.

Typische Fehler und wie sie sich vermeiden lassen

Der häufigste Fehler ist, die Übernahme als reinen Hosting-Wechsel zu behandeln. Damit bleiben oft externe Dienste, Hintergrundverarbeitung und fachliche Sonderregeln unsichtbar. Ebenso problematisch ist es, sofort aufzuräumen: Ein großes Refactoring während der Übergabe erschwert die Ursachenanalyse, falls Probleme auftreten. Erst Stabilität und Transparenz, dann Modernisierung.

Ein weiterer Fehler ist ein unklarer Verantwortungswechsel. Wenn nicht feststeht, wer Störungen annimmt, wer deployen darf und wer Zugänge verwaltet, entstehen im Ernstfall Wartezeiten und Sicherheitsrisiken. Hilfreich ist eine kurze Betriebsvereinbarung mit Ansprechpartnern, Reaktionswegen und einem klaren Verfahren für Änderungen.

Woran Sie eine übernahmefähige Anwendung erkennen

Eine übernahmefähige Anwendung muss nicht makellos sein. Sie ist übernahmefähig, wenn ein neues Team ihren Aufbau verstehen, sie reproduzierbar bereitstellen und ihren Betrieb ohne einzelne Personen absichern kann. Bekannte Schwächen sind dabei akzeptabel, sofern sie dokumentiert, priorisiert und nicht mit dem laufenden Betrieb verwechselt werden.

Für Mittelständler ist das vor allem eine Frage der unternehmerischen Handlungsfähigkeit. Code-Eigentum und offene, wartbare Technik sind wertvoll, aber sie entfalten ihren Nutzen erst mit geordneten Zugängen, dokumentierten Abläufen und einer realistischen Roadmap. Bei komplexeren Anwendungen kann eine technische Übernahmeprüfung vor der Beauftragung eines neuen Entwicklungspartners helfen, Umfang, Risiken und sinnvolle nächste Schritte sauber festzulegen.