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 Abhängigkeit. Bewege dich ungeschickt und du 404st einen relevanten Anteil eingehenden Traffics für 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 - üblich aus Gründen 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 tatsächlich migrieren musst

Drei Dinge ziehen um; sonst nichts auf der Wire-Ebene zählt.

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 Zähler - 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; darüber timeoutet er oder paginiert schlecht. Für größere Bestände 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 über 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.

Für große Bestände 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. Für 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 lässt:

• 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 über 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 ungefähr 10 Minuten, wenn du in Blöcken von 100 Links pro Aufruf mit moderater Parallelität 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 über Jahre 86400 war, ist "TTL senken" eine 24-Stunden-Wartezeit, keine fünfminütige Aufgabe. Plan darum herum.

Wenn das Änderungsfenster öffnet, 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 über automatisches On-Demand-TLS bereitgestellt; es gibt keinen manuellen Zertifikatsanforderungsschritt.

Verifiziere mit dig aus ein paar Netzwerken, bevor du den Cutover als erledigt erklärst. DNS-Propagation ist uneinheitlich; nur vom eigenen Laptop prüfen heißt, einen einzigen Resolver geprüft zu haben.

Schritt 4: Klick-Historie abgleichen

Bitly exportiert keine rohen Klick-Events. Plane keine Zeit für "deine Historie importieren" ein - es ist nicht möglich, und jedes Tool, das es verspricht, liest Aggregate und nennt sie Events.

Was du bekommst, ist der Pro-Link-Zähler 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 zählen.

Für 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-Aufschlüsselung nach Monat, Referrer-Trends -, kommen sie nicht zurück. Bau die Fragen auf Elidos rohem Event-Log nach vorne neu auf; die Migration ist der harte Schnitt.

Fünf Fallen, die in Woche zwei zubeißen

1. Hardcodierte bit.ly-Links in statischen Assets. PDFs, Druckmaterial, Embed-Snippets in Begrüßungsmails. Diese zeigen auf Bitlys Domain, nicht auf deine Custom Domain. Sie funktionieren weiter, solange du das Bitly-Konto behältst; sie brechen in dem Moment, in dem du es kündigst. Halt entweder ein kostenloses Bitly-Konto als Redirect-Only-Friedhof am Leben, oder akzeptiere den Verlust und kündige 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 während des Cutover-Fensters vorübergehend.

3. UTM-Truncation im Export. Bitly zeigt manchmal eine verkürzte Ziel-URL im Dashboard, speichert aber die kanonische volle URL. Der CSV-Export hat üblicherweise die volle URL; die Dashboard-Ansicht möglicherweise nicht. Wenn du das Dashboard scrapest statt die API aufzurufen, verlierst du UTMs. Geh immer über die API.

4. Bitlys API-Rate-Limits auf der Lese-Seite. Die Bitly-API drosselt aggressiv auf GET /bitlinks für 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 über die Jahre Domains unter verschiedenen Groups hinzugefügt hat, muss der Export alle Groups aufzählen, nicht nur die Default-Group. Versäumst du eine Group, wird diese Domain nicht migriert.

Compliance: warum die meisten Teams tatsächlich 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 läuft 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 für Healthcare-nahe Kunden, und der Tier-Sprung ist der Auslöser.

Elido ist standardmäßig EU-gehostet - Klick-Events laufen über die EU-Region, mit US East und Asien-Pazifik als Opt-in-Business+-Regionen. Die Sub-Processor-Liste sind fünf Anbieter, veröffentlicht unter /legal/subprocessors. ISO 27001 ist aktuell; SOC 2 Type II ist im Audit. BAA ist auf Business+ verfügbar. 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 nächsten Assessment will.

Self-Hosting als Alternative

Für Teams, deren Sicherheitsposture jeden SaaS-Shortener ausschließt - Finanzdienstleister, Behörden, Healthcare -, liefert Elido einen Apache-2.0-Helm-Chart aus. Dieselben Binaries, die in der EU-Region laufen, in deiner VPC deployt, BYO KMS für Verschlüsselung, keine Drittanbieter-Sub-Processors. Die Migration sieht identisch aus, außer 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 für ein frisches Deployment auf einem bestehenden k8s-Cluster.

Developer-Workflow nach der Migration

Sobald auf Elido ist die API die primäre Oberfläche für 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.

Für agent-getriebene Workflows verbindet der Open-Source-MCP-Server Elido mit Claude, Cursor oder jedem MCP-fähigen Client:

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

Standardmäßig Read-Only - Agenten können Analytics abfragen und Links suchen, ohne zu schreiben. Schreibrechte zu gewähren 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 quergeprüft
• 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 für Reporting gespeichert
• Mindestens ein Reverse-Test-Link gedruckt und gescannt, um End-to-End zu bestätigen
• Bitly-Konto für 90 Tage nach Cutover aktiv geplant als Versicherung für hardcodierte bit.ly-Links

Richtig gemacht ist die Änderung für den Nutzer unsichtbar. Falsch gemacht verbringst du zwei Wochen damit, "warum ist bit.ly kaputt?"-Tickets von jemandem zu bearbeiten, der nicht weiß, 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
• Werbung auf Bitly-Links: warum sie erscheint und wie man sie entfernt