Migrare da Rebrandly: handover del dominio brandizzato senza perdita di slug

Rebrandly è costruito attorno a un'unica astrazione centrale: il dominio brandizzato. I slashtag, le tassonomie di tag e le regole di Traffic Routing vi si appoggiano tutte. Questa scelta di design è ciò che rende Rebrandly un prodotto coerente, ed è anche ciò che rende la migrazione da esso diversa da qualsiasi altro passaggio tra URL shortener.

Quando lasci Rebrandly, non stai principalmente migrando link. Stai migrando un dominio. I link vengono trascinati nel processo, e i dettagli su come preservarli dipendono quasi interamente da cosa decidi di fare con il dominio.

Questo post copre i due percorsi realistici, la struttura dell'export dall'API di Rebrandly, la chiamata di importazione in blocco su Elido e il processo di validazione prima di annunciare il cambio.

TL;DR#

• L'astrazione centrale di Rebrandly è il dominio brandizzato. La migrazione è prima un handover DNS, poi la preservazione dei link.
• Percorso A: il dominio rimane lo stesso, cambia solo lo shortener. Pre-provisiona gli slug su Elido, cambia il CNAME, fatto.
• Percorso B: cambia anche il dominio. Hai bisogno di una catena 301 dal vecchio dominio (tier Pro di Rebrandly) oppure accetti un cambio di slug sul nuovo dominio.
• I tag Rebrandly si mappano pulitamente sui tag Elido. Le categorie Rebrandly richiedono una mappatura manuale - non hanno un equivalente diretto.

Cosa inventariare prima#

Prima di impegnarti in uno dei due percorsi, fai un bilancio di quattro cose.

Dominio o domini brandizzati. Il modello workspace di Rebrandly consente più domini personalizzati per account. Su un workspace di agenzia o multi-brand, ogni dominio è un'unità di migrazione separata. Enumerali prima di pianificare le finestre di cambio - un dominio per notte è un calendario più sicuro che farne tutti insieme.

Link attivi. Usa l'API REST di Rebrandly (acceduta il 2026-05-12) piuttosto che l'export CSV per inventari grandi. L'endpoint /v1/links impagina con i parametri query last e limit e restituisce l'oggetto link completo inclusi slashtag, destinazione, nome del dominio, set di tag e createdAt. L'export CSV dal pannello delle impostazioni workspace va bene per meno di qualche centinaio di link ma tronca i campi in modo incoerente su export più grandi.

Integrazioni. Se il tuo team crea link tramite flussi di lavoro Zapier, Make o Workato, questi connector puntano all'API di Rebrandly. Ciascuno deve essere reindirizzato. È un compito separato dalla migrazione dei link con la propria finestra di grazia. Occupatene dopo il cambio DNS, non prima.

Tassonomia di tag e categorie. Rebrandly supporta sia tag in forma libera che categorie strutturate. I tag si mappano uno-a-uno sui tag Elido. Le categorie non hanno un equivalente diretto in Elido - la mappatura più vicina è un prefisso di tag riservato (cat:campaign, cat:region) che applichi durante l'importazione. Concordate la mappatura prima di eseguire lo script, non dopo.

Percorso A: il dominio rimane, cambia lo shortener#

Questa è la migrazione più pulita. Mantieni go.acme.com (o qualunque sia il tuo dominio abbreviato brandizzato). Pre-provisioni ogni slug su Elido sotto quello stesso dominio, poi cambi il CNAME. Dal punto di vista del clic sul link, non cambia nulla - lo slug si risolve nella stessa URL di destinazione, solo tramite un edge diverso.

Fase 1: export da Rebrandly#

Scorri l'API /v1/links di Rebrandly paginata. Gli oggetti risposta includono slashtag, destination, domain.fullName, tags[], category.name e createdAt. Salva come JSONL.

Due cose da gestire con attenzione. Prima, domain.fullName - se il tuo workspace ha più di un dominio, filtra quello che stai migrando in questo passaggio. Seconda, i piani tariffari di Rebrandly (acceduta il 2026-05-12) limitano quanti link e quanti domini personalizzati sono attivi per account. L'API restituisce tutti i link indipendentemente; il tuo inventario potrebbe includere link su domini che hai già ritirato. Filtrali prima dell'importazione.

Fase 2: pre-provisioning su Elido#

Registra il dominio nel tuo workspace Elido tramite il flusso dei domini personalizzati prima di toccare il DNS. Il dominio non deve essere ancora attivo. Elido valida la proprietà del dominio tramite un record DNS TXT; puoi completarlo senza disturbare il CNAME esistente che punta a Rebrandly.

Una volta registrato il dominio, importa i link in blocco. L'endpoint POST /v1/links/bulk accetta fino a 100 link per chiamata e restituisce il successo/fallimento per elemento, quindi un conflitto di slug su una riga non interrompe il batch. Passa slug esplicitamente per preservare lo slashtag di Rebrandly. Mappa tags[] di Rebrandly direttamente su tags[] di Elido. Passa created_at per preservare il timestamp di creazione originale per l'ordinamento storico.

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"
      }
    ]
  }'

Il tag rebrandly-migrated è utile per il filtraggio nell'analytics dopo il cambio - puoi segmentare i link pre-migrazione dai link creati nativamente su Elido e confrontare le tendenze dei clic nei primi 30 giorni.

Per la mappatura della tassonomia delle categorie: se summer-promo si trovava in una categoria Rebrandly chiamata Campaigns, aggiungi cat:campaigns all'array tags. Non è semanticamente equivalente, ma ti offre un filtro nelle visualizzazioni analytics e dashboard di Elido. Documenta la mappatura nelle note di migrazione.

Prima fai un dry-run. La maggior parte dei team esegue l'importazione in blocco contro un workspace di staging o con un piccolo campione (10-20 link) prima di inviare l'inventario completo. La superficie di risposta per elemento nell'endpoint bulk mostrerà in modo pulito eventuali conflitti di slug o errori di validazione della destinazione prima che tu ti stia impegnando con l'intero export.

Fase 3: cambio DNS#

Questo è il momento. Prima di arrivarci, verifica quanto segue:

• Tutti gli slug nell'importazione in blocco hanno restituito uno stato di successo. Nessun fallimento pendente.
• Il dominio è registrato e il TLS è predisposto nel tuo workspace Elido. Testa uno slug direttamente sull'edge di Elido aggiungendo temporaneamente il CNAME a un sottodominio di test, non a quello di produzione.
• Il TTL del CNAME Rebrandly esistente è stato abbassato. La pagina dei prezzi di Rebrandly (acceduta il 2026-05-12) mostra che la configurazione DNS è disponibile dal tier Free in su - puoi abbassare il TTL senza fare un upgrade. Abbassalo a 300 secondi almeno 24 ore prima della finestra di cambio.

Quando si apre la finestra, sostituisci la destinazione CNAME:

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

L'edge di Elido usa il TLS automatico on-demand. Se il TLS era già predisposto durante la pre-validazione (consigliato), la prima richiesta dopo la propagazione DNS è rapida. In caso contrario, il certificato viene predisposto alla prima richiesta - in genere 1-3 secondi, poi il certificato va in cache e le richieste successive vengono servite con un p95 inferiore a 15ms dall'edge in regione UE.

Verifica da più resolver prima di chiudere la finestra di modifica. Un controllo di propagazione dalla tua scrivania conferma solo il tuo resolver. Strumenti come dig @8.8.8.8 go.acme.com CNAME e dig @1.1.1.1 go.acme.com CNAME individuano le divergenze più comuni.

Percorso B: cambia anche il dominio#

Alcuni team approfittano della migrazione per rinominare il dominio brandizzato - da brand.ly (un sottodominio assegnato da Rebrandly) a qualcosa di loro piena proprietà, o da un dominio brand a un altro dopo un rebranding. Altri erano sul sottodominio di Rebrandly (yourname.rebrandly.com) e non hanno mai configurato un dominio personalizzato.

In entrambi i casi, lo spazio degli slug cambia. La domanda è se puoi installare una catena 301 dal vecchio dominio per minimizzare la rottura dei link.

Opzione B1: catena 301 dal vecchio dominio Rebrandly#

La funzionalità Traffic Routing di Rebrandly - disponibile sul tier Pro - ti consente di reindirizzare un intero dominio a un nuovo URL di base. Se possiedi il vecchio dominio e vuoi inoltrare il traffico, puoi impostare un redirect wildcard in Rebrandly che inoltri tutte le richieste go.old-domain.com/* a go.new-domain.com/* con corrispondenza dello slug.

La RFC 7231 §6.4.2 definisce la semantica del 301 Moved Permanently: i client che ricevono un 301 dovrebbero aggiornare qualsiasi URL memorizzato alla nuova posizione. In pratica, ciò significa che i codici QR esistenti, i materiali stampati e i link pubblicati si reindirizzeranno correttamente durante il periodo di sovrapposizione. Questo è il più vicino che puoi arrivare a una migrazione trasparente quando il dominio cambia.

Le meccaniche: mantieni il vecchio dominio attivo su Rebrandly durante il periodo di sovrapposizione, configurato come redirector pass-through. Esegui il nuovo dominio su Elido dal primo giorno della migrazione. Dopo 30-90 giorni (a seconda di quanto a lungo i tuoi materiali pubblicati rimangono in circolazione), ritira il vecchio dominio su Rebrandly.

Opzione B2: accetta il cambio di slug#

Se il vecchio dominio era un sottodominio assegnato da Rebrandly (yourname.rebrandly.com) o un dominio su cui non hai più il controllo DNS, non è disponibile alcuna catena 301. I link sul vecchio dominio continueranno a funzionare finché Rebrandly è in esecuzione e mantieni l'account attivo. Il traffico su quei vecchi link non transita da Elido; perdi la copertura analytics su di esso.

L'approccio pratico: migra l'elenco dei link su Elido su un nuovo dominio, crea nuovi slug per i link ad alto traffico e aggiorna le superfici pubblicate che contano, e lascia che la lunga coda di vecchi link a basso traffico decada su Rebrandly. Il migrate-from-bitly-playbook copre lo stesso framework decisionale per le migrazioni Bitly - il ragionamento si applica qui.

Per i team che decidono tra l'opzione B1 e B2, il calcolo è: quante superfici pubblicate contengono i vecchi link, quanto è difficile aggiornarle e per quanto tempo il traffico continuerà ad arrivare su quelle superfici. I link nell'archivio email ad alto traffico e i materiali stampati depongono a favore di B1. Pochi documenti interni depongono a favore di B2.

Export Rebrandly: cosa ottieni e cosa non ottieni#

L'API Rebrandly (acceduta il 2026-05-12) esporta i seguenti campi per link tramite /v1/links:

• id - ID interno del link di Rebrandly (non necessario nell'importazione ma utile come chiave di idempotenza)
• slashtag - lo slug da preservare
• destination - l'URL di destinazione completo inclusi i parametri UTM
• domain.fullName - il nome host del dominio personalizzato
• tags[] - tag in forma libera; si mappano direttamente sui tag Elido
• category.name - etichetta della categoria; si mappa manualmente su un prefisso di tag
• createdAt, updatedAt - timestamp; passa createdAt al campo created_at di Elido
• clicks.total - conteggio dei clic nel tempo; non importabile nell'analytics di Elido, ma vale la pena conservarlo in un tag (clicks-baseline-1234) o nel tuo layer dati

Cosa l'API non esporta:

• Eventi di clic grezzi. Rebrandly non espone record per-clic - ottieni solo conteggi aggregati. Il conteggio dell'analytics riparte da zero su Elido dal giorno del cambio.
• Regole di Traffic Routing. Se hai configurato redirect condizionali su qualsiasi link (routing per dispositivo o geo), quelle regole devono essere ricreate manualmente nell'editor smart link di Elido dopo l'importazione. Non esiste un'importazione in blocco delle regole di routing.
• Permessi dei membri del team. L'accesso al workspace deve essere re-invitato su Elido.

L'assenza di eventi di clic grezzi è la stessa limitazione che si incontra migrando da Bitly senza rompere i link. Il pattern per gestirla è lo stesso: conserva il contatore di tutto il periodo di Rebrandly, traccia i clic Elido dal cambio in avanti e combinali quando si riportano i totali storici.

Riconfigurazione dei webhook: Zapier, Make, Workato#

Se uno dei tuoi flussi di lavoro di automazione crea link Rebrandly, questi devono essere reindirizzati: un trigger CRM che crea un link di tracciamento per prospect, uno Zap che abbrevia link da un foglio di calcolo, uno scenario Make che genera codici QR per eventi.

Il meccanismo varia per piattaforma. Su Zapier, trova ogni Zap che utilizza l'app Rebrandly e sostituisci il passaggio di azione con l'app Zapier di Elido (controlla la disponibilità al lancio) o un'azione Webhook che chiama direttamente POST /v1/links. Su Make e Workato si applica la stessa sostituzione.

Due cose da sequenziare correttamente qui. Prima, non reindirizzare le automazioni finché il cambio DNS e l'importazione in blocco non sono confermati. Eseguire automazioni contro Elido prima che il pre-provisioning sia completo crea conflitti di slug duplicati. Seconda, aggiungi la chiave API Elido alla memorizzazione delle credenziali di ogni piattaforma di automazione prima del cambio - fallo in anticipo, non durante la finestra di cambio.

La finestra di grazia: per qualsiasi automazione che crea link a bassa frequenza (qualche alla settimana), lasciarla su Rebrandly per 1-2 settimane dopo il cambio DNS è a basso rischio. I link che crea saranno sulla vecchia piattaforma ma il DNS è già cambiato, quindi quei link si risolveranno tramite Elido. Per le automazioni ad alta frequenza che creano dozzine di link al giorno, migrale il giorno del cambio.

Per le API di Elido e gli SDK disponibili, la pagina dei prezzi copre i limiti del piano, e la referenza API completa si trova su /help. Sono disponibili SDK TypeScript, Python e Go.

Validazione prima di annunciare il cambio#

Non annunciare il completamento della migrazione finché non hai eseguito un spot-check strutturato. Due cose si rompono silenziosamente: gli URL di destinazione con problemi di encoding nell'export e gli slug che hanno colliso durante l'importazione in blocco e sono stati saltati.

Controllo dei 100 slug principali#

Ordina l'elenco dei link esportati per clicks.total in ordine decrescente. Prendi i 100 principali. Per ognuno, emetti una richiesta HEAD contro l'URL ospitato da Elido e verifica che l'header Location corrisponda alla destinazione attesa:

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

Una risposta 301 con l'URL di destinazione corretto conferma che lo slug funziona. Un 404 significa che lo slug non è stato pre-provisionato (controlla il log della risposta dell'importazione in blocco) o che c'è stata una mancata corrispondenza di case. Gli slashtag di Rebrandly sono case-insensitive nella risoluzione; gli slug Elido sono case-sensitive nella creazione. Se il tuo export ha slashtag in case misto, normalizzali in minuscolo prima dell'importazione.

Piano di rollback di 30 giorni#

Mantieni l'account Rebrandly attivo per 30 giorni dopo il cambio DNS. Il cambio DNS è completamente reversibile in qualsiasi momento durante quella finestra - punta il CNAME di nuovo sull'edge di Rebrandly e i vecchi link tornano a funzionare. Dopo 30 giorni, se le analytics mostrano zero anomalie nel tasso di successo dei redirect e il controllo degli slug è passato, l'account Rebrandly è sicuro da fare downgrade o annullare.

Per il dominio: non trasferire il registrar del dominio lontano da dove si trova attualmente durante la finestra di migrazione. La modifica CNAME è l'unica operazione DNS richiesta. Un trasferimento del registrar aggiunge rischi di propagazione che non sono necessari durante il cambio.

Contesto di migrazione interno#

Le meccaniche di questa migrazione rispecchiano il playbook Bitly. I pattern DNS, i tempi TTL e l'approccio di preservazione degli slug sono gli stessi. Se stai valutando il passaggio a livello di funzionalità prima di impegnarti nel lavoro di migrazione, il confronto elido-vs-rebrandly copre in dettaglio le differenze nel modello di prezzo e il gap di residenza UE. La documentazione di configurazione dei domini personalizzati su /features/custom-domains copre il lato Elido della verifica DNS e del provisioning TLS. E /pricing ha i limiti attuali del piano - il pre-provisioning di un grande inventario Rebrandly richiede il piano giusto prima di iniziare l'importazione.

---

Citazioni: Documentazione API Rebrandly acceduta il 2026-05-12. Pagina dei prezzi Rebrandly acceduta il 2026-05-12. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.