Software an Kunden übergeben: Checkliste für Agenturen

Was gehört in eine Software-Übergabe?

Eine brauchbare Übergabe beantwortet für jeden Bestandteil drei Fragen: Wer übernimmt ihn, was wurde nachgewiesen und was bleibt offen? Ein Repository-Link und eine Liste von Passwörtern beantworten das nicht. Die folgenden acht Punkte bilden den Kern:

1. Umfang: Anwendung, übergebene Version, Umgebungen und ausdrücklich ausgenommene Leistungen.
2. Code: Repository, Build, Tests, Veröffentlichung, Datenbankmigrationen und dokumentierter Rückweg.
3. Konten: Inhaber, Administration, Vertretung und Rechnungsempfänger für alle Dienste und Domains.
4. Zugriffe: Persönliche Konten, Rollen, maschinelle Zugänge, Geheimnisverwaltung und Entzug alter Berechtigungen.
5. Daten: Sicherungsumfang, Wiederherstellungsanleitung und ein protokollierter Restore.
6. Betrieb: Updates, Überwachung, Störungen, Kontaktwege und vereinbarte Betreuungszeiten.
7. Kosten: Laufende Dienste, verbrauchsabhängige Posten, Verlängerungen und Zuständigkeit für Budgetwarnungen.
8. Freigabe: Ergebnis der Übergabeprobe, offene Punkte, Verantwortliche und nächste Termine.

Die editierbare Übergabe-Checkliste als Markdown herunterladen. Sie lässt sich ohne Anmeldung in einem Texteditor bearbeiten oder in Ihr Projekt-Wiki übernehmen. Enthalten sind ein Diensteregister, eine Prüfliste, ein Probenprotokoll und ein Register für Ausnahmen. Tragen Sie dort Nachweise und Verweise auf geschützte Ablagen ein, keine Geheimnisse oder Kundendatensätze.

Die Vorlage steht unter der MIT-Lizenz und darf für eigene Kundenprojekte verwendet, angepasst und weitergegeben werden. Der Copyright- und Lizenzhinweis ist dabei beizubehalten.

Die Vorlage dokumentiert eine technische Betriebsübergabe. Vertragsumfang und rechtliche Abnahme werden hier nicht geregelt. Die weitergehende Sicherheitsprüfung einer Anwendung behandelt unser Leitfaden zum sicheren Betrieb von Vibe-Coding-Anwendungen.

Den Umfang und die Verantwortung festhalten

Benennen Sie zuerst die genaue Lieferung: Anwendung und Version, Quellcode-Stand, Produktions- und Testumgebung, Datenbank, Dateispeicher, Anmeldung, E-Mail, Jobs und angebundene APIs. Ergänzen Sie, welche Teile weiterhin bei der Agentur oder einem anderen Dienstleister liegen. Ein statisches Frontend kann fertig übergeben sein, während sein Backend noch an einem privaten Agenturkonto hängt.

Unterscheiden Sie fachliche Verantwortung beim Kunden, technische Betriebsverantwortung und die Befugnis zur Freigabe einer Änderung. Die Agentur kann weiter betreuen; ebenso kann die IT des Kunden oder ein anderer Betreiber übernehmen. Entscheidend ist die Zuordnung jeder Aufgabe einschließlich einer Vertretung.

Nachweis: Ein gemeinsames Diensteregister nennt zu jedem Bestandteil den Kontoinhaber, den zuständigen Betreiber und die verantwortliche Person. Der Empfänger bestätigt mit seinem eigenen Konto, dass er die für seine Aufgabe benötigten Informationen erreicht. „Liegt irgendwo bei der Agentur“ bleibt ein offener Punkt.

Code und Veröffentlichung nachvollziehbar übergeben

Übergeben Sie den Quellcode mit Versionshistorie, Abhängigkeitsdateien, Build-Anleitung und Konfigurationsbeispielen ohne Geheimnisse. Halten Sie fest, welche Laufzeit- und Werkzeugversionen zum übergebenen Stand gehören und wie Build, Tests und Bereitstellung ausgelöst werden. Zu einem Datenbankprojekt gehören außerdem die Migrationen und deren Reihenfolge.

Der Empfänger soll von einem frischen Arbeitsverzeichnis oder dem vorgesehenen Build-System aus einen geprüften Stand erzeugen können. Der Beleg verbindet Commit oder Release, erzeugtes Artefakt und tatsächlich bereitgestellte Version. Vorhandene Lizenzhinweise und die Liste eingebundener Komponenten bleiben Teil der Lieferung.

Ein Repository-Transfer erledigt die Zugriffsbereinigung nicht automatisch. GitHub dokumentiert beispielsweise, dass Webhooks, Secrets und Deploy Keys beim Transfer verbunden bleiben; der bisherige Inhaber bleibt als Mitwirkender hinzugefügt. Prüfen Sie deshalb nach dem Wechsel die tatsächlichen Berechtigungen und Integrationen Ihres Anbieters. Quelle: GitHub, Repository übertragen.

Nachweis: Der künftige Betreiber erstellt und veröffentlicht den vereinbarten Stand in der Testumgebung. Ein Rückwechsel wird separat geprüft. Bei Datenbankänderungen muss feststehen, welche Anwendungsversion zum Schema passt; der Rückwechsel von Dateien macht eine Migration nicht rückgängig.

Konten, Domains und Zugänge zuordnen

Erfassen Sie mehr als den Hosting-Login: Domainregistrar, DNS, Zertifikate, Build-System, Laufzeit, Datenbank, Dateien, Identitätsdienst, E-Mail, Überwachung und gegebenenfalls KI- oder Zahlungsdienste. Notieren Sie auch, wer eine Rechnung erhält, Verlängerungen bestätigt und den Anbieter bei Problemen kontaktieren darf.

Eine Domain hat mehrere Zuständigkeiten. Der Domaininhaber, das Registrarkonto, die DNS-Verwaltung und der Anwendungsbetreiber können verschieden sein. Dokumentieren Sie diese Aufteilung. Vor einer Änderung sichern Sie den aktuellen DNS-Stand und berücksichtigen auch Mail- und Verifizierungseinträge, die nicht zur Website gehören.

Für Menschen sind nachvollziehbare persönliche Zugänge mit passenden Rollen vorzusehen. Dienstkonten und automatisierte Deployments erhalten eigene Verantwortliche. Klären Sie die Wiederherstellung eines Administrationszugangs, falls die bisher zuständige Person ausscheidet. Ein funktionierender Agentur-Login ist kein Nachweis dafür, dass der Kunde selbst handlungsfähig ist.

Nachweis: Die empfangende Person meldet sich selbst an, sieht die richtigen Projekte und erreicht Einstellungen und Abrechnungsinformationen entsprechend ihrer Aufgabe. Agenturzugänge bleiben nur dort bestehen, wo eine weitere Betreuung ausdrücklich vorgesehen und dokumentiert ist.

Zugangsdaten übertragen, ohne sie offenzulegen

In das Protokoll gehören Zweck, zuständiger Dienst und ein Verweis auf die geschützte Geheimnisablage. Passwörter, private Schlüssel, Wiederherstellungscodes und Tokens bleiben außerhalb von Checklisten, Tickets und Screenshots. Gewähren Sie dem Empfänger den benötigten Zugriff auf die dafür vorgesehene Ablage und prüfen Sie ihn gemeinsam.

Für nicht mehr benötigte Zugänge wird der Entzug dokumentiert. Bei gemeinsam genutzten maschinellen Zugangsschlüsseln planen Sie Ersatz, Funktionstest und Widerruf des alten Schlüssels als zusammengehörigen Vorgang. Prüfen Sie abhängige Jobs und Integrationen mit. Schlüssel zum Entschlüsseln vorhandener Daten oder Backups dürfen dabei nicht mit austauschbaren Zugriffstokens verwechselt werden.

OWASP behandelt Geheimnisse als Lebenszyklus mit Berechtigungen, Erneuerung, Widerruf und Wiederherstellung. Für die Übergabe bedeutet das: Der Empfänger muss nicht nur an ein benötigtes Geheimnis kommen, sondern auch dessen Einsatz und Entzug beherrschen. Quelle: OWASP, Secrets Management.

Nachweis: Ein eigens für die Probe eingerichteter Zugang funktioniert vor dem Entzug und nach dem vereinbarten Wirksamkeitsfenster nicht mehr. Prüfen Sie dabei auch bestehende Sitzungen oder Tokens. Erfasst werden Zeitpunkt, betroffener Dienst und Ergebnis, nicht der geheime Wert. Produktive Berechtigungen werden nach dem abgestimmten Übergabeplan geändert.

Backups durch einen Restore belegen

Erfassen Sie gemeinsam, was gesichert wird: Datenbank, hochgeladene Dateien, notwendige Konfiguration und benötigtes Schlüsselmaterial. Eine gesicherte Datenbank enthält nicht automatisch die separat gespeicherten Anhänge. Für PostgreSQL beschreibt die offizielle Dokumentation unterschiedliche Sicherungswege, darunter SQL-Dumps, Dateisicherungen und kontinuierliche Archivierung. Der konkrete Wiederherstellungsweg muss zu Ihrem gewählten Verfahren passen. Quelle: PostgreSQL 18, Backup and Restore.

Der Kunde benennt den tolerierbaren Datenverlust und die benötigte Wiederanlaufzeit. Diese Ziele werden mit dem gewählten Verfahren abgeglichen. Die Größe einer Sicherungsdatei oder ein grüner Backup-Job belegt noch nicht, dass die Anwendung danach wieder arbeitet.

1. Der künftige Betreiber wählt einen dokumentierten Sicherungsstand und stellt ihn in einer isolierten, dafür freigegebenen Umgebung wieder her.
2. Ausgehende E-Mails, Webhooks, Zahlungen und produktive Hintergrundjobs bleiben dort unterbunden. Die Daten und Zugänge der Probe sind dafür ausdrücklich freigegeben.
3. Er prüft einen vereinbarten Datensatz, den zugehörigen Anhang und einen typischen Arbeitsablauf. Zeitpunkte und tatsächlich erreichter Datenstand werden festgehalten.
4. Abweichungen von den Wiederherstellungszielen und die anschließende Bereinigung der Testumgebung erhalten einen Verantwortlichen.

Nachweis: Sicherungsreferenz, verwendete Anleitung, prüfende Person, beobachtete Dauer, geprüfte Daten und Ergebnis sind miteinander verknüpft. Ein Deployment-Rollback ist ein eigener Vorgang und ersetzt diesen Nachweis nicht.

Updates, Störungen und Kosten organisieren

Benennen Sie, wer Meldungen zu Sicherheitslücken und neuen Versionen bearbeitet, ihre Bedeutung für die Anwendung bewertet und Änderungen testet. Ein Scanner allein aktualisiert keine Anwendung. OWASP unterscheidet die Erkennung verwundbarer Abhängigkeiten von ihrer Behandlung. Quelle: OWASP, Vulnerable Dependency Management.

Legen Sie einen Termin für die nächste reguläre Überprüfung und einen gesonderten Weg für dringende Meldungen fest. Das Protokoll nennt die zuständige Person, benötigte Freigaben, Testumgebung und den Rückweg. Automatische Updates entbinden nicht davon, fehlgeschlagene Änderungen zu bemerken und zu bearbeiten.

Der Störungsweg braucht eine erreichbare Erstansprechperson und eine Vertretung. Halten Sie fest, wer eine Anwendung einschränken darf, wer technische Diagnose übernimmt und wer den Kunden informiert. NIST ordnet Vorbereitung, Reaktion und Wiederherstellung in ein gemeinsames Vorgehen für Sicherheitsvorfälle ein. Quelle: NIST SP 800-61 Revision 3.

Trennen Sie außerdem laufende Anbieterrechnungen von der Betreuung durch eine Agentur. Die Kostenübersicht enthält Dienst, Rechnungsempfänger, Abrechnungsmodell, nächste Verlängerung sowie Verantwortliche für Budgetwarnungen und Änderungen. Tragen Sie die tatsächlich vereinbarten Werte ein. Eine offene technische Frage verschwindet nicht dadurch, dass eine Rechnung bereits bezahlt ist.

Nachweis: Ein angekündigter Testalarm erreicht die richtige Person über den vereinbarten Kanal. Für die Probe wird festgehalten, wer ihn angenommen hat und welcher nächste Schritt vorgesehen war. Betreuungszeiten werden ausdrücklich benannt; die Liste impliziert keine Rund-um-die-Uhr-Bereitschaft.

Die Übergabe gemeinsam proben

Die empfangende Person führt aus, die Agentur beobachtet. Nutzt sie heimlich ein eigenes Administrationskonto oder ergänzt einen undokumentierten Schritt, ist genau das ein Befund. Planen Sie die Probe auf einer freigegebenen Testumgebung; produktive Umschaltungen erfolgen separat nach dem vereinbarten Verfahren.

1. Starten: Mit dem eigenen Konto die Anleitung, die getestete Version und die benötigten Dienste finden.
2. Veröffentlichen: Eine harmlose, erkennbare Änderung erstellen, die vorgesehenen Prüfungen ausführen und sie bereitstellen.
3. Nachvollziehen: Die ausgelieferte Version und den zugehörigen Protokolleintrag identifizieren. Einen vereinbarten Testalarm zuordnen.
4. Zurückkehren: Den dokumentierten Rückweg ausführen und den Anwendungstest wiederholen. Datenbankschema und Datenstand dabei ausdrücklich berücksichtigen.
5. Wiederherstellen: Die beschriebene Restore-Probe mit Daten und Dateien durchführen, falls sie nicht bereits als eigener Termin dokumentiert ist.
6. Zugriff entziehen: Einen temporären Testzugang entfernen und die erwartete Wirkung überprüfen. Verbleibende Agenturzugänge mit der vorgesehenen Betreuung abgleichen.

Für jeden Schritt werden Erwartung und Beobachtung getrennt notiert. „Veröffentlichung möglich“ ist die Erwartung. „Mit Konto [Rolle] wurde Release [Referenz] in Umgebung [Name] bereitgestellt; Protokoll [Link]“ ist ein auszufüllender Nachweis. Fehlende Beobachtungen bleiben offen.

Die Rechteprüfung der eigentlichen Anwendung ist ein eigener Nachweis. Für ein Supabase-Projekt hilft die Anleitung zum Testen von RLS; für Mitarbeitende und Partner im CRM der Beitrag Internes CRM absichern. Eine gelungene Veröffentlichungsprobe ersetzt diese Prüfungen nicht.

Ein fiktives Serviceportal als Beispiel

Illustratives Beispiel, kein Kundenfall: Eine Agentur übergibt ein Serviceportal an die IT eines Handwerksbetriebs. Das Frontend liegt bei einem Hostinganbieter, Vorgänge in einer Datenbank, Anhänge in einem Dateispeicher. Ein separater Dienst versendet Benachrichtigungen.

Nehmen wir an, die empfangende Person kann die Testversion veröffentlichen. Beim Restore fehlen jedoch die Anhänge, und die Rechnung des Maildienstes geht weiterhin an eine ausscheidende Agenturmitarbeiterin. Dann wäre „Software übergeben“ als Gesamtstatus irreführend. Die Veröffentlichung wäre belegt; Datenwiederherstellung und Kontozuordnung blieben offen.

In der Vorlage entstehen zwei eigene Punkte: Sicherungsumfang um Dateien ergänzen und Restore wiederholen; Kontoinhaber und Abrechnung des Maildienstes klären. Beide bekommen eine zuständige Person, einen Termin und ein Kriterium für den Abschluss. Die vorgesehenen Ergebnisse sind Beispiele. Es wurden für diesen Beitrag weder diese Probe durchgeführt noch Zeiten gemessen.

Offene Punkte und Betriebsfreigabe dokumentieren

Verwenden Sie eindeutige Zustände: offen, in Arbeit, nachgewiesen oder nicht anwendbar mit Begründung. Ein geplanter Test ist kein Nachweis. Bei einer Ausnahme bleiben Einschränkung und zuständige Entscheidungsperson sichtbar.

Zu jedem offenen Punkt gehören Auswirkung, betroffener Teilumfang, verantwortliche Person, Zieldatum und Abschlussnachweis. Wenn eine eingeschränkte Nutzung trotzdem vorgesehen ist, halten Sie zulässigen Umfang, vorübergehende Maßnahme und erneuten Prüftermin ausdrücklich fest. Eine fehlende zentrale Betriebsfähigkeit wird durch eine Unterschrift nicht hergestellt.

Die technische Betriebsfreigabe nennt die konkrete Version, Umgebung und den übernommenen Aufgabenbereich. Empfänger und übergebende Seite bestätigen, welche Proben durchgeführt wurden und welche Einschränkungen bleiben. Vereinbaren Sie anschließend den ersten Betreuungstermin und prüfen Sie dort auch, ob temporäre Zugänge und Probedaten entfernt wurden.

Übergabevorlage herunterladen und für Ihr Projekt ausfüllen. Speichern Sie ausgefüllte Fassungen nur in der dafür vorgesehenen internen Projektablage. Für Nachweise genügen geschützte Referenzen; sie müssen nicht öffentlich zugänglich sein.

Ihr Projekt mit obhut besprechen

obhut entwickelt eine Plattform für Agenturen mit Websites, Kundenportalen, SaaS und internen Anwendungen. Statisches Hosting sowie DNS-, TLS-, Proxy- und HTTP-Tunnelgrundlagen sind implementiert. Die Plattform läuft als interner Pilot; die externe Beta ist noch nicht freigegeben. Benutzer-Access, WAF und Rate Limits für Kundenanwendungen sowie eigene Server-Laufzeiten sind geplant.

Die Agenturübersicht grenzt diese Bausteine voneinander ab. Eine Anbindung übernimmt nicht automatisch die Sicherung einer Kundendatenbank oder die Wartung des Anwendungscodes. Für ein Gespräch über Ihr Kundenprojekt nennen Sie Anwendung, heutigen Betrieb, vorgesehenen Betreiber und den offenen Übergabeschritt. Zugangsdaten oder Kundendaten werden dafür nicht benötigt.