Migration von Bitly zu Elido: ein technischer Leitfaden

Link-Infrastruktur zu migrieren ist riskant. Jeder Kurzlink, den du je gedruckt, in einen E-Mail-Footer eingebettet oder auf einen QR-Code gestempelt hast, ist jetzt eine Abhaengigkeit. Bewege dich ungeschickt und du 404st einen relevanten Anteil eingehenden Traffics fuer Wochen, bevor es jemand bemerkt.

Dieser Leitfaden deckt den Umzug von Bitly zu Elido ab. Er nimmt an, dass du dich bereits entschieden hast zu wechseln - ueblich aus Gruenden der EU-Datenresidenz, einer saubereren Free-Tier-Erfahrung, White-Label-Wiederverkauf oder API-Zugriff, der nicht das Premium-Tier voraussetzt (199 $/Monat im Jahresabo oder 300 $/Monat im Monatsabo, Stand Mai 2026). Wenn du noch evaluierst, ist die Vergleichsseite unter /compare/vs-bitly der bessere Startpunkt.

Was du tatsaechlich migrieren musst#

Drei Dinge ziehen um; sonst nichts auf der Wire-Ebene zaehlt.

1. Aktive Kurzlinks. Der Slug, das Ziel, optionale Tags und Ordner, und die Custom Domain (falls vorhanden).
2. Custom-Domain-DNS. Der CNAME-Eintrag, der auf Bitlys Edge zeigt, muss auf Elidos zeigen.
3. Klick-Historie. Bitlys aggregierte Zaehler - keine rohen Events (die sind nicht exportierbar).

Alles andere - Bitly-Sights-Dashboards, gebrandete QR-Codes, Deep-Link-Konfigurationen - ist Greenfield-Setup auf Elido, keine Migration. Versuche nicht, sie zu portieren; bau einmal auf dem neuen Stack neu.

Schritt 1: Inventar#

Bitly begrenzt den historischen Daten-Export nach Tier. Der CSV-Export im Dashboard funktioniert bis etwa 10K Links; darueber timeoutet er oder paginiert schlecht. Fuer groessere Bestaende laufst du die API direkt ab:

curl -H "Authorization: Bearer $BITLY_TOKEN" \
  "https://api-ssl.bitly.com/v4/groups/$GROUP_GUID/bitlinks?size=100"

Paginiere ueber die pagination.next-URL in jeder Antwort. Page-Size 100 ist das Maximum. Persistiere Ergebnisse als JSONL - ein Link pro Zeile - damit du fortsetzen kannst, falls der Export stockt.

Was du aus jeder Zeile willst:

• link - die volle Kurz-URL (https://bit.ly/abc oder https://yourdomain.com/abc)
• long_url - das Ziel
• tags, archived, created_at
• link_clicks (Lifetime-Total) - die einzige Klick-Historie, die du aus Bitly herausbekommst

Filtere archivierte Links raus, sofern du keinen Grund hast, sie zu behalten. Die meisten Teams stellen fest, dass 30-50 % ihres Bestands tot ist - alte Kampagnen, einmalige Shares -, und die Migration ist der richtige Zeitpunkt, um den Ballast abzuwerfen.

Schritt 2: Pre-Provisioning auf Elido#

Bevor du DNS anfasst, lass jeden Link auf Elido unter derselben Custom Domain und demselben Slug reservieren.

Fuer grosse Bestaende nutze links.bulkCreate statt Einzel-Erstellungen. Du brauchst deine Elido-Workspace-ID und die numerische Domain-ID (suche die Domain zuerst mit workspaceDomains.list(workspaceId)):

import { ElidoApi } from "@elido/sdk";

const api = new ElidoApi({ apiKey: process.env.ELIDO_API_KEY! });

// Resolve your custom domain's numeric ID once, before the import loop
const { items: domains } = await api.workspaceDomains.list(WORKSPACE_ID);
const domain = domains.find((d) => d.hostname === "links.yourbrand.com");
if (!domain) throw new Error("Domain not registered in workspace");

// Batch the JSONL into chunks of 100 (the bulk endpoint maximum)
async function migrateChunk(rows: BitlyRow[]) {
  return api.links.bulkCreate(
    WORKSPACE_ID,
    {
      domain_id: domain.id,
      links: rows.map((row) => ({
        slug: row.slug,
        destination_url: row.long_url,
        tags: [
          ...row.tags,
          `bitly-migrated`, // tag for filtering in analytics
        ],
        title: row.title ?? undefined,
      })),
    },
    { idempotencyKey: `mig-batch-${rows[0].slug}` },
  );
}

Der Endpoint links.bulkCreate (POST /v1/workspaces/{workspace_id}/links/bulk) akzeptiert bis zu 100 Links pro Aufruf und liefert pro Eintrag Erfolg-/Fehlerstatus, sodass ein Teilfehler den Batch nicht abbricht. Fuer Einzel-Link-Importe akzeptiert links.create(workspaceId, input, { idempotencyKey }) dieselben Felder domain_id / slug / destination_url / tags und einen optionalen Idempotency-Key, damit ein teilweise gelaufenes Script sicher fortsetzen kann.

Ein paar Dinge, die du wissen solltest, bevor du das Script laufen laesst:

• Domain-Registrierung zuerst. Die domain_id im Request-Body muss sich auf eine Domain beziehen, die bereits in deinem Workspace registriert ist. Registriere und verifiziere die Domain ueber den custom domains flow, bevor du den Import startest. Die Domain muss noch nicht live sein - du kannst sie unter Elido registrieren, bevor du DNS umlegst.
• Tier-Limits. Elido erzwingt Workspace-weite Link-Limits nach Tier. Das Vor-Provisioning eines 100K-Link-Bestands erfordert einen Business-Plan.
• Rate-Limits. Bulk-Create unterliegt denselben Workspace-weiten Rate-Limits wie Einzel-Erstellungen. Eine 50K-Link-Migration dauert ungefaehr 10 Minuten, wenn du in Bloecken von 100 Links pro Aufruf mit moderater Parallelitaet batchst. Halte es seriell oder leicht parallel von einem Runner, damit das Audit-Log einen sauberen Importblock zeigt.

Schritt 3: Custom Domain umlegen#

Das ist der Cutover. Alles davor ist reversibel; alles danach ist live.

Senke die TTL auf dem bestehenden Bitly-CNAME mindestens 24 Stunden vor dem Cutover-Fenster:

links.yourbrand.com.  300  IN  CNAME  cname.bitly.com.

Wenn deine TTL ueber Jahre 86400 war, ist "TTL senken" eine 24-Stunden-Wartezeit, keine fuenfminuetige Aufgabe. Plan darum herum.

Wenn das Aenderungsfenster oeffnet, tausch das Ziel:

links.yourbrand.com.  300  IN  CNAME  edge.elido.me.

Elidos Edge nutzt automatisches On-Demand-TLS. Die erste Anfrage nach DNS-Propagation triggert eine Let's Encrypt-Ausstellung - typischerweise 1-3 Sekunden Latenz auf dieser einen Anfrage, dann wird das Zertifikat gecacht und nachfolgende Anfragen werden vom EU-Region-Edge in einstelligen Millisekunden ausgeliefert. Das Zertifikat wird ueber automatisches On-Demand-TLS bereitgestellt; es gibt keinen manuellen Zertifikatsanforderungsschritt.

Verifiziere mit dig aus ein paar Netzwerken, bevor du den Cutover als erledigt erklaerst. DNS-Propagation ist uneinheitlich; nur vom eigenen Laptop pruefen heisst, einen einzigen Resolver geprueft zu haben.

Schritt 4: Klick-Historie abgleichen#

Bitly exportiert keine rohen Klick-Events. Plane keine Zeit fuer "deine Historie importieren" ein - es ist nicht moeglich, und jedes Tool, das es verspricht, liest Aggregate und nennt sie Events.

Was du bekommst, ist der Pro-Link-Zaehler link_clicks aus dem Bitly-API-Export. Speichere ihn an einer Stelle, an der du ihn gegen dein Elido-Link-Inventar joinen kannst - eine separate Spalte in einem Metabase-Dataset, ein Tag, falls du ihn inline willst. Elido beginnt zum Cutover-Zeitpunkt bei Null zu zaehlen.

Fuer die Reporting-Ebene lautet die Formel: total_clicks = elido_clicks + bitly_lifetime_clicks. Die Analytics-API legt Elidos Klickdaten unter /v1/analytics/workspaces/{workspace_id}/timeseries offen; eine 20-zeilige Metabase- oder Hex-Abfrage stitcht die beiden Zahlen, falls du die Bitly-Basis gespeichert hast.

Wenn du granulare historische Analytics brauchst - Geo-Aufschluesselung nach Monat, Referrer-Trends -, kommen sie nicht zurueck. Bau die Fragen auf Elidos rohem Event-Log nach vorne neu auf; die Migration ist der harte Schnitt.

Fuenf Fallen, die in Woche zwei zubeissen#

1. Hardcodierte bit.ly-Links in statischen Assets. PDFs, Druckmaterial, Embed-Snippets in Begruessungsmails. Diese zeigen auf Bitlys Domain, nicht auf deine Custom Domain. Sie funktionieren weiter, solange du das Bitly-Konto behaeltst; sie brechen in dem Moment, in dem du es kuendigst. Halt entweder ein kostenloses Bitly-Konto als Redirect-Only-Friedhof am Leben, oder akzeptiere den Verlust und kuendige mindestens ein Jahr lang nicht.

2. CDN-Doppel-Redirect. Wenn du deine Domain im Proxy-Modus von Cloudflare (orange Wolke) frontest, kann der SSL-Handshake zu Elido mit Cloudflares Universal SSL kollidieren. Setze Cloudflare SSL auf "Full (Strict)" und entferne alle Page Rules, die das alte Bitly-Ziel referenzierten. Oder grey-cloud den Eintrag waehrend des Cutover-Fensters voruebergehend.

3. UTM-Truncation im Export. Bitly zeigt manchmal eine verkuerzte Ziel-URL im Dashboard, speichert aber die kanonische volle URL. Der CSV-Export hat ueblicherweise die volle URL; die Dashboard-Ansicht moeglicherweise nicht. Wenn du das Dashboard scrapest statt die API aufzurufen, verlierst du UTMs. Geh immer ueber die API.

4. Bitlys API-Rate-Limits auf der Lese-Seite. Die Bitly-API drosselt aggressiv auf GET /bitlinks fuer High-Volume-Konten. Naiv 1M Links sequenziell zu lesen kann Tage dauern. Paginiere parallel (4-8 gleichzeitige Paginatoren), aber pass auf 429s auf; back off, wenn sie feuern.

5. Bitly Account-Level vs. Group-Level Scoping. Bitly-Groups sind keine Workspaces. Ein einzelnes Bitly-Konto kann mehrere Groups besitzen, jede mit eigener Custom-Domain-Konfiguration. Wenn dein Team ueber die Jahre Domains unter verschiedenen Groups hinzugefuegt hat, muss der Export alle Groups aufzaehlen, nicht nur die Default-Group. Versaeumst du eine Group, wird diese Domain nicht migriert.

Compliance: warum die meisten Teams tatsaechlich umziehen#

Die Migration ist meist compliance-getrieben, nicht feature-getrieben. Das Muster:

• DPO markiert Bitly als US-basierten Sub-Processor; die Berufung auf das Data Privacy Framework bekommt im Audit Gegenwind.
• Procurement fragt nach der Sub-Processor-Liste; Bitlys laeuft auf 20+ Anbieter.
• BAA im Premium-Plan (300 $/Monat monatlich abgerechnet, oder 199 $/Monat bei Jahresbindung, Stand Mai 2026 - verifiziere das aktuelle Pricing) wird zur Anforderung fuer Healthcare-nahe Kunden, und der Tier-Sprung ist der Ausloeser.

Elido ist standardmaessig EU-gehostet - Klick-Events laufen ueber die EU-Region, mit US East und Asien-Pazifik als Opt-in-Business+-Regionen. Die Sub-Processor-Liste sind fuenf Anbieter, veroeffentlicht unter /legal/subprocessors. ISO 27001 ist aktuell; SOC 2 Type II ist im Audit. BAA ist auf Business+ verfuegbar. Schrems II ist auf der Default-Konfiguration kein Thema, weil Daten den EWR nicht verlassen, sofern ein Workspace nicht explizit an eine Nicht-EU-Region pinnt.

Wenn Compliance der Treiber ist, sollte der Migrationsplan ein Side-by-Side-Datenfluss-Diagramm enthalten: wo Klick-Events vorher lebten, wo sie jetzt leben. Dieses Diagramm ist das, was dein Auditor beim naechsten Assessment will.

Self-Hosting als Alternative#

Fuer Teams, deren Sicherheitsposture jeden SaaS-Shortener ausschliesst - Finanzdienstleister, Behoerden, Healthcare -, liefert Elido einen Apache-2.0-Helm-Chart aus. Dieselben Binaries, die in der EU-Region laufen, in deiner VPC deployt, BYO KMS fuer Verschluesselung, keine Drittanbieter-Sub-Processors. Die Migration sieht identisch aus, ausser dass Schritt 3 (DNS) auf deinen In-Cluster-Ingress zeigt statt auf edge.elido.me.

Das Self-Host-Runbook deckt Helm-Install, Secret-Bootstrapping und die Verkabelung der Authentifizierungsebene ab; veranschlage einen halben Tag fuer ein frisches Deployment auf einem bestehenden k8s-Cluster.

Developer-Workflow nach der Migration#

Sobald auf Elido ist die API die primaere Oberflaeche fuer jedes Team, das mehr als ein paar Links pro Woche erstellt. Die OpenAPI-3.1-Spec liegt unter /help; das @elido/sdk-Paket deckt die API in TypeScript ab, und ein Go-SDK liegt in packages/sdk-go.

Fuer agent-getriebene Workflows verbindet der Open-Source-MCP-Server Elido mit Claude, Cursor oder jedem MCP-faehigen Client:

{
  "mcpServers": {
    "elido": {
      "command": "npx",
      "args": ["-y", "@elido/mcp-server"],
      "env": { "ELIDO_API_KEY": "elido_pk_..." }
    }
  }
}

Standardmaessig Read-Only - Agenten koennen Analytics abfragen und Links suchen, ohne zu schreiben. Schreibrechte zu gewaehren ist eine bewusste Einstellung pro Workspace.

Finale Checkliste vor dem Cutover#

• Bitly-API-Token hat Zugriff auf alle Groups, nicht nur die Default-Group
• Inventar als JSONL exportiert, archivierte Links rausgefiltert, Anzahl gegen das Bitly-Dashboard quergeprueft
• Alle Slugs auf Elido unter der richtigen Custom Domain vorab provisioniert; Script lieferte 100 % Erfolg in einem Dry-Run
• Custom Domain im Elido-Workspace registriert und verifiziert, bevor DNS angefasst wird
• DNS-TTL auf dem bestehenden Bitly-CNAME auf 300s gesenkt, mindestens 24 Stunden vor Cutover
• Cloudflare Proxy-Modus und SSL-Einstellung als kompatibel mit Elidos Edge verifiziert
• Bitly-Lifetime-Klickzahlen zur Cutover-Stunde erfasst und fuer Reporting gespeichert
• Mindestens ein Reverse-Test-Link gedruckt und gescannt, um End-to-End zu bestaetigen
• Bitly-Konto fuer 90 Tage nach Cutover aktiv geplant als Versicherung fuer hardcodierte bit.ly-Links

Richtig gemacht ist die Aenderung fuer den Nutzer unsichtbar. Falsch gemacht verbringst du zwei Wochen damit, "warum ist bit.ly kaputt?"-Tickets von jemandem zu bearbeiten, der nicht weiss, dass es nicht seine Schuld ist.

Die technische Arbeit ist geradlinig. Die Disziplin liegt im Staging.

Verwandt im Blog#

• Migrate from Bitly without breaking links: a failure-modes playbook
• Migrate from Rebrandly: branded domain handover without slug loss
• EU data residency for marketing tools: what your DPO actually asks
• Set up branded short links: pick a domain, ship in an afternoon