Ratgeber
Software-Übergabe: Was in einem sauberen Übergabeprotokoll steht
Quellstand, Server, Zugänge, Lizenzhinweis, Drittkomponenten, Prüfnachweise: die Liste zum Abhaken, und daneben das, was ausdrücklich nicht übergeben wird.
Stand: 18. August 2026 · MCP Baldux
Zu einer sauberen Software-Übergabe gehören der kundenspezifische Quellstand in Ihrem eigenen Verzeichnis, ein Hosting-Vertrag auf Ihren Namen, sämtliche Zugangsdaten bei Ihnen, die eingesetzte Framework-Version mit Lizenzhinweis, eine Liste der Drittkomponenten und die Prüfnachweise. Nicht übergeben werden die Entwicklungsplattform, die Engine und interne Zugangsschlüssel des Anbieters.
Was bei der Software-Übergabe an Sie geht
Die Frage hinter der Übergabe lautet nicht „bekomme ich den Code“, sondern: Könnten wir morgen ohne diesen Anbieter weiterarbeiten? Daran gemessen sind sechs Gegenstände entscheidend, und sie liegen an unterschiedlichen Orten.
| Gegenstand | Wo er liegt | Woran Sie ihn erkennen |
|---|---|---|
| Kundenspezifischer Quellstand | in Ihrem eigenen GitHub-Konto | Sie können ihn ohne Rückfrage herunterladen und einem Dritten geben. |
| Server und Betrieb | Hosting-Vertrag auf Ihren Namen | Die Rechnung des Rechenzentrums kommt zu Ihnen, nicht zu uns. |
| Zugangsdaten | bei Ihnen | Sie melden sich überall selbst an, ohne uns zu fragen. |
| Framework-Version | in Ihrer Anwendung eingebettet | Version und Lizenzhinweis sind schriftlich festgehalten. |
| Drittkomponenten | Liste zur Anwendung | Jede Fremdbibliothek mit Version und Lizenz, nachlesbar. |
| Prüfnachweise | Belegkette zur gebauten Fassung | Je Schritt: was geändert wurde, wer geprüft hat, mit welchem Ergebnis. |
Der zweite Punkt wird oft unterschätzt. Wenn der Server auf den Namen des Dienstleisters läuft, hängt der Betrieb an dessen Vertragsverhältnis, und eine Trennung wird zur Umzugsaktion. Läuft er auf Ihren Namen, ist eine Trennung ein Wechsel des Ansprechpartners.
Was nicht übergeben wird, und warum
Ebenso wichtig wie die Liste oben ist die Gegenliste. Ein Anbieter, der alles verspricht, verspricht auch das, was er nicht halten kann; ein Anbieter, der die Grenze schriftlich zieht, macht sie überprüfbar.
- Die Entwicklungsplattform. Sie ist das Werkzeug, mit dem gebaut wird, und kein Teil des Ergebnisses.
- Die Engine mit ihren Prüfrollen, Regelwerken und Abläufen. Ihr Ergebnis bekommen Sie, sie selbst bleibt beim Anbieter.
- Interne Zugangsschlüssel und Modellkonten des Anbieters. Schlüssel, die Ihre Anwendung dauerhaft für den Betrieb braucht, werden davon getrennt und Ihnen zugeordnet.
Für das Framework unter Ihrer Anwendung gilt eine eigene Regel, und sie steht auf allen unseren Seiten gleichlautend:
Ihre Anwendung gehört Ihnen: Sie nutzen sie, betreiben sie, lassen sie weiterentwickeln, hosten sie selbst oder lassen hosten. Das Baldux-Framework darunter bleibt unser Eigentum und ist für genau diese Anwendung unbefristet lizenziert — kein Weiterverkauf, keine Unterlizenz, kein Herauskopieren, keine Nutzung in anderen Projekten, auch nicht durch andere Agenturen oder Ihre Mitarbeitenden. Änderungen am Framework fallen an Baldux; die Entwicklungsplattform und die Engine werden nie ausgeliefert. Einzelheiten: AGB Ziffer 12–17 und /lizenz.
Praktisch heißt das: Sie dürfen Ihre Anwendung selbst betreiben, verändern und von einer anderen Agentur weiterentwickeln lassen. Was diese Agentur nicht darf, ist das Framework herauslösen und in einem anderen Projekt verwenden. Änderungen, die jemand direkt am Framework vornimmt, fallen an Baldux zurück; im Gegenzug dürfen Sie sie in Ihrer Anwendung dauerhaft weiter nutzen.
Das Übergabeprotokoll: zehn Punkte zum Abhaken
Ein Übergabeprotokoll ist kein Formalismus, sondern die Stelle, an der beide Seiten dasselbe Verständnis unterschreiben. Diese zehn Punkte decken den üblichen Fall ab.
- Quellstand: Verzeichnis, Zweig, Versionsstand, wer Zugriff hat.
- Betrieb: Anbieter, Vertragspartner, Standort, Ansprechpartner für Störungen.
- Zugänge: Liste aller Konten und Schlüssel, mit dem Hinweis, wer sie zuletzt gewechselt hat.
- Framework: eingesetzte Version, Lizenzhinweis und die Fundstelle der Lizenzbedingungen.
- Drittkomponenten: Name, Version, Lizenz, Zweck.
- Datenbank: Schema, Migrationsstand, Sicherungsverfahren und Rückspielprobe.
- Prüfnachweise: Belegkette der ausgelieferten Fassung und die Kennzeichnung des geprüften Standes.
- Abnahme: welche Kriterien geprüft wurden und mit welchem Ergebnis.
- Bekannte Einschränkungen: offene Punkte, bewusst nicht Gebautes, Nicht-Ziele.
- Betriebsanleitung: wie die Anwendung neu aufgesetzt, gestartet und aktualisiert wird.
Punkt sieben ist der, an dem sich Anbieter unterscheiden. Ein Nachweis, aus dem sich Einträge entfernen lassen, belegt nichts; ein Merkmal am geprüften Stand macht spätere Abweichungen sichtbar, ohne sie zu unterbinden.
Nach der Übergabe: Betrieb, Pflege, Weiterentwicklung
Mit der Übergabe endet die Zusammenarbeit nicht zwangsläufig, aber sie wird freiwillig. Genau das ist der Punkt: Pflege und Weiterentwicklung laufen bei uns über ein Monatsabo, wenn Sie wollen. Wollen Sie nicht, läuft Ihre Anwendung weiter, weil Zugänge, Quellstand und Server bereits bei Ihnen liegen.
Drei Dinge lohnen sich unabhängig vom weiteren Weg. Erstens eine Rückspielprobe: Eine Sicherung, die noch nie zurückgespielt wurde, ist eine Vermutung. Zweitens ein benannter Zuständiger auf Ihrer Seite, auch wenn er selbst nicht entwickelt. Drittens ein fester Termin, an dem Abhängigkeiten aktualisiert werden, denn Fremdbibliotheken altern unabhängig von Ihrer Anwendung.
Und wenn Sie den Anbieter wechseln: Die Übergabeliste von oben ist zugleich die Einarbeitungsliste für den Nachfolger. Wer sie vollständig bekommt, braucht keine Rückfrage bei uns, um loszulegen.
Häufige Fragen zur Software-Übergabe
Was gehört zu einer vollständigen Software-Übergabe?
Der kundenspezifische Quellstand in Ihrem Verzeichnis, ein Hosting-Vertrag auf Ihren Namen, alle Zugangsdaten, die eingesetzte Framework-Version mit Lizenzhinweis, eine Liste der Drittkomponenten mit Lizenzen, die Prüfnachweise und eine Betriebsanleitung samt bekannten Einschränkungen.
Wem gehört die fertige Anwendung?
Ihre Anwendung gehört Ihnen: Sie nutzen sie, betreiben sie, lassen sie weiterentwickeln, hosten sie selbst oder lassen hosten. Das Baldux-Framework darunter bleibt unser Eigentum und ist für genau diese Anwendung unbefristet lizenziert — kein Weiterverkauf, keine Unterlizenz, kein Herauskopieren, keine Nutzung in anderen Projekten, auch nicht durch andere Agenturen oder Ihre Mitarbeitenden. Änderungen am Framework fallen an Baldux; die Entwicklungsplattform und die Engine werden nie ausgeliefert. Einzelheiten: AGB Ziffer 12–17 und /lizenz.
Darf eine andere Agentur die Anwendung weiterentwickeln?
Ja. Sie dürfen eigene Mitarbeitende und externe Dienstleister mit Betrieb, Wartung und Weiterentwicklung beauftragen. Der Dienstleister arbeitet dabei als Ihre Hilfsperson und erhält kein eigenes Recht am Framework; für andere Mandanten oder eigene Produkte darf er es nicht verwenden.
Bekomme ich auch die Engine oder die Entwicklungsplattform?
Nein. Sie erhalten das Ergebnis, nicht das Werkzeug. Entwicklungsplattform, Engine, interne Regelwerke und Anbieter-Schlüssel bleiben bei Baldux; Schlüssel, die Ihre Anwendung für den Betrieb braucht, werden davon getrennt und Ihnen zugeordnet.
Was passiert mit meiner Anwendung, wenn wir die Zusammenarbeit beenden?
Sie läuft weiter. Server, Zugänge und Quellstand liegen ohnehin bei Ihnen, und die Lizenz für das eingebettete Framework ist unbefristet. Was endet, sind die Zugänge zu unseren Entwicklungsfunktionen wie dem Einreichen und dem Kundenbereich.
Wie lange sollte ich die Prüfnachweise aufbewahren?
So lange, wie Sie den Nachweis über die Entstehung der Anwendung brauchen könnten, üblicherweise mindestens über die Lebensdauer der Fassung im Betrieb. Ob für Ihr Haus längere Aufbewahrungsfristen gelten, klärt Ihre Rechtsabteilung oder eine Kanzlei; dieser Artikel ist eine Einordnung und keine Rechtsberatung.