--- title: "Softwareprojekt übernehmen: 30-Tage-Anbieterwechsel" canonical: https://wavect.io/de/blog/software-project-takeover-provider-change/ language: de description: "Softwareanbieter wechseln? 30-Tage-Plan, Risikoregister und Scorecard für Zugänge, Releases, Daten, Recovery und die Wahl des neuen Partners." image: "https://wavect.io/img/blog/headers/header_software-project-takeover-provider-change.png" --- [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 15 min Lesezeit · 13. August 2026 Zuletzt geprüft 13. August 2026 [**Weiter**](/de/blog/software-agency-proposal-teardown/) # Softwareprojekt übernehmen: 30-Tage-Plan für den Anbieterwechsel TL;DR Eine Softwareübernahme ist gelungen, wenn das neue Team das Produkt ohne den bisherigen Anbieter bauen, deployen, beobachten, zurückrollen und wiederherstellen kann. Sichere an Tag 1 bis 5 Eigentum und Produktions-Baseline, kartiere an Tag 6 bis 10 Architektur und kritische Journeys, beweise an Tag 11 bis 20 Release und Recovery und liefere an Tag 21 bis 30 eine kleine risikoarme Änderung. Wähle den neuen Anbieter nach Brownfield-Nachweisen, operativer Kontrolle, Sicherheit, Übernahmemethode und kommerzieller Klarheit. Lehne Anbieter ab, die vor der Prüfung einen Rewrite oder einen fixen Lieferplan versprechen. **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](/de/software-development-guide/software-handover-checklist/) für die vollständige Artefaktliste, den [Guide zur Auswahl einer Softwareagentur](/de/software-development-guide/how-to-choose-a-software-agency/) für die breitere Einkaufsentscheidung und Wavects [Software-Übernahme-Service](/de/services/software-takeover/), 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. | Situation | Bester erster Schritt | Warum | | --- | --- | --- | | Das Team ist fähig, aber Prioritäten und Verantwortung sind unklar | Governance und Entscheidungsrechte neu setzen | Ein neuer Anbieter würde dasselbe Führungsproblem erben. | | Delivery ist langsam, das System aber stabil und transparent | Ein begrenztes unabhängiges Assessment | Du brauchst Evidenz, bevor du Wechselkosten bezahlst. | | Code, Cloud oder Daten liegen in Anbieter-Accounts | Exit und Rückgewinnung der Kontrolle planen | Die operative Abhängigkeit ist bereits ein Geschäftsrisiko. | | Security, Datenintegrität oder Produktionskontinuität sind gefährdet | Kontrollierte Notfall-Triage | Begrenze das Risiko vor der langfristigen Roadmap. | 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](https://csrc.nist.gov/pubs/sp/1326/final). - **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. | Phase | Primäres Ziel | Abschlussnachweis | | --- | --- | --- | | Vor Tag 1 | Mandat, Scope, Kommunikation und Exit-Pflichten klären | Transition Charter, Owner Map und Zugriffsprotokoll | | Tag 1 bis 5 | Kontrolle sichern und Produktion baselinen | Asset-Register, Zugriffsmatrix, Health Snapshot | | Tag 6 bis 10 | Architektur, Daten und kritische Journeys kartieren | System Map, Risikoregister, verifizierter lokaler Build | | Tag 11 bis 20 | Deploy, Rollback, Restore und Incident Response beweisen | Beobachtete Betriebstests und Stabilitätsplan | | Tag 21 bis 30 | Eine kleine Änderung liefern und Roadmap entscheiden | Produktionsänderung, Review und 90-Tage-Plan | ### 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](https://www.gov.uk/government/publications/guidance-on-the-mid-tier-contract/the-mid-tier-contract-guidance-for-buyers-html). 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. | Klasse | Bedeutung | Aktion | | --- | --- | --- | | P0: aktive Gefährdung | Aktuelles Security-, Datenverlust- oder Kontinuitätsrisiko | Sofort eindämmen, Evidenz sichern, Owner informieren | | P1: Release-Blocker | Das Team kann nicht sicher ändern oder wiederherstellen | Build, Deploy, Rollback, Backup oder Observability reparieren | | P2: Delivery-Bremse | Reibung verlangsamt jede Änderung | Dort beheben, wo die nächste Roadmap-Arbeit sie berührt | | P3: Verbesserung | Sinnvoll, aber nicht für sichere Verantwortung erforderlich | Mit Business Case in die normale Roadmap | 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](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained). 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](https://eur-lex.europa.eu/eli/reg/2016/679/oj). 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](https://digital-strategy.ec.europa.eu/en/policies/cra-summary) 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](https://csrc.nist.gov/pubs/sp/800/218/final) bietet Praktiken für unterschiedliche Entwicklungsprozesse. Für Webanwendungen liefert [OWASP ASVS 5.0](https://owasp.org/www-project-application-security-verification-standard/) 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? | Fehlermodus | Frühes Signal | Kontrolle | | --- | --- | --- | | Credentials werden falsch rotiert | Unbekannte Consumer und geteilte Accounts | Abhängigkeiten kartieren, in Wellen rotieren, Rollback halten | | Die Übergabe wird zum Videoarchiv | Viele Calls, keine ausführbaren Runbooks | Jede Session in Artefakt und verifizierten Task überführen | | Der neue Anbieter verkauft sofort einen Rewrite | Schätzung und Architektur vor dem Zugang | Begrenztes Assessment mit Kriterien für Weiterverwenden oder Ersetzen | | Das alte Team geht zu früh | Keine Überlappung für Deploy oder Incident | Gezielte Hilfe halten, bis Unabhängigkeits-Gates erfüllt sind | | Feature-Druck verdrängt Stabilisierung | Roadmap-Termine vor dem Risikoregister | Takeover-, Stabilitäts- und Roadmap-Budget trennen | | Lizenzen oder Accounts sind nicht übertragbar | Kernservices unter Anbieter-Verträgen | Verträge, Exporte und Ersatzkosten vor Cutover inventarisieren | | Ein ernstes Finding bleibt im Chat | Kein Owner oder Severity | Vertrauliche Eskalation, Evidence Controls und Decision Log | | Erfolg bedeutet „Repo geliefert“ | Kein Deploy-, Rollback- oder Restore-Test | Operative Unabhängigkeit zum Abnahmekriterium machen | ## 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. | Kriterium | Gewicht | Anzufordernder Nachweis | | --- | --- | --- | | Brownfield- und Takeover-Erfahrung | 20 | Anonymisiertes Assessment, Fall oder Risikoregister | | Übernahmemethode | 20 | 30-Tage-Plan, Unabhängigkeits-Gates, Protokoll mit dem alten Team | | Release- und Recovery-Kompetenz | 15 | Build, Deploy, Rollback, Backup und Restore | | Security und Datenbehandlung | 15 | Zugriffsmodell, Eskalation, Evidenz und Löschprozess | | Kommerzielle Klarheit | 10 | Scope, Annahmen, Ausschlüsse, IP, Exit und Folgemodell | | Produkt- und Roadmap-Urteil | 10 | Beispiele für Behalten, Ändern oder Ablehnen | | Kommunikation und Kontinuität | 10 | Lead, echtes Team, Vertretung und Entscheidungsrhythmus | 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](/de/case-studies/ftw-ventures/). Für eine unabhängige Qualitätsbaseline vor oder während der Übernahme sieh dir unseren [Software-QA-Service](/de/services/software-quality-assurance/) an. ## FAQ zur Softwareübernahme ## Häufig gestellte Fragen ### Wie lange dauert die Übernahme eines Softwareprojekts? Nutze 30 Tage als erstes Kontroll- und Assessment-Fenster, nicht als Abschlussversprechen. Kleine Produkte können früher unabhängig sein. Regulierte, verteilte oder schlecht dokumentierte Systeme brauchen oft längere Überlappung. Definiere Abschluss über Build, Deploy, Rollback, Restore und Incident-Evidenz. ### Kann ein neuer Anbieter Software ohne Dokumentation übernehmen? Oft ja, wenn der Kunde Code, Infrastruktur und Stakeholder-Zugang rechtmäßig bereitstellen kann. Rechne mit mehr Discovery-Aufwand. Das Team muss Architektur und Betrieb aus Repositories, Konfiguration, Telemetrie, Tickets und Interviews rekonstruieren und die fehlenden Runbooks beim Verifizieren schreiben. ### Soll der neue Anbieter die Software neu schreiben? Nicht vor dem Assessment. Vergleiche Wartung, gezielte Stabilisierung, schrittweise Modernisierung und Ersatz. Ein Rewrite ist erst begründet, wenn Evidenz zeigt, dass Gesamtkosten und Risiko des bestehenden Systems höher sind. ### Was tun, wenn der bisherige Anbieter nicht kooperiert? Sichere Verträge, Rechnungen, Korrespondenz und bestehende Zugänge. Kläre, was der Kunde besitzt, vermeide unautorisierten Zugriff und lass Rechte qualifiziert prüfen. Technisch priorisierst du Backups, Account Recovery, Kontinuität und ein Unknowns Register. ### Was muss ein Takeover-Assessment liefern? Mindestens Asset- und Zugriffsinventar, System- und Datenfluss-Map, Build- und Deployment-Status, Betriebs- und Security-Risikoregister, Dependency- und Lizenzfragen, Doku-Lücken, Stabilitätsprioritäten, Optionen, Teambedarf und ein bepreistes Folgeangebot mit Annahmen. ### Wie vergleiche ich Anbieter für eine Softwareübernahme? Gib Finalisten dasselbe Szenario und bewerte Evidenz statt Selbstsicherheit. Gewichte Brownfield-Erfahrung, Methode, Release und Recovery, Security und Daten, kommerzielle Klarheit, Produkturteil und Kontinuität. Verlange ein Assessment, das auch bei einem anderen Umsetzungspartner nützlich bleibt. ## Fazit Ein sicherer Softwareanbieterwechsel überträgt Fähigkeit, nicht nur Dateien. Das neue Team muss das System erklären, unter Druck betreiben und eine kleine Änderung durch den echten Release-Weg bringen können. Deshalb führt der erste Monat von Kontrolle über Verständnis zu Betriebsnachweis und erst dann zur Roadmap. Wähle den Anbieter, der Unbekannte, Evidenz und Decision Gates am präzisesten beschreibt. Der beste Takeover-Pitch ist selten das größte Versprechen. Es ist die klarste Methode, Abhängigkeit zu reduzieren, während Produkt und Geschäft weiterlaufen. ## Das könnte dich auch interessieren.. [**Softwareagentur-Angebot im Teardown** Prüfe nach der Anbieterwahl Scope, Abnahme, IP, Security und Exit-Klauseln vor der Unterschrift.](/de/blog/software-agency-proposal-teardown/) [**Wavect vs. klassische Entwicklungsagentur** Vergleiche founder-geführtes Produkturteil, Senior-Kontinuität und saubere Übergabe mit kapazitätsgetriebener Delivery.](/de/compare/wavect-vs-dev-agencies/) Softwareeinkauf und Finanzierung ## In diesem Cluster weiterlesen Agenturauswahl, Verträge, Preise, Förderungen und die kommerzielle Seite der Delivery. [Mit dem Grundlagenartikel starten**Softwareagentur-Angebot im Check: 12 Klauseln zu Preis, Scope und Eigentum**](/de/blog/software-agency-proposal-teardown/) - [Worauf dich das Wort "Dienstleister" festlegt](/de/blog/werkvertrag-vs-dienstvertrag-software-austria/) - [Softwareagenturen in Tirol im Vergleich 2026](/de/blog/software-agencies-tyrol-comparison-2026/) - [Softwareagentur-Angebot im Check: 12 Klauseln zu Preis, Scope und Eigentum](/de/blog/software-agency-proposal-teardown/) - [KI-Beratung Österreich 2026: der ehrliche Guide](/de/blog/ai-consulting-austria-2026/) - [KI-Förderung Österreich 2026: aws, FFG, Forschungsprämie](/de/blog/ai-funding-austria-2026/) Postfach, ohne Lärm ## Folge der Arbeit, die für dich zählt Du bekommst eine kurze E-Mail, wenn wir etwas Neues veröffentlichen. Folge dem ganzen Blog oder nur den Themen, die dich interessieren. [**Zurück**](/de/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/de/team/kevin-riedl/) [Kevin Riedl](/de/team/kevin-riedl/) https://linkedin.com/in/wsdt 15 min Lesezeit · 13. August 2026 Zuletzt geprüft 13. August 2026 [**Weiter**](/de/blog/software-agency-proposal-teardown/) Neue Beiträge per E-Mail × × Neue Beiträge per E-Mail Eine kurze E-Mail, wenn wir etwas veröffentlichen. Kostenlos, ohne Tracking. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/de/blog/software-project-takeover-provider-change/#webpage", "@type": "WebPage", "dateModified": "2026-08-13", "inLanguage": "de", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-13", "url": "https://wavect.io/de/blog/software-project-takeover-provider-change/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Eine Softwareübernahme ist gelungen, wenn das neue Team das Produkt ohne den bisherigen Anbieter bauen, deployen, beobachten, zurückrollen und wiederherstellen kann. Sichere an Tag 1 bis 5 Eigentum und Produktions-Baseline, kartiere an Tag 6 bis 10 Architektur und kritische Journeys, beweise an Tag 11 bis 20 Release und Recovery und liefere an Tag 21 bis 30 eine kleine risikoarme Änderung. Wähle den neuen Anbieter nach Brownfield-Nachweisen, operativer Kontrolle, Sicherheit, Übernahmemethode und kommerzieller Klarheit. Lehne Anbieter ab, die vor der Prüfung einen Rewrite oder einen fixen Lieferplan versprechen.", "articleBody": " Blog-Übersicht/Business und Regulierung/Softwareeinkauf und Finanzierung Softwareprojekt übernehmen: 30-Tage-Plan für den Anbieterwechsel TL;DR Eine Softwareübernahme ist gelungen, wenn das neue Team das Produkt ohne den bisherigen Anbieter bauen, deployen, beobachten, zurückrollen und wiederherstellen kann. Sichere an Tag 1 bis 5 Eigentum und Produktions-Baseline, kartiere an Tag 6 bis 10 Architektur und kritische Journeys, beweise an Tag 11 bis 20 Release und Recovery und liefere an Tag 21 bis 30 eine kleine risikoarme Änderung. Wähle den neuen Anbieter nach Brownfield-Nachweisen, operativer Kontrolle, Sicherheit, Übernahmemethode und kommerzieller Klarheit. Lehne Anbieter ab, die vor der Prüfung einen Rewrite oder einen fixen Lieferplan versprechen. 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. SituationBester erster SchrittWarum Das Team ist fähig, aber Prioritäten und Verantwortung sind unklarGovernance und Entscheidungsrechte neu setzenEin neuer Anbieter würde dasselbe Führungsproblem erben. Delivery ist langsam, das System aber stabil und transparentEin begrenztes unabhängiges AssessmentDu brauchst Evidenz, bevor du Wechselkosten bezahlst. Code, Cloud oder Daten liegen in Anbieter-AccountsExit und Rückgewinnung der Kontrolle planenDie operative Abhängigkeit ist bereits ein Geschäftsrisiko. Security, Datenintegrität oder Produktionskontinuität sind gefährdetKontrollierte Notfall-TriageBegrenze das Risiko vor der langfristigen Roadmap. 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. PhasePrimäres ZielAbschlussnachweis Vor Tag 1Mandat, Scope, Kommunikation und Exit-Pflichten klärenTransition Charter, Owner Map und Zugriffsprotokoll Tag 1 bis 5Kontrolle sichern und Produktion", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "NIST SP 1326 zur Cybersecurity Supply Chain Due Diligence", "url": "https://csrc.nist.gov/pubs/sp/1326/final" }, { "@type": "WebPage", "name": "britische Government Guidance zu Exit Management", "url": "https://www.gov.uk/government/publications/guidance-on-the-mid-tier-contract/the-mid-tier-contract-guidance-for-buyers-html" }, { "@type": "WebPage", "name": "Data-Act-Explainer der Europäischen Kommission", "url": "https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained" }, { "@type": "WebPage", "name": "amtlichen DSGVO-Text auf EUR-Lex", "url": "https://eur-lex.europa.eu/eli/reg/2016/679/oj" }, { "@type": "WebPage", "name": "Zusammenfassung des Cyber Resilience Act durch die Europäische Kommission", "url": "https://digital-strategy.ec.europa.eu/en/policies/cra-summary" }, { "@type": "WebPage", "name": "Secure Software Development Framework von NIST", "url": "https://csrc.nist.gov/pubs/sp/800/218/final" }, { "@type": "WebPage", "name": "OWASP ASVS 5.0", "url": "https://owasp.org/www-project-application-security-verification-standard/" } ], "dateModified": "2026-08-13", "datePublished": "2026-08-13", "description": "Eine Softwareübernahme ist gelungen, wenn das neue Team das Produkt ohne den bisherigen Anbieter bauen, deployen, beobachten, zurückrollen und wiederherstellen kann. Sichere an Tag 1 bis 5 Eigentum und Produktions-Baseline, kartiere an Tag 6 bis 10 Architektur und kritische Journeys, beweise an Tag 11 bis 20 Release und Recovery und liefere an Tag 21 bis 30 eine kleine risikoarme Änderung. Wähle den neuen Anbieter nach Brownfield-Nachweisen, operativer Kontrolle, Sicherheit, Übernahmemethode und kommerzieller Klarheit. Lehne Anbieter ab, die vor der Prüfung einen Rewrite oder einen fixen Lieferplan versprechen.", "headline": "Softwareprojekt übernehmen: 30-Tage-Plan für den Anbieterwechsel", "image": "https://wavect.io/img/blog/headers/header_software-project-takeover-provider-change.svg", "inLanguage": "de", "keywords": "Engineering, Softwareübernahme, Anbieterwechsel", "mainEntityOfPage": { "@id": "https://wavect.io/de/blog/software-project-takeover-provider-change/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/de/blog/software-project-takeover-provider-change/", "wordCount": 2288 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/de/", "name": "Startseite", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/overview/", "name": "Blog-Übersicht", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/topics/business-regulation/", "name": "Business und Regulierung", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/clusters/software-buying-funding/", "name": "Softwareeinkauf und Finanzierung", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/de/blog/software-project-takeover-provider-change/", "name": "Softwareprojekt übernehmen: 30-Tage-Anbieterwechsel | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nutze 30 Tage als erstes Kontroll- und Assessment-Fenster, nicht als Abschlussversprechen. Kleine Produkte können früher unabhängig sein. Regulierte, verteilte oder schlecht dokumentierte Systeme brauchen oft längere Überlappung. Definiere Abschluss über Build, Deploy, Rollback, Restore und Incident-Evidenz." }, "name": "Wie lange dauert die Übernahme eines Softwareprojekts?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Oft ja, wenn der Kunde Code, Infrastruktur und Stakeholder-Zugang rechtmäßig bereitstellen kann. Rechne mit mehr Discovery-Aufwand. Das Team muss Architektur und Betrieb aus Repositories, Konfiguration, Telemetrie, Tickets und Interviews rekonstruieren und die fehlenden Runbooks beim Verifizieren schreiben." }, "name": "Kann ein neuer Anbieter Software ohne Dokumentation übernehmen?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Nicht vor dem Assessment. Vergleiche Wartung, gezielte Stabilisierung, schrittweise Modernisierung und Ersatz. Ein Rewrite ist erst begründet, wenn Evidenz zeigt, dass Gesamtkosten und Risiko des bestehenden Systems höher sind." }, "name": "Soll der neue Anbieter die Software neu schreiben?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Sichere Verträge, Rechnungen, Korrespondenz und bestehende Zugänge. Kläre, was der Kunde besitzt, vermeide unautorisierten Zugriff und lass Rechte qualifiziert prüfen. Technisch priorisierst du Backups, Account Recovery, Kontinuität und ein Unknowns Register." }, "name": "Was tun, wenn der bisherige Anbieter nicht kooperiert?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Mindestens Asset- und Zugriffsinventar, System- und Datenfluss-Map, Build- und Deployment-Status, Betriebs- und Security-Risikoregister, Dependency- und Lizenzfragen, Doku-Lücken, Stabilitätsprioritäten, Optionen, Teambedarf und ein bepreistes Folgeangebot mit Annahmen." }, "name": "Was muss ein Takeover-Assessment liefern?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Gib Finalisten dasselbe Szenario und bewerte Evidenz statt Selbstsicherheit. Gewichte Brownfield-Erfahrung, Methode, Release und Recovery, Security und Daten, kommerzielle Klarheit, Produkturteil und Kontinuität. Verlange ein Assessment, das auch bei einem anderen Umsetzungspartner nützlich bleibt." }, "name": "Wie vergleiche ich Anbieter für eine Softwareübernahme?" } ] } ```