Agenturwechsel: Übergabeprotokoll für Kundenwebsites

Woran eine Übergabe scheitert

Die Trennung selbst ist selten das Problem. Das Problem ist die Lücke zwischen dem letzten Arbeitstag der bisherigen Agentur und dem ersten der neuen. In dieser Lücke laufen Verträge weiter, Zertifikate laufen ab, Mahnungen erreichen einen Empfänger, der nicht mehr zuständig ist, und für die Domain fühlt sich niemand verantwortlich. Streitig wird am Ende fast nie die Gestaltung, sondern die Kontrolle über Zugänge: Wer kann die Domain umziehen, wer kann das Zertifikat erneuern, wer kommt an die Datenbank. Ein Protokoll, das jede dieser Positionen mit Datum, Empfänger und Bestätigung festhält, kostet einen halben Tag und beendet die Diskussion, bevor sie anfängt.

Der häufigste Auslöser ist eine Registrierung, die vor Jahren aus Bequemlichkeit gelaufen ist: Die Agentur hat die Domain auf den eigenen Namen eintragen lassen, weil das schneller ging als eine Vollmacht. Solange das Verhältnis trägt, fällt es niemandem auf. Bei der Trennung steht plötzlich die Frage im Raum, wem der Name gehört. Dieselbe Frage entsteht bei Zertifikaten, bei Konten für Versanddienste und bei jedem Werkzeug, das die Agentur im eigenen Konto für den Kunden betreibt. Wer wissen will, wie knapp die Fristen dabei sind, findet die Zahlen im Beitrag über Domainablauf und Verlängerungsfristen.

• Domain und AuthInfo - Inhaber laut Registerdatenbank, zuständiger Provider, AuthInfo, geplantes Umzugsdatum.
• DNS-Zonendatei - jeder Eintrag im Klartext, samt Zeitspanne bis zum Ablauf, Mailrouten und Prüfeinträgen für den Mailversand.
• Hosting und Datenbank - Servername, Zugang für die Dateiablage, Datenbankauszug mit Datum, Zeitpunkt der letzten Sicherung.
• Quellcode und Bauweg - Ablageort des Quelltextes, Zugang dazu, Bauanleitung, Abhängigkeiten, Anleitung für eine Auslieferung von Hand.
• Zertifikate und private Schlüssel - Aussteller, Ablaufdatum, Erneuerungsweg, Ablageort des privaten Schlüssels.
• Konten bei Diensten - Mailversand, Zahlungsanbieter, Kartendienst, Suchkonsole: je Konto der Inhaber und der Weg, ihn zu wechseln.
• Messdaten und Berichte - Reichweitendaten, Verfügbarkeitsreihen, Bildschirmfotos, Berichtsarchiv, jeweils mit Ausgabeformat.
• Löschnachweis - was nach der Übergabe beim bisherigen Dienstleister gelöscht wird, wann, und wer das bestätigt.

Jede dieser acht Positionen hat drei mögliche Zustände: übergeben, ausdrücklich beim bisherigen Dienstleister verblieben oder nicht vorhanden. Der dritte Zustand ist der wichtigste, denn er verhindert, dass die Nachfolge Wochen später nach etwas sucht, das es nie gab. Wer die Zugänge ohnehin je Kunde trennt, hat diese Liste beinahe fertig im System stehen; wie eine solche Trennung samt Protokoll aussieht, beschreibt der Beitrag über Zugriffsrechte, Rollen und Protokoll im Team.

Die Domain und die AuthInfo

Der Umzug einer .de-Domain läuft über die AuthInfo, ein Kennwort, das der abgebende Provider erzeugt und beim Register hinterlegt. Die Vorgaben dafür sind eng: Die AuthInfo muss zwischen 8 und 16 Zeichen lang sein, und nicht erlaubt sind die Zeichen I, l, O, o, 0 und 1, weil sie sich in gedruckter Form zu leicht verwechseln lassen (DENIC). Das klingt nach einer Randnotiz, ist aber der häufigste Grund für einen gescheiterten ersten Versuch: Der Code wird am Telefon durchgegeben, aus einer Eins wird ein kleines L, und der Antrag läuft in einen Fehler, den beide Seiten dem jeweils anderen zuschreiben. In das Protokoll gehört die AuthInfo darum nicht als Zuruf, sondern als Datei.

Zwei weitere Eigenschaften sind für die Zeitplanung entscheidend. Erstens speichert das Register nur eine verschlüsselte Version der AuthInfo, nicht das Kennwort im Klartext (DENIC) - eine verlorene AuthInfo lässt sich also nicht nachschlagen, sondern nur neu erzeugen. Zweitens verfällt der Code nach 30 Tagen automatisch und muss dann neu angefordert werden (DENIC). Wer die AuthInfo im November anfordert und den Umzug auf Januar legt, beginnt von vorn. Stimmt die AuthInfo dagegen mit dem hinterlegten Wert überein, zieht die Domain sofort um (DENIC); zwischen dem Antrag der neuen Agentur und dem Wechsel der Zuständigkeit liegt dann keine Wartezeit, in der etwas geklärt werden könnte.

TRANSIT und die Frist nach der Löschung

Kündigt der bisherige Provider den Vertrag, ohne dass ein Nachfolger bereitsteht, fällt die Domain nicht ins Nichts. Das TRANSIT-Verfahren ist ein kostenloser Dienst für alle Domaininhaber und schützt vor dem ungewollten Verlust der Domain; die Domain wird nicht sofort gelöscht, sondern vorübergehend direkt vom Register verwaltet und kann von niemand anderem registriert werden (DENIC). Das ist die Schutzschicht, die eine schlecht geplante Trennung vor dem Totalverlust bewahrt - aber sie ist befristet und sie setzt voraus, dass der Inhaber erreichbar ist.

1. Ein Monat für die Entscheidung. Für seine Entscheidung zum Providerwechsel hat der Domaininhaber einen Monat Zeit (DENIC). Das individuelle Datum steht im Brief des Registers, nicht in einer allgemeinen Regel.
2. Erreichbarkeit entscheidet. Lässt sich der Brief nicht zustellen, kündigt das Register den Domainvertrag per E-Mail, und die Domain wird gelöscht (DENIC). Eine veraltete Anschrift ist damit kein Schönheitsfehler, sondern der Weg in die Löschung.
3. 30 Tage nach der Löschung. Eine Domain kann nach der Löschung nur innerhalb von 30 Tagen - der Redemption Grace Period - vom bisherigen Domaininhaber erneut registriert werden; nach Ablauf der Frist steht sie zur Neuregistrierung durch jeden Interessierten zur Verfügung (DENIC).

Diese dritte Frist ist die teuerste im ganzen Ablauf, weil sie still läuft. Niemand bekommt eine Erinnerung, und der Verlust fällt erst auf, wenn die Adresse im Browser ins Leere zeigt oder die Mails nicht mehr ankommen. In das Übergabeprotokoll gehören deshalb nicht nur Zugänge, sondern drei Daten: der Tag des Umzugs, der Tag, an dem der alte Vertrag endet, und der Tag, an dem die Zuständigkeit für die Verlängerung auf die neue Agentur übergeht. Wer diese Daten überwacht statt sie zu notieren, sieht eine Lücke, bevor sie eine Frist wird - dazu gehört auch die Überwachung von Domain- und DNS-Einträgen im laufenden Betrieb.

Der Auth-Code ist kein Druckmittel

In der Praxis wird die AuthInfo regelmäßig als Pfand behandelt: erst die offene Rechnung, dann der Code. Die Rechtslage gibt das nicht her. Wer eine Domain im Auftrag eines Kunden registriert, handelt in aller Regel als Treuhänder, und für den Beauftragten gilt: Der Beauftragte ist verpflichtet, dem Auftraggeber alles, was er zur Ausführung des Auftrags erhält und was er aus der Geschäftsbesorgung erlangt, herauszugeben (§ 667 BGB). Die Domain und der Zugang dazu sind genau das - etwas, das aus der Geschäftsbesorgung erlangt wurde. Der Herausgabeanspruch hängt nicht daran, auf wessen Namen der Eintrag steht.

Ein Fachbeitrag zum Herausgabeanspruch fasst die höchstrichterliche Linie so zusammen: "Der Bundesgerichtshof hat bereits 2010 entschieden, dass der Agentur als Treuhänderin kein Zurückbehaltungsrecht an der Domain bzw. den Auth-Code zusteht" (Kanzlei Hoesmann). Und weiter: "Diese darf selbst dann nicht die Herausgabe verweigern, wenn sie sich als Domaininhaberin hat eintragen lassen" sowie "Auch etwaige offene Forderungen begründen kein Zurückbehaltungsrecht" (Kanzlei Hoesmann). Für die scheidende Agentur heißt das: Das Zurückhalten des Codes verbessert die Zahlungsaussicht nicht, verlagert aber die Auseinandersetzung von der Rechnung auf das eigene Verhalten - und erzeugt genau die Bewertung, die beim nächsten Pitch mitgelesen wird.

Zugangsinventar: was tatsächlich übergeben wird

Ein Übergabeprotokoll ist kein Textdokument mit guten Absichten, sondern eine Tabelle mit Zeilen, die abgehakt werden. Jede Zeile nennt die Position, die Stelle, an der sie hängt, und das, was der Nachfolger konkret in die Hand bekommt. Der entscheidende Unterschied zu einer Aufzählung im Abschlussgespräch: Die Tabelle zwingt zur Entscheidung, ob eine Position überhaupt existiert. Aus "das macht der Hoster" wird ein Name, aus "das läuft automatisch" ein Erneuerungsweg mit Zuständigkeit.

Die letzte Zeile ist die, die am häufigsten fehlt, und sie ist die einzige, die den bisherigen Dienstleister schützt. Ohne Löschnachweis bleibt offen, ob die Daten des Kunden zwei Jahre später noch auf einem Zweitrechner liegen; mit Nachweis ist die Frage beantwortet, bevor sie gestellt wird. Wie lange welche Messreihe überhaupt aufbewahrt werden sollte, ist ein eigenes Thema und steht im Beitrag über Aufbewahrungsfristen für Monitoring- und Analysedaten.

Daten, Löschfristen und der Nachweis

Sobald die Agentur für den Kunden personenbezogene Daten verarbeitet hat - Besucherdaten, Formularinhalte, Bildschirmfotos aus Bereichen hinter der Anmeldung, Kontaktdaten der Alarmempfänger - endet die Übergabe nicht mit einem Zugang, sondern mit einer Entscheidung. Der Auftragsverarbeiter muss nach Abschluss der Erbringung der Verarbeitungsleistungen alle personenbezogenen Daten nach Wahl des Verantwortlichen entweder löschen oder zurückgeben und die vorhandenen Kopien löschen, sofern nicht nach dem Unionsrecht oder dem Recht der Mitgliedstaaten eine Verpflichtung zur Speicherung besteht (Art. 28 Abs. 3 lit. g DSGVO). Die Wahl trifft der Kunde, nicht die Agentur - und sie gehört schriftlich ins Protokoll, mit Datum.

Was der Vertrag dazu im Einzelnen enthalten muss, ist an anderer Stelle ausführlich beschrieben: Der Beitrag über den Auftragsverarbeitungsvertrag nach Artikel 28 geht die acht Buchstaben der Norm durch. Für die Übergabe zählt davon vor allem der vorletzte: Er beschreibt genau den Tag, an dem die Zusammenarbeit endet, und er ist der einzige Teil des Vertrags, der erst dann gebraucht wird.

Das Protokoll als Dokument

Ein brauchbares Protokoll passt auf wenige Seiten und hat für jede Position dieselben Felder: Bezeichnung, Zustand, Empfänger, Datum, Nachweis. Der Nachweis ist dabei kein Wort, sondern ein Ergebnis - eine Registerabfrage, eine Kopfzeile aus einer Anfrage, ein Ablaufdatum aus dem Zertifikat, eine Dateiliste des Exports. Wer das Protokoll maschinenlesbar führt, kann es am Stichtag gegen die Wirklichkeit prüfen, statt es zu glauben.

{
  "kunde": "Beispiel GmbH",
  "stichtag": "2026-12-31",
  "abgebend": "Agentur A",
  "übernehmend": "Agentur B",
  "positionen": [
    {
      "position": "domain",
      "bezeichnung": "kunde.example",
      "zustand": "übergeben",
      "empfänger": "Agentur B",
      "datum": "2026-12-08",
      "nachweis": "Registerabfrage vom 2026-12-09, Provider gewechselt"
    },
    {
      "position": "zertifikat",
      "bezeichnung": "kunde.example, Wildcard",
      "zustand": "übergeben",
      "empfänger": "Agentur B",
      "datum": "2026-12-08",
      "nachweis": "notAfter=2027-03-14, Erneuerung ab 2027-02-12 bei Agentur B"
    },
    {
      "position": "messdaten",
      "bezeichnung": "Verfügbarkeit und Reichweite 2024-2026",
      "zustand": "zurueckgegeben",
      "empfänger": "Beispiel GmbH",
      "datum": "2026-12-15",
      "nachweis": "Export csv und json, 41 Dateien, Prüfsumme im Anhang"
    },
    {
      "position": "loeschung",
      "bezeichnung": "Kundendaten in den Systemen von Agentur A",
      "zustand": "terminiert",
      "empfänger": "Beispiel GmbH",
      "datum": "2027-01-15",
      "nachweis": "Bestaetigung nach Ablauf der Sicherungen, Rechnungsbelege ausgenommen"
    }
  ],
  "offen": []
}

Das Feld für offene Punkte ist absichtlich das letzte und absichtlich leer. Solange dort etwas steht, ist die Übergabe nicht abgeschlossen, und beide Seiten sehen dieselbe Liste. Ein Protokoll, das offene Punkte verschweigt, liest sich am Stichtag wie Vollständigkeit und wird sechs Wochen später zur Rechnung. Die Erfahrung aus Abnahmen gilt hier genauso: Was nicht gemessen wurde, ist nicht übergeben - dieselbe Logik beschreibt der Beitrag über die Website-Abnahme mit Messprotokoll.

Ein Übergabeprotokoll schützt nicht den, der es verlangt, sondern den, der es schreibt. Wer nachweisen kann, was er übergeben und was er gelöscht hat, diskutiert über Rechnungen und nicht über Vorwürfe.

— XICTRAQ

Rechte an Gestaltung und Quellcode

Zugänge sind die eine Hälfte, Rechte die andere. Ob die Nachfolgeagentur den vorhandenen Entwurf weiterentwickeln darf, entscheidet nicht der Besitz der Dateien, sondern der Umfang der eingeräumten Nutzungsrechte. Sind bei der Einräumung eines Nutzungsrechts die Nutzungsarten nicht ausdrücklich einzeln bezeichnet, bestimmt sich nach dem von beiden Partnern zugrunde gelegten Vertragszweck, auf welche Nutzungsarten es sich erstreckt (§ 31 Abs. 5 UrhG). Im Zweifel bleibt beim Urheber, was er nicht ausdrücklich abgegeben hat - eine Regel, die bei der Trennung zum ersten Mal wehtut.

• Bearbeitungsrecht ausdrücklich nennen. Ein Nutzungsrecht an einem Entwurf ist nicht automatisch das Recht, ihn zu ändern. Ohne diesen Punkt darf die Nachfolge die Seite betreiben, aber nicht umbauen.
• Fremdbestandteile trennen. Schriften, Bilder und zugekaufte Bausteine haben eigene Bedingungen. In das Protokoll gehört je Bestandteil, ob die Lizenz auf den Kunden läuft oder auf die Agentur.
• Eigenentwicklungen benennen. Ein für den Kunden entwickelter Baustein ist etwas anderes als eine allgemeine Bibliothek der Agentur. Beides darf mitgehen - aber nur, wenn geklärt ist, unter welchen Bedingungen.
• Zugang ist kein Recht. Wer den Quelltext herausgibt, gibt damit nicht automatisch das Recht zur Weiterentwicklung; und wer das Recht einräumt, hat deshalb noch keinen lesbaren Bauweg übergeben.

Nachmessen statt zusagen

Der Unterschied zwischen einem Protokoll und einer Behauptung ist die Gegenprobe am Stichtag. Sie dauert wenige Minuten und deckt regelmäßig auf, was in der Übergabe untergegangen ist: ein Namenseintrag, der noch auf den alten Server zeigt, ein Zertifikat, dessen Erneuerung an einem Konto der alten Agentur hängt, ein Mailversand, der über einen Dienst läuft, den niemand erwähnt hat. Gemessen wird von außen, mit denselben Mitteln, die auch der Nachfolge zur Verfügung stehen.

Vier Zeilen, vier Antworten: Wohin zeigt der Name, welche Adresse antwortet, steht die Auslieferung noch, wann läuft das Zertifikat ab. Dieselben Fragen stellen sich danach jeden Tag, nur ohne jemanden, der sie stellt - deshalb gehört an den Stichtag nicht nur die Messung, sondern die Übergabe der Überwachung selbst. Für die Erreichbarkeit ist das die laufende Verfügbarkeitsmessung, für die Inhaberdaten eine regelmäßige Abfrage der Registerdaten.

Internationale Domains: die Transfer Policy

Bei Domains unter .com, .net oder .org gilt nicht das Verfahren des deutschen Registers, sondern die Transfer Policy der ICANN. Sie setzt eine Obergrenze, die bei einer Trennung hilfreich ist: Bietet der Registrar keine Selbstbedienung an, mit der der Domaininhaber seinen AuthInfo-Code selbst erzeugen und die Transfersperre ClientTransferProhibited selbst entfernen kann, muss er beides binnen fünf Kalendertagen nach der ersten Anfrage des Domaininhabers bereitstellen (ICANN). Fünf Kalendertage sind damit die Spanne, mit der zu rechnen ist - und sie beginnt mit der Anfrage, nicht mit der Kündigung des Vertrags.

Zwei weitere Punkte derselben Regel gehören in jede Auseinandersetzung über eine offene Rechnung. Erstens darf der bisherige Registrar die Aufhebung der Sperre oder die Herausgabe des AuthInfo-Codes nicht allein deshalb verweigern, weil zwischen ihm und dem Domaininhaber ein Streit über eine Zahlung besteht (ICANN). Zweitens müssen die vom Registrar erzeugten AuthInfo-Codes je Domain eindeutig sein (ICANN) - ein gemeinsamer Code für das ganze Kundenkonto ist also kein zulässiger Ersatz und taugt auch als Nachweis nichts. Wer eine Domain mit gesetzter Transfersperre übernimmt, findet die Hintergründe zu den Sperrzuständen im Beitrag über Registry Lock und EPP-Status.

Die saubere Trennung als Verkaufsargument

Eine Übergabe ist die letzte Handlung im Auftrag und die erste im nächsten. Der Kunde, der gerade geht, wird gefragt werden, wie die Trennung gelaufen ist - von seinem Nachfolger im Amt, von der neuen Agentur, von einem Bekannten mit derselben Frage. Ein Protokoll, das jede Position benennt und jeden Nachweis mitliefert, ist an dieser Stelle mehr wert als jede Referenzliste, weil es das einzige ist, was die andere Seite prüfen kann. Umgekehrt kostet ein zurückgehaltener Zugang mehr als die Rechnung, um die es geht.

Für die übernehmende Seite gilt dasselbe in die andere Richtung: Wer die acht Positionen am ersten Tag abfragt, statt sie im dritten Monat zu suchen, übernimmt einen Bestand und kein Rätsel. Und wer den Kunden dauerhaft halten will, zeigt die Übergabe als Teil des Angebots - mit einem Mandanten, in dem Zugänge, Ablaufdaten und Berichte von Anfang an getrennt liegen. Wie sich daraus ein laufendes Angebot bauen lässt, beschreibt der Beitrag über Monitoring unter eigenem Namen für Agenturen; die regelmäßige Berichterstattung an den Kunden behandelt der Beitrag über automatisierte Wochenberichte.

Ablaufplan für die letzten dreißig Tage

Die Reihenfolge ist wichtiger als die Vollständigkeit. Wer mit dem Domainumzug beginnt, bevor die Zone kopiert ist, nimmt sich die Möglichkeit, sie noch einmal auszulesen. Wer die Daten löscht, bevor der Export geprüft ist, hat nichts mehr in der Hand. Der folgende Plan hält die Reihenfolge ein und lässt für jede Position Zeit für einen zweiten Versuch.

1. Tag 30 bis 25: Bestand aufnehmen. Registerabfrage, Zone auslesen, Konten auflisten, Zertifikate mit Ablaufdatum erfassen, Werkzeuge benennen. Ergebnis ist die Tabelle, noch ohne Zustände.
2. Tag 24 bis 18: Inhaber klären. Steht die Domain auf dem Kunden? Laufen die Konten auf den Kunden? Was muss vor dem Umzug auf den richtigen Inhaber wechseln? Diese Woche entscheidet über den Rest.
3. Tag 17 bis 12: Daten sichern und exportieren. Datenbankauszug, Dateien, Messreihen, Berichtsarchiv. Jeder Export wird einmal geöffnet und in der Tabelle mit Umfang und Datum vermerkt.
4. Tag 11 bis 7: Umzug fahren. AuthInfo anfordern und weitergeben, Zone beim neuen Betreiber anlegen, Zeitspannen bis zum Ablauf vorher verkürzen, Zertifikat auf der Zielseite bereitstellen.
5. Tag 6 bis 2: Gegenprobe. Namenseintrag, Adresse, Auslieferung, Zertifikat, Mailversand und Prüfeinträge messen; jede Abweichung korrigieren, solange beide Seiten erreichbar sind.
6. Tag 1 bis 0: Protokoll schließen. Zustände eintragen, Löschtermin festlegen, offene Punkte benennen, beidseitig bestätigen. Danach beginnt die Frist für die Löschung, nicht die Suche nach Zugängen.

Ein Wartungsfenster für den Umzug selbst schadet nicht, auch wenn technisch nichts ausfällt: Es setzt eine Erwartung, die sonst jeder für sich bildet. Wie ein solches Fenster angekündigt und technisch sauber abgebildet wird, beschreibt der Beitrag über Wartungsfenster mit 503 und Retry-After.