Zusammenfassung

  • Versionslose Domains werden bei Fastly unabhängig von einer einzelnen Dienstversion verwaltet. Die Vorbereitung des öffentlichen Namens muss deshalb nicht denselben Zeitplan wie die Anwendung haben.
  • Für einen Betreiberwechsel zählen die Verfügungsrechte über DNS, Zertifikatsnachweise, Konten und Zuordnungen zu Diensten oder Routingregeln. Eine Codeübergabe bildet diese Rechte nicht vollständig ab.
  • Die Delegation zwischen Konten ist weder ein rechtlicher Eigentumsübergang noch ein Wechsel zu einem anderen CDN. Klassische Domains und Platform TLS unterliegen zudem abweichenden Verfahren.

Die Abnahme hat eine zweite Grenze

Bei einem geordneten Wechsel der Webagentur ist die Anwendung ein naheliegender Gegenstand der Abnahme. Stellen wir uns vor, der neue Dienstleister hat Quellcode, Build-Anleitung und Informationen über den Ursprungsserver erhalten. Beide Agenturen arbeiten zusammen. Der neue Betreiber kann den Dienst ausführen. Kann der Auftraggeber damit auch veranlassen, dass die bekannte öffentliche Adresse auf diesen Dienst führt?

Die Frage beschreibt kein belegtes Problem eines Fastly-Kunden, sondern eine hypothetische Übergabe. Sie betrifft die Reichweite eines Betriebsvertrags. Wer eine Anwendung ausführen kann, verfügt nicht zwangsläufig über die Konten und Nachweise, die ihre öffentliche Erreichbarkeit zuordnen. Selbst eine technisch brauchbare Lieferung kann deshalb einen Teil des Betreiberwechsels offenlassen.

Fastly macht diese Trennung mit versionslosen Domains ausdrücklich. Eine solche Domain wird außerhalb der einzelnen Dienstversion verwaltet. Sie lässt sich anlegen, bevor ein Dienst zugeordnet wird; Änderungen erfordern keine Erhöhung der Dienstversion. Die Verwaltung des Namens bekommt damit einen eigenen Arbeitsablauf neben dem Release.

Für einen Auftraggeber ist das zunächst eine Erleichterung. Das Team für die öffentliche Adresse kann Vorbereitungen treffen, während das Anwendungsteam noch arbeitet. Nicht jede administrative Änderung muss eine neue Dienstversion auslösen. Doch gerade weil die Aufgaben auseinanderfallen, darf die Abnahme der Anwendung nicht zugleich als Nachweis gelten, dass sämtliche Zuständigkeiten am Eingang übernommen wurden.

Was innerhalb der Plattform beweglicher wird

Die ältere Konstruktion verdeutlicht den Unterschied. Fastly bezeichnet Domains, die zur Konfiguration und den Versionen eines Dienstes gehören, als klassische Domains. Eine geänderte Dienstzuordnung benötigt dort eine neue Version. Die Funktion ist laut Dokumentation auf Konten beschränkt, die vor dem 16. September 2025 angelegt wurden. Wird eine klassische Domain bereits in einem anderen Fastly-Konto genutzt, erfolgt die Delegation über den Support.

Für versionslose Domains beschreibt Fastly dagegen eine selbst bedienbare Delegation an ein anderes Konto oder einen anderen Kunden. Als Nachweis kommt ein von Fastly verwaltetes, per DNS-Prüfung beschafftes Zertifikat zusammen mit einem DNS-Token infrage. Alternativ nennt die Dokumentation ein gültiges Zertifikat einer öffentlich anerkannten Zertifizierungsstelle und den passenden privaten Schlüssel. Das sind Produktbedingungen, keine Empfehlung, produktive private Schlüssel zwischen Dienstleistern herumzureichen.

Der wirtschaftlich interessante Punkt ist die zusätzliche Handlungsmöglichkeit. Bei einer geeigneten Konstellation muss die Übergabe nicht zwingend mit einem Supporteingriff beginnen. Hält der Auftraggeber die erforderlichen Berechtigungen und Nachweismöglichkeiten unter einer dauerhaft nutzbaren Verwaltung, kann er den nächsten Betreiber gezielter vorbereiten. Liegen sämtliche Voraussetzungen beim bisherigen Dienstleister, stellt eine Selbstbedienungsfunktion sie nicht automatisch dem Kunden zur Verfügung.

Eine wichtige Ausnahme steht im Leitfaden zur Domainverwaltung: Kunden von Platform TLS haben in Unified Domain Management nur Lesezugriff. Zur Verwaltung von Domains oder zur Migration müssen sie den Support kontaktieren. Eine Aussage über einen möglichen Ablauf darf daher nicht zur Zusage für sämtliche Fastly-Produkte werden.

Für den Einkauf folgt daraus eine Reihenfolge: Erst die tatsächlich eingesetzte Konto- und TLS-Konstellation bestimmen, dann den Übergabeplan daran ausrichten. Die öffentlichen Unterlagen liefern weder eine durchschnittliche Bearbeitungszeit noch eine Übergabegebühr oder eine gemessene Kostenersparnis. Sie begründen eine bedingte Aussage über mehr organisatorischen Spielraum, keine allgemeine Zusage reibungsloser Portabilität.

Der Vorlauf ist ein Teil des Nutzens

Die Trennung von Name und Dienstversion lässt sich bei TLS praktisch nutzen. Fastlys Anleitung für verwaltete Zertifikate erläutert die standardmäßige ACME-DNS-Prüfung: Nur die Prüf-Subdomain wird auf Fastly ausgerichtet. Produktiver Verkehr muss zu diesem Zeitpunkt noch nicht wechseln. Zertifikatsvorbereitung und tatsächliche Verkehrsverlagerung können somit getrennt geplant werden.

Bei der HTTP-Prüfung ist das anders. Sie leitet Verkehr sofort weiter. Fastly warnt, dass eine unvollständige TLS- oder Dienstkonfiguration dann Sicherheitswarnungen oder einen nicht erreichbaren Auftritt verursachen kann. Für einen Übergabevertrag ist entscheidend, ob unerledigte Arbeit noch in der Vorbereitung bleibt oder bereits bei den Nutzern ankommt.

Ein früherer Vorbereitungsschritt kann fehlende Rechte sichtbar machen, solange der bisherige Dienst den Verkehr noch übernimmt. Die neue Agentur muss die Unterstützung dann nicht erst im letzten Moment anfordern. Das schafft Verhandlungsspielraum über Zuständigkeiten und Termine. Es garantiert keine unterbrechungsfreie Migration; auch der empfangende Dienst und das Verhalten der Anwendung müssen stimmen.

Mit dem ersten Zertifikat endet die Verantwortung nicht. Geänderte DNS-Einträge oder eine einschränkende CAA-Regel können die Erneuerung behindern. Die API für TLS-Abonnements unterscheidet Ausstellung, Erneuerung und Wiederholungsversuche. Dass ein Verfahren weiter versucht, ein Zertifikat auszustellen, verlängert nicht die Gültigkeit eines abgelaufenen Zertifikats. Eine Übergabe muss deshalb auch die Voraussetzungen für den nächsten Zyklus einem Verantwortlichen zuweisen.

Fastly unterscheidet außerdem zwischen dem Einsatz eines Zertifikats und seiner weiteren Verwaltung: Werden sämtliche TLS-Aktivierungen deaktiviert, endet dadurch allein die verwaltete Erneuerung nicht; das Löschen des Abonnements ist ein anderer Vorgang. Hier wird keine dieser Maßnahmen als Migrationsschritt vorgeschlagen. Der Unterschied zeigt vielmehr, warum mehrere fortlaufende Pflichten nicht unter einem einzigen Schaltvorgang zusammengefasst werden sollten.

Ein technischer Nachweis ist kein Rechtstitel

Die Domainverwaltungs-API trennt den per Zertifikat bestätigten Kontrollnachweis von einer vorhandenen TLS-Aktivierung. Die Zuordnung zu einem Dienst und zu einer Routingkonfiguration wird wiederum separat dargestellt; diese Verknüpfungen können leer sein. Jede Bedingung betrifft einen anderen Ausschnitt des Betriebs.

Ein für das Produkt ausreichender Kontrollnachweis klärt nicht, wem eine registrierte Domain rechtlich zusteht. Er überträgt auch keine Marke und kein Unternehmen. Ebenso belegt eine TLS-Aktivierung für sich genommen nicht, dass jede geschäftliche Funktion die beabsichtigte Anwendung erreicht. Die Beteiligten sollten benennen, welche Fähigkeit sie tatsächlich übergeben, statt sämtliche Vorgänge als einen Domaintransfer zu behandeln.

Bei selbst verwalteten Zertifikaten ist die Versuchung groß, die Übergabe als Dateitransfer zu betrachten. Fastlys Anleitung für eigene Zertifikate verlangt jedoch neben gültigem Zertifikat und passendem Schlüssel die TLS-Konfiguration, Aktivierungen und korrekten DNS-Einstellungen. Mehrere Namen in einem Zertifikat bedeuten nicht, dass sämtliche vorgesehenen Domains automatisch ausdrücklich aktiviert wurden.

Auch die Erneuerung selbst verwalteter Zertifikate liegt beim Kunden. Dateien ohne übernommene Fristenüberwachung und Verwaltungsrechte verschieben die offene Aufgabe lediglich. Die TLS-Voraussetzungen nennen weitere Konto- und Berechtigungsbedingungen. Eine erhaltene Betriebsanleitung verleiht der neuen Agentur nicht automatisch die darin vorausgesetzten Rechte.

Wer verteilt die Anfragen zwischen den Teams?

Hinter einem Namen können mehrere Dienste stehen. Fastlys Regeln für das Request-Routing verteilen Anfragen anhand von Pfaden und Bedingungen auf verschiedene Fastly-Dienste. Für diese Routingebene muss kein VCL- oder Compute-Code geschrieben werden. Die öffentliche Adresse kann bestehen bleiben, während die Aufgaben dahinter neu verteilt werden.

Bei einer schrittweisen Erneuerung eines Webauftritts ließen sich auf diese Weise unterschiedliche Teile verschiedenen Diensten zuweisen. Das ist ein Beispiel für die dokumentierte Möglichkeit, kein beobachteter Kundeneinsatz. Die zusätzliche Flexibilität bringt eine weitere Übergabeaufgabe mit sich: Nicht nur die empfangenden Anwendungen, sondern auch die Regeln ihrer Zuteilung brauchen einen klaren Betreiber.

Vorausgesetzt werden eine Domain in Domain Management, ein gültiges TLS-Zertifikat und ein aktiver Dienst. Eine Standardregel ist verpflichtend. Die Routingkonfiguration muss bereitgestellt und mit der Domain verknüpft werden. Eine bereits bereitgestellte Konfiguration beginnt mit der Verknüpfung, Anfragen zu verteilen. Das Recht, diese Zuordnung vorzunehmen, hat damit eine eigene Wirkung auf die Aufteilung des Betriebs.

Eine nach Codebeständen organisierte Übergabe kann diese Ebene übersehen. Der neue Betreiber erhält einen Dienst, während eine andere Stelle weiterhin festlegt, welche Anfragen dort ankommen. Das ist kein Grund, auf die Funktion zu verzichten. Es ist ein Grund, die vertragliche Zuständigkeit an der tatsächlichen Reichweite der Entscheidung auszurichten.

Die beschriebenen Regeln führen zu Diensten innerhalb Fastlys. Sie belegen weder eine Verteilung auf fremde CDNs noch, dass ein Webauftritt ohne weitere Arbeit auf eine andere Plattform wechseln könnte. Eine interne Auswahlmöglichkeit bleibt wirtschaftlich nützlich, auch wenn sie keine externe Ausstiegsmöglichkeit ist. Beides sollte nicht gleichgesetzt werden.

Vier Vorgänge statt eines pauschalen Umzugs

Eine Dienstzuordnung innerhalb eines Kontos ändern, eine Domain zwischen Fastly-Konten delegieren, öffentlichen Verkehr zu einem anderen Anbieter verlagern und rechtliche Inhaberschaft übertragen: Diese Vorgänge haben unterschiedliche Voraussetzungen. Die ersten beiden bleiben innerhalb Fastlys. Der dritte braucht zusätzlich eine geeignete Gegenstelle mit ihren Zertifikaten und Anwendungsbedingungen. Der vierte wird durch den technischen Kontrollnachweis nicht entschieden.

Fastlys Leitfaden zur Verkehrsführung hält fest, dass Fastly in der beschriebenen Konfiguration keinen verwalteten DNS-Dienst bereitstellt. Kunden wählen ihren DNS-Anbieter und hinterlegen die vorgegebenen Einträge. Damit existiert eine Verwaltungsebene außerhalb des Anwendungsreleases. Ob der Auftraggeber selbst auf sie zugreifen kann, ergibt sich allerdings erst aus seiner eigenen Konto- und Dienstleisterorganisation.

DNS bringt zudem zeitliche Bedingungen mit. Bereits zwischengespeicherte Einträge verschwinden nicht mit der unterschriebenen Abnahme. Umgekehrt ist eine geänderte Zuordnung von Domain und Dienst innerhalb Fastlys nicht automatisch ein öffentlicher DNS-Umzug. Wer die Vorgänge auseinanderhält, überschätzt weder die Leichtigkeit eines Anbieterwechsels noch unterschätzt er die Wirkung einer internen Neuzuordnung.

Die wirtschaftliche Größenordnung erklärt, weshalb sich der Blick auf solche Verwaltungsdetails lohnt. Fastly meldete für das zweite Quartal 2026 183,3 Millionen US-Dollar Umsatz, darunter 133,9 Millionen US-Dollar mit Network Services. Das sind vom Unternehmen veröffentlichte Geschäftszahlen, keine Messung der Nutzung versionsloser Domains oder ihrer Ersparnisse. Sie verorten die Namensverwaltung am Eingang eines erheblichen Auslieferungsgeschäfts.

Der sinnvolle Anspruch des Käufers ist enger als völlige Lieferantenunabhängigkeit. Er sollte den Betreiber hinter seiner bekannten Adresse ersetzen können, ohne zuerst die eigene Fähigkeit zu rekonstruieren, diesen Ersatz zu autorisieren. Fastly löst den Namen von einer Dienstversion. Der Kunde muss weiterhin dafür sorgen, dass Nachweise, Rechte und laufende Pflichten bei einem Wechsel geordnet nutzbar bleiben.