Neuen Entwicklungspartner onboarden: Checkliste für die Übergabe

Der Wechsel zu einem neuen Entwicklungspartner gelingt, wenn Sie vier Dinge in der richtigen Reihenfolge tun. Klären Sie zuerst schriftlich die Fragen zu Rechten und Daten. Übergeben Sie Code, Konten und Wissen in einer kontrollierten Abfolge. Lassen Sie das neue Team eine kurze Zeit parallel zum alten arbeiten. Und nehmen Sie die Übergabe erst ab, wenn der neue Partner eine echte Änderung eigenständig ausgeliefert hat. Dieser Leitfaden führt Sie Schritt für Schritt durch die Checkliste für einen Partnerwechsel in einem Schweizer Unternehmen, inklusive der rechtlichen Punkte, über die Teams regelmässig stolpern.

Kurz zusammengefasst

• Bevor jemand Code anfasst: schriftlich festhalten, wem das Urheberrecht gehört, wo Daten bearbeitet werden und wer welches Konto besitzt.
• Übergeben Sie das vollständige Repository samt Historie und wechseln Sie danach sämtliche Zugangsdaten. Verlassen Sie sich nicht auf eine ZIP-Datei oder geteilte Passwörter.
• Lassen Sie alten und neuen Partner eine kurze Zeit parallel laufen, mit schrittweiser statt stichtagsbezogener Übergabe der Verantwortung.
• Legen Sie Umfang, Kommunikationsrhythmus, Meilensteine und Abnahmekriterien vor dem ersten Sprint fest, nicht währenddessen.
• Die Übergabe ist abgeschlossen, wenn der neue Partner eine Änderung eigenständig ausgeliefert hat, nicht wenn eine Checkliste abgehakt ist.

Was Sie klären, bevor der neue Partner startet

Die meisten gescheiterten Übergaben scheitern nicht an der Technik. Sie scheitern an Fragen, die in der ersten Woche niemand gestellt hat. Klären Sie diese Punkte vor dem Kickoff.

Warum Sie wechseln. Notieren Sie die zwei oder drei Gründe: verpasste Termine, eine abgewanderte Schlüsselperson in der Entwicklung, ein Technologie-Stack, den niemand mehr warten kann, oder die Kosten. Der neue Partner braucht das, um das Muster nicht zu wiederholen, und Sie brauchen es, um später den Erfolg zu beurteilen.

Was tatsächlich existiert. Listen Sie jedes Produkt, jede Umgebung und jeden Drittanbieterdienst auf, aus denen das System besteht: Produktion, Staging, Domain-Registrar, Hosting-Konto, Zahlungs- und E-Mail-Anbieter, Analytics, CI/CD, Monitoring. Teams sind meist überrascht, wie viele davon auf den Namen oder die Kreditkarte des bisherigen Dienstleisters laufen.

Wer entscheiden darf. Benennen Sie auf Ihrer Seite eine Person, die den Umfang freigeben darf, und eine, die Ausgaben freigeben darf. Ein neuer Partner mit fünf Quellen für Anweisungen reproduziert genau die Verwirrung, die Sie hinter sich lassen wollen.

Was im alten Vertrag steht. Prüfen Sie Kündigungsfrist, Übergabepflichten des bisherigen Dienstleisters, Vertraulichkeitsklauseln und allfällige Einschränkungen bei der Weitergabe von Code an einen Nachfolger. Ihre Rechtsberatung sollte das lesen, bevor Sie dem neuen Partner einen Starttermin zusagen.

Rechte, Datenschutz und Vertragsbedingungen prüfen

In der Schweiz gibt es einige Regeln, die Gründer:innen überraschen. Klären Sie sie früh, denn sie können den neuen Partner rechtlich daran hindern, an Ihrem Produkt zu arbeiten.

Wem der Quellcode gehört

Dass der Code auf Ihrem Server liegt, heisst nicht, dass Ihnen die Rechte daran gehören. Nach Schweizer Recht wird copyright in software is not automatically transferred to the commissioning party ausserhalb von Anstellungsverhältnissen nicht automatisch auf die auftraggebende Partei übertragen, und die Herausgabe einer Kopie des Quellcodes bringt nicht automatisch das Nutzungsrecht mit sich. Ein Unternehmen, das Code ohne ausdrückliche Rechtsübertragung besitzt, darf ihn unter Umständen weder ändern noch weitergeben noch anderswo betreiben.

Das Bundesgericht hat gleich entschieden. Gemäss einer University of Geneva analysis of the ruling bedeutet ein Softwareentwicklungsvertrag nicht automatisch, dass das Urheberrecht auf die Kundschaft übergeht. Die Kundschaft muss sich auf eine ausdrückliche Bestimmung berufen können, und eine Pflicht zur Herausgabe des Quellcodes begründet die Übertragung für sich allein nicht.

In der Praxis heisst das: Suchen Sie in Ihrem alten Vertrag die Klausel, die das Urheberrecht überträgt oder Nutzungsrechte einräumt. Fehlt sie oder ist sie unklar, lassen Sie Ihre Rechtsberatung die Rechte vom bisherigen Dienstleister schriftlich bestätigen, bevor der neue Partner beginnt. Achten Sie anschliessend darauf, dass Ihr Vertrag mit dem neuen Partner die Übertragung oder Lizenz von Tag eins an klar festhält. Komponenten von Dritten und Open-Source-Bestandteile verdienen eine eigene kurze Liste, samt ihren Lizenzen.

Personendaten und der Auftragsbearbeitungsvertrag

Wenn das System Personendaten bearbeitet, kommt der neue Partner beim Testen, im Support oder bei der Migration damit in Berührung. Eine Schweizer Checkliste zur IT-Beschaffung der Kanzlei Wicki Partners nennt die Fragen, die Sie beantworten sollten:

• Werden überhaupt Personendaten bearbeitet, und gilt zusätzlich die DSGVO?
• Verlassen Daten die Schweiz, und wohin gehen sie?
• Liegt ein Auftragsbearbeitungsvertrag vor?
• Wem stehen die Rechte an den gespeicherten Daten zu?
• Kann der Anbieter seine technischen und organisatorischen Massnahmen belegen?

Lassen Sie den neuen Partner seine Antworten in den Vertrag schreiben. Legen Sie ausserdem fest, wie während der Übergabe mit Produktionsdaten umgegangen wird. Staging-Umgebungen mit anonymisierten oder synthetischen Daten sind sicherer als Kopien echter Kundendaten auf einem Entwickler-Laptop. Unterliegen Ihre Daten besonderen Geheimhaltungspflichten, etwa im Banken- oder Gesundheitsbereich, beziehen Sie Ihre Datenschutzverantwortung ein, bevor eine Kopie erstellt wird.

Die Übergabe-Checkliste aufbauen

Das ist der Kern der Übergabe. Behandeln Sie jede Zeile als Aufgabe mit einer verantwortlichen Person und einem Termin.

Bereich	Was zu übergeben ist	Woran Sie die Erledigung erkennen
Quellcode	Vollständige Repositories mit kompletter Historie, Branches, Tags und CI-Konfiguration	Der neue Partner baut und deployt aus dem Repository, das Ihnen gehört
Konten	Hosting, Domain-Registrar, App Stores, Zahlungen, E-Mail, Analytics, Monitoring	Jedes Konto führt Ihr Unternehmen als Inhaber, mit namentlich genannten Admin-Nutzenden
Zugangsdaten	API-Schlüssel, Datenbankpasswörter, Deploy-Keys, Signaturzertifikate	Alle gewechselt; alte Werte funktionieren nicht mehr
Infrastruktur	Umgebungsdiagramme, Infrastructure as Code, Backup- und Wiederherstellungsabläufe	Der neue Partner führt einen Wiederherstellungstest durch
Dokumentation	Architekturnotizen, Datenmodell, Betriebshandbücher, Releaseprozess, bekannte Probleme	Der neue Partner kann dem Betriebshandbuch folgen, ohne das alte Team anzurufen
Wissen	Durchsprachen, aufgezeichnete Demos, offenes Ticket-Backlog mit Kontext	Die Fragenliste ist abgeschlossen oder bewusst zurückgestellt
Recht	Übertragung des Urheberrechts, Auftragsbearbeitungsvertrag, Lizenzliste	Unterzeichnet und abgelegt

Code, Konten und Zugangsdaten sicher übergeben

Übergeben Sie das ganze Repository, nicht eine Momentaufnahme des Hauptbranches. Alte Branches und Commit-Nachrichten erklären, warum die Dinge so sind, wie sie sind, und genau das brauchen Sie beim ersten Störfall. Wenn Sie ein Repository zwischen Organisationen auf einer Plattform wie GitHub übertragen, prüfen Sie, was daran hängen bleibt, etwa Webhooks, Deploy-Keys und Secrets. Übernommene Integrationen können sonst weiterhin mit den Zugangsdaten des alten Dienstleisters laufen. Eine vendor handover checklist from Trio macht denselben Punkt: Secrets werden am häufigsten vergessen.

Eine praktikable Reihenfolge:

1. Zuerst inventarisieren. Ein gemeinsames Dokument listet jedes Konto und jedes Secret samt aktueller Inhaberschaft.
2. Kontoinhaberschaft auf Ihr Unternehmen übertragen. Der alte Dienstleister soll Nutzer in Ihrem Konto sein, nicht umgekehrt.
3. Dem neuen Partner persönliche, namentliche Zugänge geben, über Ihren Passwortmanager oder Ihren Identitätsdienst. Teilen Sie nie einen Login unter mehreren Personen.
4. Secrets wechseln, sobald der neue Partner arbeitet, und im selben Zug die Zugänge des bisherigen Dienstleisters entziehen.
5. Änderungen protokollieren, damit Sie belegen können, wer wann Zugang hatte.

Wer was besitzt, pro Konto und Umgebung, halten Sie in Ihrem eigenen Übergabeblatt fest. Wenn Sie eine Vorlage suchen, die Sie für den Umfang der Übergabe und die anschliessenden Servicelevel anpassen können, ist this checklist product ein möglicher Ausgangspunkt.

Wissen übergeben, nicht nur Dateien

Code erklärt, was ein System tut. Er erklärt selten, warum. Planen Sie drei Arten von Sitzungen mit dem bisherigen Team, selbst wenn das Verhältnis angespannt ist, und erwägen Sie, sie in Ihren Ausstiegsbedingungen zu vergüten:

• Architektur-Durchsprache: Komponenten, Datenflüsse, Abhängigkeiten von Dritten.
• Betriebs-Durchsprache: wie Releases ablaufen, was kaputtgeht, wer alarmiert wird, welche monatlichen Routinen es gibt.
• Backlog-Durchsprache: jedes offene Ticket, mit dem Grund für seine Existenz und allfälligen Zusagen gegenüber Kundschaft.

Zeichnen Sie die Sitzungen auf. Neue Teammitglieder schauen sich diese Aufnahmen Monate später an. Dieselbe Logik gilt, wenn KI-Komponenten Teil des Systems sind: Prompts, Modellkonfiguration, Evaluationsdaten und Deployment-Einstellungen gehören dokumentiert wie jeder andere Code. Ein Beitrag zu knowledge transfer and operational continuity bei KI-Deployments behandelt diesen Aspekt ausführlicher.

Die Zusammenarbeit vereinbaren

Eine saubere technische Übergabe scheitert trotzdem, wenn die Arbeitsvereinbarung vage bleibt. Klären Sie diese Punkte vor dem ersten Sprint.

Umfang. Beschreiben Sie das erste Arbeitspaket, nicht die ganze Roadmap. Wählen Sie etwas Kleines und Echtes, etwa das Beheben eines bekannten Fehlers oder das Ausliefern einer kleineren Funktion, damit beide Seiten die Arbeitsweise der anderen günstig kennenlernen.

Verantwortlichkeiten. Halten Sie fest, wer für Störungen in der Produktion zuständig ist, wer Releases freigibt, wer mit den Nutzenden spricht und wer Sicherheitsupdates einspielt. Wenn Sie zusätzlich eine Person im eigenen Haus haben, definieren Sie die Abgrenzung zum Partner.

Kommunikation. Legen Sie einen Kanal für tägliche Fragen und ein wöchentliches Meeting für Entscheidungen fest. Vereinbaren Sie Reaktionszeiten. Fragen Sie, wer während der gesamten Zusammenarbeit Ihre Ansprechperson ist und ob diese Person auch selbst arbeitet. Personelle Kontinuität zählt in den ersten Monaten sehr viel. Fragen Sie deshalb direkt, wie der Partner das Mandat besetzt und was passiert, wenn jemand geht.

Meilensteine und Abnahmekriterien. Schreiben Sie für jeden Meilenstein beobachtbar auf, was «fertig» bedeutet: in Produktion ausgeliefert, Tests laufen durch, Dokumentation aktualisiert, Sie können die Funktion vorführen. Vage Abnahmeformulierungen sind der Ursprung von Streit über den Umfang.

Servicelevel nach dem Start. Wenn der Partner das System betreibt, definieren Sie, was überwacht wird, wie schnell er auf Störungen reagiert und was monatlich enthalten ist. Unser eigener Monitoring-Plan, Run & monitor, kostet CHF 750 pro Monat; verlangen Sie von jedem Partner die gleiche Aufschlüsselung, damit Sie Vergleichbares vergleichen.

Ausfälle mit einer gestaffelten Übernahme vermeiden

Am riskantesten ist das Umschaltwochenende: Der alte Dienstleister geht am Freitag, der neue beginnt am Montag. Ein gestaffelter Plan in etwa drei Phasen ist sicherer. Dieser Aufbau folgt einem 90-day transition plan published by Howdy, hier als allgemeines Muster angepasst. Die Dauer hängt von der Systemgrösse ab: Betrachten Sie 90 Tage als Obergrenze für ein komplexes Produkt und planen Sie für eine einfache Website kürzer.

Phase 1: Zugänge stabilisieren und einlesen

Der neue Partner erhält Lesezugriff, prüft den Code, richtet eigene lokale und Staging-Umgebungen ein und liest die Betriebshandbücher. In der Produktion ändert sich nichts. Ihr Ziel: Der neue Partner kann die drei riskantesten Teile des Systems benennen.

Phase 2: Parallelbetrieb

Der neue Partner beginnt mit kleinen Änderungen, nach Möglichkeit vom bisherigen Team überprüft. Die Verantwortung wandert schrittweise: zuerst Staging, dann Deployments, dann die Störungsbehebung. Führen Sie eine kurze Liste mit allem, was dem neuen Partner unklar ist, und klären Sie das mit dem alten Team, solange es noch erreichbar ist.

Phase 3: Umschaltung

Der neue Partner verantwortet Releases und Störungen. Wechseln Sie die verbleibenden Secrets, entziehen Sie die alten Zugänge und stellen Sie die Supportbedingungen auf die neuen Servicelevel um. Halten Sie den alten Dienstleister für eine definierte Zeit für Rückfragen erreichbar, schriftlich festgehalten in Ihrer Ausstiegsvereinbarung.

Das Geschäft während des Wechsels schützen

• Frieren Sie nicht zwingende Releases in den Tagen um die Umschaltung ein.
• Erstellen Sie ein vollständiges Backup und testen Sie die Wiederherstellung, bevor Zugänge geändert werden.
• Sagen Sie Ihrem Supportteam, wen es während der Übergabe anrufen soll.
• Legen Sie die Umschaltung nicht auf Ihre umsatzstärksten Tage.

Bestätigen, dass der neue Partner das Produkt tragen kann

Eine abgehakte Checkliste beweist, dass Dokumente den Besitzer gewechselt haben. Sie beweist nicht, dass das neue Team das Produkt betreiben kann. Nutzen Sie stattdessen Tests mit echtem Ergebnis:

1. Deployment-Test: Der neue Partner bringt eine kleine Änderung ohne Hilfe des alten Dienstleisters in die Produktion.
2. Wiederherstellungstest: Er bringt das System aus dem Backup in einer sauberen Umgebung zum Laufen.
3. Störungsübung: Er beschreibt anhand des Betriebshandbuchs, wie er auf eine ausgefallene Zahlungsintegration oder einen Datenbankausfall reagieren würde.
4. Zugangsprüfung: Sie können jede Person mit Zugang auflisten, und der bisherige Dienstleister taucht nirgends mehr auf.
5. Dokumentationsprüfung: Eine falsche oder fehlende Dokumentation wurde vom neuen Partner während des Prozesses korrigiert.

Halten Sie nach der Abnahme nach 30 und nach 90 Tagen einen Rückblick. Vergleichen Sie mit Ihren ursprünglichen Wechselgründen: Liefergeschwindigkeit, Fehler, Kommunikation, Kosten. Lösen Sie Probleme, solange die Beziehung jung ist.

Wie wir als neuer Partner einsteigen

Ampersand ist ein kleines Zürcher Studio, und erfahrene Entwickler:innen bleiben vom ersten Gespräch bis zur Übergabe beteiligt. So vermeiden wir umgeschriebene Anforderungen und Personalwechsel mitten im Projekt, und Sie bleiben in der Lage, Ihr eigenes Produkt zu betreiben, statt gebunden zu sein. Wenn Sie ein Produkt von einem anderen Dienstleister übernehmen, unterstützen wir Sie bei Audits, bei der Migration von Altsystemen, mit Beratung und mit laufendem Support. Unser Guidance-Plan für erfahrene technische Beratung kostet CHF 799 pro Monat. Die Optionen finden Sie auf unserer Preisseite oder starten Sie auf unserer Startseite.

Häufige Fragen

Wie lange dauert das Onboarding eines neuen Entwicklungspartners?

Das hängt von der Grösse des Systems ab. Eine einfache Website kann in ein paar Wochen übergeben sein, eine komplexe Plattform mit vielen Integrationen braucht bis zu rund drei Monate gestaffelten Übergang. Planen Sie eine Parallelphase statt einer harten Umschaltung und definieren Sie das Ende über Tests mit echtem Ergebnis, etwa ein eigenständiges Deployment in die Produktion.

Was gehört in eine Checkliste für den Partnerwechsel?

Mindestens: vollständige Repositories mit Historie, Kontoinhaberschaft, gewechselte Zugangsdaten, Dokumentation zu Infrastruktur und Backups, Betriebshandbücher, eine Durchsprache des offenen Backlogs sowie unterzeichnete Dokumente zu Urheberrecht und Datenbearbeitung. Jeder Punkt braucht eine verantwortliche Person und eine Möglichkeit, die Erledigung zu prüfen.

Gehört mir der Code, den die frühere Agentur für mich geschrieben hat?

Nicht automatisch. Nach Schweizer Recht geht das Urheberrecht an individuell entwickelter Software nicht allein deshalb auf Sie über, weil Sie dafür bezahlt oder den Quellcode erhalten haben. Prüfen Sie Ihren Vertrag auf eine ausdrückliche Übertragung oder Nutzungslizenz und lassen Sie die Lage von einer Anwältin oder einem Anwalt bestätigen, bevor der neue Partner beginnt.

Was tun, wenn der alte Dienstleister nicht kooperiert?

Beginnen Sie mit dem, was Ihr Vertrag verlangt: Übergabepflichten, Kündigungsfristen und Herausgabe des Codes. Sichern Sie die Konten, die Ihnen direkt gehören, etwa Domain und Hosting, und überlassen Sie strittige Punkte Ihrer Rechtsberatung. Lassen Sie den neuen Partner zuerst den Code prüfen, damit Sie vor den Verhandlungen wissen, was fehlt.

Quellen

• Wicki Partners
• copyright in software is not automatically transferred to the commissioning party
• University of Geneva analysis of the ruling
• vendor handover checklist from Trio
• 90-day transition plan published by Howdy