Migration von Rebrandly: Branded-Domain-Uebergabe ohne Slug-Verlust

Rebrandly ist um eine einzige zentrale Abstraktion herum gebaut: die Branded Domain. Slashtags, Tag-Taxonomien und Traffic-Routing-Regeln haengen alle darunter. Diese Designentscheidung macht Rebrandly zu einem kohaerenten Produkt, und sie macht die Migration weg von Rebrandly anders als jeden anderen Shortener-Wechsel.

Wenn Sie Rebrandly verlassen, migrieren Sie nicht in erster Linie Links. Sie migrieren eine Domain. Die Links fahren mit, und die Details, wie Sie sie bewahren, haengen fast vollstaendig davon ab, was Sie mit der Domain machen wollen.

Dieser Beitrag behandelt die zwei realistischen Pfade, die Exportform aus der Rebrandly-API, den Bulk-Import-Call zu Elido und den Validierungsprozess vor der Ankuendigung des Cutovers.

TL;DR#

• Die Kern-Abstraktion von Rebrandly ist die Branded Domain. Die Migration ist zuerst eine DNS-Uebergabe, dann Linkerhaltung.
• Pfad A: Die Domain bleibt gleich, nur der Shortener aendert sich. Slugs auf Elido vorbereitstellen, CNAME umlegen, fertig.
• Pfad B: Auch die Domain aendert sich. Sie brauchen entweder eine 301-Kette von der alten Domain (Rebrandly-Pro-Stufe) oder akzeptieren eine Slug-Aenderung auf der neuen Domain.
• Rebrandly-Tags lassen sich sauber auf Elido-Tags abbilden. Rebrandly-Kategorien brauchen manuelles Mapping - sie haben kein direktes Pendant.

Was Sie zuerst inventarisieren muessen#

Bevor Sie sich auf einen der beiden Pfade festlegen, machen Sie eine Bestandsaufnahme von vier Dingen.

Branded Domain oder Domains. Das Workspace-Modell von Rebrandly erlaubt mehrere Custom-Domains pro Konto. In einem Agentur- oder Multi-Brand-Workspace ist jede Domain eine separate Migrationseinheit. Zaehlen Sie sie auf, bevor Sie Cutover-Fenster planen - eine Domain pro Nacht ist ein sichereres Zeitplan als alle auf einmal.

Aktive Links. Nutzen Sie fuer grosse Bestaende die Rebrandly REST API (abgerufen am 2026-05-12) statt des CSV-Exports. Der Endpunkt /v1/links paginiert mit den Query-Parametern last und limit und gibt das vollstaendige Link-Objekt inklusive Slashtag, Ziel, Domainnamen, Tag-Set und createdAt zurueck. Der CSV-Export aus dem Workspace-Settings-Panel ist fuer unter ein paar hundert Links in Ordnung, schneidet Felder aber bei groesseren Exporten inkonsistent ab.

Integrationen. Wenn Ihr Team Links ueber Zapier-, Make- oder Workato-Workflows erstellt, zeigen diese Konnektoren auf die Rebrandly-API. Jeder muss neu ausgerichtet werden. Das ist eine separate Aufgabe von der Linkmigration mit eigenem Karenzfenster. Decken Sie sie nach dem DNS-Wechsel ab, nicht davor.

Tag- und Kategorientaxonomie. Rebrandly unterstuetzt sowohl freie Tags als auch strukturierte Kategorien. Tags bilden eins-zu-eins auf Elido-Tags ab. Kategorien haben in Elido kein direktes Pendant - die naechstliegende Abbildung ist ein reserviertes Tag-Praefix (cat:campaign, cat:region), das Sie beim Import vergeben. Einigen Sie sich auf das Mapping, bevor Sie das Skript starten, nicht danach.

Pfad A: Domain bleibt, Shortener wechselt#

Das ist die saubere Migration. Sie behalten go.acme.com (oder wie auch immer Ihre Branded-Short-Domain heisst). Sie stellen jeden Slug auf Elido unter derselben Domain vorab bereit und schalten dann den CNAME um. Aus Sicht eines Linkklicks aendert sich nichts - der Slug loest auf dieselbe Ziel-URL auf, nur ueber einen anderen Edge.

Schritt 1: aus Rebrandly exportieren#

Laufen Sie ueber die Rebrandly /v1/links API paginiert. Die Response-Objekte enthalten slashtag, destination, domain.fullName, tags[], category.name und createdAt. Speichern Sie als JSONL.

Zwei Dinge sind sorgfaeltig zu behandeln. Erstens domain.fullName - wenn Ihr Workspace mehr als eine Domain hat, filtern Sie auf diejenige, die Sie in diesem Durchgang migrieren. Zweitens, die Rebrandly-Preisstufen (abgerufen am 2026-05-12) gaten, wie viele Links und wie viele Custom-Domains pro Konto aktiv sind. Die API gibt alle Links zurueck; Ihr Bestand kann Links auf Domains enthalten, die Sie bereits stillgelegt haben. Filtern Sie diese vor dem Import heraus.

Schritt 2: auf Elido vorab bereitstellen#

Registrieren Sie die Domain in Ihrem Elido-Workspace ueber den Custom-Domains-Flow, bevor Sie DNS anfassen. Die Domain muss noch nicht live sein. Elido validiert den Domain-Besitz ueber einen DNS-TXT-Record; das koennen Sie erledigen, ohne den bestehenden CNAME zu stoeren, der auf Rebrandly zeigt.

Sobald die Domain registriert ist, importieren Sie die Links per Bulk. Der Endpunkt POST /v1/links/bulk akzeptiert bis zu 100 Links pro Aufruf und gibt Erfolg/Misserfolg pro Item zurueck, sodass eine Slug-Kollision in einer Zeile den Batch nicht abbricht. Uebergeben Sie slug explizit, um den Rebrandly-Slashtag zu erhalten. Bilden Sie Rebrandlys tags[] direkt auf Elidos tags[] ab. Uebergeben Sie created_at, um den urspruenglichen Erstellzeitstempel fuer historische Sortierungen zu erhalten.

curl -X POST "https://api.elido.app/v1/links/bulk" \
  -H "Authorization: Bearer $ELIDO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: rebrandly-migration-batch-001" \
  -d '{
    "workspace_id": "ws_xxxxxxxxxxxx",
    "domain_id": "dom_xxxxxxxxxxxx",
    "links": [
      {
        "slug": "summer-promo",
        "destination_url": "https://acme.example/summer",
        "tags": ["campaign", "q3", "rebrandly-migrated"],
        "created_at": "2025-07-01T09:00:00Z"
      },
      {
        "slug": "hero-cta",
        "destination_url": "https://acme.example/hero",
        "tags": ["homepage", "rebrandly-migrated"],
        "created_at": "2025-03-15T14:30:00Z"
      }
    ]
  }'

Das rebrandly-migrated-Tag ist fuer die Analytik-Filterung nach dem Cutover nuetzlich - Sie koennen vor-migrierte Links von nativ auf Elido erstellten trennen und Klicktrends ueber die ersten 30 Tage vergleichen.

Fuer das Kategorien-Taxonomie-Mapping: Wenn summer-promo in einer Rebrandly-Kategorie namens Campaigns lag, fuegen Sie cat:campaigns zum tags-Array hinzu. Es ist semantisch nicht aequivalent, aber es liefert Ihnen einen Filter in Elidos Analytics- und Dashboard-Ansichten. Dokumentieren Sie das Mapping in Ihren Migrationsnotizen.

Machen Sie zuerst einen Trockenlauf. Die meisten Teams fahren den Bulk-Import gegen einen Staging-Workspace oder mit einer kleinen Stichprobe (10-20 Links), bevor sie den vollen Bestand schicken. Die Antwortflaeche pro Item im Bulk-Endpunkt zeigt etwaige Slug-Konflikte oder Ziel-Validierungsfehler sauber an, bevor Sie den gesamten Export committen.

Schritt 3: DNS-Cutover#

Das ist der Moment. Bevor Sie hier ankommen, verifizieren Sie Folgendes:

• Alle Slugs im Bulk-Import haben Erfolgsstatus zurueckgegeben. Keine offenen Fehler.
• Die Domain ist registriert und TLS ist in Ihrem Elido-Workspace bereitgestellt. Testen Sie einen Slug direkt gegen den Elido-Edge, indem Sie temporaer einen CNAME auf eine Test-Subdomain setzen, nicht auf Ihre Produktion.
• Die TTL des bestehenden Rebrandly-CNAME wurde abgesenkt. Die Rebrandly-Preisseite (abgerufen am 2026-05-12) zeigt, dass DNS-Konfiguration ab der Free-Stufe verfuegbar ist - Sie koennen die TTL ohne Upgrade absenken. Senken Sie sie mindestens 24 Stunden vor dem Cutover-Fenster auf 300 Sekunden.

Wenn das Fenster sich oeffnet, tauschen Sie das CNAME-Ziel:

go.acme.com.  300  IN  CNAME  edge.elido.me.

Elidos Edge nutzt automatisches On-Demand-TLS. Wenn TLS bereits waehrend der Vorvalidierung bereitgestellt wurde (empfohlen), ist die erste Anfrage nach DNS-Propagation schnell. Wenn nicht, wird das Zertifikat bei der ersten Anfrage bereitgestellt - typischerweise 1-3 Sekunden, dann cacht das Zertifikat und nachfolgende Anfragen werden bei p95 unter 15 ms vom EU-Region-Edge bedient.

Verifizieren Sie von mehreren Resolvern, bevor Sie das Change-Fenster schliessen. Ein Propagations-Check von Ihrem Schreibtisch bestaetigt nur Ihren Resolver. Tools wie dig @8.8.8.8 go.acme.com CNAME und dig @1.1.1.1 go.acme.com CNAME fangen die uebliche Divergenz ab.

Pfad B: auch die Domain aendert sich#

Manche Teams nehmen die Migration als Gelegenheit, die Branded Domain umzubenennen - von brand.ly (eine von Rebrandly zugewiesene Subdomain) zu etwas, das ihnen vollstaendig gehoert, oder von einer Markendomain zu einer anderen nach einem Rebrand. Andere waren auf Rebrandlys Subdomain (yourname.rebrandly.com) und haben nie eine Custom-Domain eingerichtet.

In beiden Faellen aendert sich der Slug-Raum. Die Frage ist, ob Sie eine 301-Kette von der alten Domain installieren koennen, um Linkbrueche zu minimieren.

Option B1: 301-Kette von der alten Rebrandly-Domain#

Rebrandlys Traffic-Routing-Feature - auf der Pro-Stufe verfuegbar - erlaubt es, eine ganze Domain auf eine neue Basis-URL umzuleiten. Wenn Sie die alte Domain besitzen und Traffic weiterleiten wollen, koennen Sie in Rebrandly einen Wildcard-Redirect einrichten, der alle Anfragen go.old-domain.com/* mit Slug-Match auf go.new-domain.com/* weiterleitet.

RFC 7231 §6.4.2 definiert die Semantik von 301 Moved Permanently: Clients, die einen 301 erhalten, sollen jede gespeicherte URL auf den neuen Standort aktualisieren. In der Praxis bedeutet das, dass bestehende QR-Codes, Druckerzeugnisse und veroeffentlichte Links waehrend des Ueberlappungszeitraums korrekt umgeleitet werden. Das ist das Naechstliegende zu einer transparenten Migration, wenn die Domain sich aendert.

Die Mechanik: Halten Sie die alte Domain waehrend des Ueberlappungszeitraums auf Rebrandly live, konfiguriert als Pass-Through-Redirector. Fahren Sie die neue Domain ab Tag eins der Migration auf Elido. Nach 30-90 Tagen (je nachdem, wie lange Ihre veroeffentlichten Materialien im Umlauf bleiben) nehmen Sie die alte Domain auf Rebrandly ausser Betrieb.

Option B2: Slug-Aenderung akzeptieren#

Wenn die alte Domain eine von Rebrandly zugewiesene Subdomain (yourname.rebrandly.com) war oder eine Domain, ueber die Sie keine DNS-Kontrolle mehr haben, ist keine 301-Kette verfuegbar. Die Links auf der alten Domain funktionieren weiter, solange Rebrandly laeuft und Sie das Konto aktiv halten. Traffic auf diesen alten Links wird nicht ueber Elido geroutet; Sie verlieren die Analytics-Abdeckung dafuer.

Der praktische Ansatz: migrieren Sie die Linkliste zu Elido auf einer neuen Domain, erstellen Sie neue Slugs fuer die Links mit hoechstem Traffic und aktualisieren Sie die veroeffentlichten Oberflaechen, die wichtig sind, und lassen Sie den Long Tail von alten Links mit wenig Traffic auf Rebrandly verfallen. Das migrate-from-bitly-playbook deckt denselben Entscheidungsrahmen fuer Bitly-Migrationen ab - die Argumentation gilt hier.

Fuer Teams, die zwischen Option B1 und B2 entscheiden, lautet die Rechnung: wie viele veroeffentlichte Oberflaechen die alten Links enthalten, wie schwer sie zu aktualisieren sind und wie lange Traffic weiterhin auf diesen Oberflaechen ankommt. E-Mail-Archiv-Links mit viel Traffic und Druckerzeugnisse sprechen fuer B1. Ein paar interne Dokumente sprechen fuer B2.

Rebrandly-Export: was Sie bekommen und was nicht#

Die Rebrandly API (abgerufen am 2026-05-12) exportiert die folgenden Felder pro Link ueber /v1/links:

• id - Rebrandlys interne Link-ID (nicht zum Import noetig, aber als Idempotenz-Key nuetzlich)
• slashtag - der zu erhaltende Slug
• destination - die vollstaendige Ziel-URL inklusive UTM-Parametern
• domain.fullName - der Custom-Domain-Hostname
• tags[] - freie Tags; direkt auf Elido-Tags abbilden
• category.name - Kategoriebezeichnung; manuell auf ein Tag-Praefix abbilden
• createdAt, updatedAt - Zeitstempel; createdAt auf Elidos created_at-Feld uebergeben
• clicks.total - Lebenszeit-Klickzahl; nicht in Elidos Analytics importierbar, aber wert, in einem Tag (clicks-baseline-1234) oder in der eigenen Datenebene gespeichert zu werden

Was die API nicht exportiert:

• Rohe Click-Events. Rebrandly stellt keine Pro-Klick-Records bereit - Sie erhalten nur aggregierte Zaehlungen. Die Analytics-Uhr beginnt auf Elido ab dem Cutover-Tag von neuem.
• Traffic-Routing-Regeln. Wenn Sie bedingte Redirects auf irgendwelchen Links konfiguriert haben (Geraete- oder Geo-Routing), muessen diese Regeln nach dem Import manuell im Smart-Link-Editor von Elido neu angelegt werden. Es gibt keinen Bulk-Import fuer Routing-Regeln.
• Team-Mitglied-Berechtigungen. Workspace-Zugriff muss auf Elido neu eingeladen werden.

Das Fehlen roher Click-Events ist dieselbe Einschraenkung, auf die Sie bei der Migration von Bitly ohne Linkbruch stossen. Das Muster fuer den Umgang damit ist dasselbe: Speichern Sie den Rebrandly-Lebenszeit-Zaehler, verfolgen Sie Elido-Klicks ab dem Cutover und kombinieren Sie sie beim Reporting historischer Summen.

Webhook-Neuverkabelung: Zapier, Make, Workato#

Wenn irgendwelche Ihrer Automationsworkflows Rebrandly-Links erstellen, muessen diese neu ausgerichtet werden: ein CRM-Trigger, der pro Lead einen Tracking-Link erzeugt, ein Zap, der Links aus einem Spreadsheet kuerzt, ein Make-Szenario, das QR-Codes fuer Events erzeugt.

Der Mechanismus unterscheidet sich je nach Plattform. In Zapier finden Sie jeden Zap, der die Rebrandly-App nutzt, und ersetzen den Aktionsschritt entweder durch die Elido-Zapier-App (Verfuegbarkeit beim Launch pruefen) oder eine Webhook-Aktion, die POST /v1/links direkt aufruft. In Make und Workato gilt dieselbe Ersetzung.

Zwei Dinge sind hier richtig zu sequenzieren. Erstens: Richten Sie die Automationen nicht neu aus, bevor der DNS-Cutover und der Bulk-Import bestaetigt sind. Automationen gegen Elido auszufuehren, bevor die Vorbereitstellung abgeschlossen ist, erzeugt doppelte Slug-Konflikte. Zweitens: Fuegen Sie den Elido-API-Key vor dem Wechsel in den Credential-Store jeder Automationsplattform ein - machen Sie das im Voraus, nicht waehrend des Cutover-Fensters.

Das Karenzfenster: Fuer jede Automation, die Links mit geringer Frequenz erzeugt (ein paar pro Woche), ist es risikoarm, sie 1-2 Wochen nach dem DNS-Cutover auf Rebrandly zu lassen. Die von ihr erzeugten Links sind zwar auf der alten Plattform, aber das DNS ist bereits umgelegt, sodass diese Links ueber Elido aufgeloest werden. Fuer Hochfrequenz-Automationen, die Dutzende Links pro Tag erzeugen, migrieren Sie sie am Cutover-Tag.

Fuer die API und verfuegbaren SDKs von Elido behandelt die Preisseite die Plan-Limits, und die vollstaendige API-Referenz liegt unter /help. TypeScript-, Python- und Go-SDKs sind verfuegbar.

Validierung vor der Cutover-Ankuendigung#

Erklaeren Sie die Migration nicht fuer abgeschlossen, bevor Sie eine strukturierte Stichprobenpruefung gemacht haben. Zwei Dinge brechen stillschweigend: Ziel-URLs, die beim Export Encoding-Probleme hatten, und Slugs, die beim Bulk-Import kollidierten und uebersprungen wurden.

Top-100-Slug-Check#

Sortieren Sie Ihre exportierte Linkliste absteigend nach clicks.total. Nehmen Sie die Top 100. Senden Sie fuer jeden eine HEAD-Anfrage gegen die Elido-gehostete URL und pruefen Sie, dass der Location-Header dem erwarteten Ziel entspricht:

curl -s -o /dev/null -w "%{http_code} %{redirect_url}" \
  "https://go.acme.com/summer-promo"

Eine 301-Antwort mit der korrekten Ziel-URL bestaetigt, dass der Slug funktioniert. Ein 404 bedeutet entweder, dass der Slug nicht vorab bereitgestellt wurde (Bulk-Import-Antwortprotokoll pruefen), oder es lag ein Case-Sensitivity-Mismatch vor. Rebrandly-Slashtags sind beim Aufloesen case-insensitiv; Elido-Slugs sind bei der Erstellung case-sensitiv. Wenn Ihr Export gemischte Slashtags enthaelt, normalisieren Sie vor dem Import auf Kleinbuchstaben.

30-Tage-Rollback-Plan#

Halten Sie das Rebrandly-Konto 30 Tage nach dem DNS-Cutover aktiv. Die DNS-Aenderung ist zu jedem Zeitpunkt in diesem Fenster vollstaendig umkehrbar - zeigen Sie den CNAME wieder auf Rebrandlys Edge und die alten Links funktionieren wieder. Wenn die Analytik nach 30 Tagen keine Anomalie in der Redirect-Erfolgsrate zeigt und der Slug-Check bestanden ist, kann das Rebrandly-Konto sicher heruntergestuft oder gekuendigt werden.

Zur Domain: Uebertragen Sie den Registrar der Domain waehrend des Migrationsfensters nicht von dort, wo er gerade liegt. Die CNAME-Aenderung ist die einzige DNS-Operation, die erforderlich ist. Ein Registrar-Transfer fuegt Propagationsrisiko hinzu, das waehrend des Cutovers unnoetig ist.

Interner Migrationskontext#

Die Mechanik dieser Migration entspricht dem Bitly-Playbook. Die DNS-Muster, das TTL-Timing und der Slug-Erhaltungsansatz sind dieselben. Wenn Sie den Wechsel auf Feature-Ebene bewerten, bevor Sie sich auf Migrationsarbeit festlegen, behandelt der elido-vs-rebrandly-Vergleich Unterschiede beim Preismodell und die EU-Residenz-Luecke im Detail. Die Setup-Dokumentation zu Custom-Domains unter /features/custom-domains deckt die Elido-Seite der DNS-Verifikation und TLS-Bereitstellung ab. Und /pricing hat die aktuellen Stufenlimits - die Vorbereitstellung eines grossen Rebrandly-Bestands erfordert den richtigen Plan, bevor Sie mit dem Importieren beginnen.

---

Quellen: Rebrandly API documentation abgerufen am 2026-05-12. Rebrandly pricing page abgerufen am 2026-05-12. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.