Softwareprojekt übernehmen: 30-Tage-Plan für den Anbieterwechsel

Eine Softwareprojekt-Übernahme ist der kontrollierte Wechsel der technischen und operativen Verantwortung für ein laufendes Produkt zu einem neuen Team. Sie ist erst abgeschlossen, wenn das neue Team das System ohne den bisherigen Anbieter bauen, deployen, beobachten, zurückrollen und wiederherstellen kann. Ein übertragenes Repository ist ein Input, aber kein Abnahmetest.

Dieser Guide beantwortet die Übergangsfrage: Was musst du vor, während und nach einem Softwareanbieterwechsel tun? Nutze die Software-Übergabe-Checkliste für die vollständige Artefaktliste, den Guide zur Auswahl einer Softwareagentur für die breitere Einkaufsentscheidung und Wavects Software-Übernahme-Service, wenn ein Team das Assessment und die Codebase übernehmen soll.

Solltest du den Softwareanbieter wechseln?

Wechsle, wenn Kosten und Risiko des Bleibens höher sind als Kosten und Risiko der Übernahme. Ein verfehlter Meilenstein allein reicht nicht. Suche nach einem wiederkehrenden Muster: Releases sind nicht planbar, Fehler kommen ohne Ursachenbehebung zurück, Zugänge oder Dokumentation bleiben unter Anbieter-Kontrolle, wesentliche Risiken werden versteckt oder die kommerziellen Anreize passen nicht mehr zum Produkt.

Kündige keinen harten Cutover an, bevor Vertrag, Nutzungsrechte, Kündigungsfrist, Zahlungsstand, Auftragsverarbeitung und reale Zugänge geprüft sind. Bei Streit über Rechte oder Herausgabepflichten brauchst du qualifizierte Rechtsberatung. Dieser Artikel ist operative Orientierung, keine Rechtsberatung.

Was solltest du prüfen, bevor der neue Anbieter Zugang erhält?

Erstelle die Shortlist, bevor du Produktions-Credentials oder Kundendaten offenlegst. Im Juli 2026 hat NIST einen finalen Guide für Supplier Due Diligence veröffentlicht. Er strukturiert die Prüfung eines ICT-Anbieters unter anderem nach Herkunft, Resilienz, grundlegender Cybersecurity, Supply-Chain-Stufen sowie Eigentum und Kontrolle. Das korrigiert eine Auswahl nur nach Portfolio: Untersuche, wie der Anbieter arbeitet, nicht nur, was er gebaut hat. Siehe NIST SP 1326 zur Cybersecurity Supply Chain Due Diligence.

• Identität und Verantwortung. Welche juristische Person unterschreibt, wer leitet die Übernahme, wer darf in Produktion und wer entscheidet bei einem Incident?
• Brownfield-Nachweise. Frage nach einem anonymisierten Takeover-Report, Risikoregister oder 30-Tage-Plan, nicht nur nach Greenfield-Screenshots.
• Delivery-Grenze. Kläre, ob dieselben Menschen prüfen, stabilisieren und weiterentwickeln.
• Security-Praxis. Frage, wie Zugriffe genehmigt, protokolliert, geprüft und entzogen, Secrets behandelt und Findings eskaliert werden.
• Kommerzielle Unabhängigkeit. Das Assessment muss nützlich bleiben, wenn du den Folgeauftrag nicht vergibst.

Vergib namentliche, zeitlich begrenzte Least-Privilege-Zugänge über kundeneigene Identitäten. Beginne, wo möglich, nur lesend. Verschicke niemals Passwort-Dumps per E-Mail. Vereinbare, wie Evidenz gespeichert wird, wer sie sehen darf und wann sie gelöscht wird.

Der 30-Tage-Plan für die Softwareübernahme

30 Tage sind ein Planungsrahmen, kein allgemeines Versprechen. Ein kleines Webprodukt kann schneller sein. Eine regulierte Plattform, eine Mobile-Landschaft, ein Industriesystem oder ein Produkt mit 24/7-Pflichten braucht womöglich parallele Teams und eine längere Überlappung. Wichtiger als der Kalender ist die Reihenfolge.

Vor Tag 1: Transition Charter schreiben

Benenne je eine verantwortliche Person beim Kunden, bisherigen Anbieter und neuen Anbieter. Definiere Systeme im Scope, Notfallkanal, Change Authority, Meeting-Rhythmus, Evidence Repository, Überlappungsfenster und Unabhängigkeitstest. Trenne geordneten Exit und Notfall-Exit. Die aktuelle britische Mid-Tier-Contract-Guidance behandelt Exit Management als laufende Vorbereitung, inklusive gepflegter virtueller Bibliothek, Exit-Plan, Unterstützung bei Neuausschreibung und Termination Assistance. Dein Vertrag kann kleiner sein, das Prinzip skaliert trotzdem. Siehe die britische Government Guidance zu Exit Management.

Halte den bisherigen Anbieter, wo möglich, in einer klaren bezahlten Übergaberolle. Eine feindselige Übergabe liefert schlechtere Evidenz und erhöht das Geschäftsrisiko. Bezahle konkrete Artefakte und Sessions, dokumentiere offene Fragen und nutze Findings nicht für eine öffentliche Schuldzuweisung.

Tag 1 bis 5: Kontrolle sichern, ohne einen Ausfall auszulösen

1. Vor Rotation inventarisieren. Erfasse Repositories, Cloud, DNS, Zertifikate, Domains, App Stores, Datenbanken, Queues, E-Mail, Analytics, Observability, Support-Tools, Registries und Lizenzen.
2. Eigentum bestätigen. Dokumentiere Kontoinhaber, Billing Owner, Admins, Recovery-Kontakte und Transferweg.
3. Evidenz bewahren. Erstelle autorisierte Backups, Exporte und Konfigurations-Snapshots. Bewahre Audit Logs und Git-Historie.
4. Nach Abhängigkeit rotieren. Ersetze Credentials erst, wenn klar ist, was sie nutzt. Halte Rollback unter Kundenkontrolle.
5. Produktion baselinen. Erfasse Traffic, Fehlerrate, Latenz, Queues, Backups, Incidents, Support-Volumen und Release-Stand.

Ein Change Freeze sollte selektiv sein. Stoppe riskante Roadmap-Arbeit, Schema-Änderungen und Infrastruktur-Umbauten. Halte einen Emergency-Patch-Pfad mit namentlicher Freigabe offen. Ein pauschaler Freeze ohne Patch-Weg kann eine bekannte Lücke genauso konservieren wie Stabilität.

Tag 6 bis 10: System Map und Risikoregister aufbauen

Das neue Team sollte drei bis fünf geschäftskritische Journeys von der Nutzeraktion bis zu Daten und externen Effekten verfolgen, etwa Login, Kauf, Auszahlung, Dokumenterstellung oder Abrechnung. Dokumentiere Einstieg, Services, Datenspeicher, Drittanbieter, Berechtigungen, Monitoring, Fehlerbilder und manuelle Recovery.

Lass Code-Ästhetik nicht über Betriebsrisiko stehen. Ein älteres Framework mit reproduzierbarem Build und getesteter Recovery ist an Tag 10 sicherer als ein Rewrite-Plan ohne Produktionsnachweis.

Tag 11 bis 20: Betriebswege beweisen

Führe beobachtete Tests in der sichersten repräsentativen Umgebung durch. Das Team sollte Fresh Setup, reproduzierbaren Build, Deployment, Smoke Test, Rollback, Backup-Verifikation, Restore-Probe und Incident-Eskalation demonstrieren. Produktionsänderungen durchlaufen den normalen Risiko- und Freigabeprozess.

Prüfe für Cloud- und SaaS-Abhängigkeiten Exportwege und Wechselpflichten. Der EU Data Act gilt seit 12. September 2025 und stellt Mindestanforderungen an den Wechsel zwischen Datenverarbeitungsdiensten, einschließlich Cloud und Edge. Die Kommission erklärt, dass Anbieter Wechselhindernisse beseitigen und für PaaS und SaaS offene Schnittstellen sowie mindestens Exporte in gängigen maschinenlesbaren Formaten bereitstellen müssen. Scope und Ausnahmen zählen, prüfe daher Dienst und Vertrag. Siehe den Data-Act-Explainer der Europäischen Kommission.

Verarbeitet ein Anbieter personenbezogene Daten für dich, muss der Exit zum Auftragsverarbeitungsvertrag passen. Art. 28 DSGVO verlangt nach Ende der Leistung auf Wahl des Verantwortlichen die Löschung oder Rückgabe personenbezogener Daten, sofern keine gesetzliche Speicherung erforderlich ist. Dateninventar, Export, Löschbestätigung und entzogene Subprocessor-Zugriffe gehören deshalb in die Übernahme. Prüfe den amtlichen DSGVO-Text auf EUR-Lex.

Bei Produkten mit digitalen Elementen im CRA-Scope musst du klären, wer nach dem Wechsel Cybersecurity-Risikobewertung, technische Dokumentation, Supportzeitraum und Vulnerability Handling verantwortet. Die Pflichten hängen von Produkt und Rolle ab. Die Zusammenfassung des Cyber Resilience Act durch die Europäische Kommission erklärt Herstellerpflichten, Schwachstellenbehandlung und zentrale Geltungsdaten.

Tag 21 bis 30: eine begrenzte Änderung liefern

Eine Übernahme wird nicht durch Slides bewiesen. Wähle eine risikoarme Änderung, die den echten Weg vom Issue bis zur Produktion berührt: einen Defect, eine Observability-Verbesserung, einen Dependency-Patch oder eine kleine Workflow-Korrektur. Verlange Review, automatisierte Checks, Deployment-Evidenz und Beobachtung nach dem Release.

Nutze eine klare Security-Baseline. Das Secure Software Development Framework von NIST bietet Praktiken für unterschiedliche Entwicklungsprozesse. Für Webanwendungen liefert OWASP ASVS 5.0 testbare Security-Anforderungen und ist ausdrücklich auch für Procurement gedacht. Wähle Anforderungen risikobasiert. Behaupte keine pauschale Compliance, nur weil ein Scanner einmal lief.

Die Entscheidung an Tag 30 sollte auf einen von vier Wegen führen: vorsichtige Wartung, Stabilisierung vor neuen Features, Modernisierung ausgewählter Grenzen oder Ersatz, wenn Evidenz für bessere Gesamtkosten und geringeres Risiko spricht. „Alles neu schreiben“ ist ein Ergebnis, keine Startmethode.

Was kann beim Softwareanbieterwechsel schiefgehen?

Wie wählst du den neuen Softwareanbieter aus?

Gib allen Finalisten dasselbe redigierte Evidence Pack: System Map, Constraints, eine kritische Journey und das gewünschte Ergebnis. Frage nach Risiken, Unbekannten, Zugangsbedarf, den ersten zwei Wochen, Teamrollen, Decision Gates und Annahmen. Belohne nicht das längste generische Angebot.

Lege die Regel vor den Angeboten fest. Unser Default sind mindestens 70 Punkte ohne Hard Stop. Hard Stops sind: kein verantwortlicher Lead, kein sicherer Produktionszugang, kein schriftliches Assessment, unklare Rechte am Ergebnis oder ein fixer Rewrite vor der Prüfung. Passe Gewichte an dein Produkt an, aber lass keinen starken Sales Call eine nicht erfüllte Kontrolle kompensieren.

Wann Wavect passt und wann nicht

Wavect passt, wenn du ein laufendes oder festgefahrenes Custom-Softwareprodukt hast, legitimen Stakeholder- und Systemzugang geben kannst und vor Wartung oder Weiterentwicklung ein Assessment willst. Unser Grundsatz: System verstehen, Risiken dokumentieren, Relevantes stabilisieren und Folgearbeit danach aus Evidenz quotieren. Den schriftlichen Bericht behältst du.

Wir passen nicht für einen blinden Rewrite, anonyme Staff Augmentation, einen allgemeinen 24/7-IT-Helpdesk oder eine Übernahme ohne autorisierbaren Zugang. Manchmal ist die richtige Empfehlung, das bisherige Team zu behalten und Governance zu reparieren. Weil dies ein Wavect-Artikel ist, verstehe die Scorecard als offengelegte Perspektive und fordere von jedem Anbieter, auch von uns, dieselben Nachweise.

Ein relevantes Beispiel ist die FTW-Ventures-Case-Study. Für eine unabhängige Qualitätsbaseline vor oder während der Übernahme sieh dir unseren Software-QA-Service an.

FAQ zur Softwareübernahme