Migra de Rebrandly: traspaso de dominio de marca sin pérdida de slug

Rebrandly está construido alrededor de una abstracción central única: el dominio de marca. Slashtags, taxonomías de etiquetas y reglas de Traffic Routing cuelgan bajo él. Esa decisión de diseño es lo que hace a Rebrandly un producto coherente, y también lo que hace que migrar de él sea diferente a cualquier otra mudanza de acortador.

Cuando dejas Rebrandly, no estás migrando enlaces principalmente. Estás migrando un dominio. Los enlaces vienen contigo, y los detalles de cómo los preservas dependen casi enteramente de lo que decidas hacer con el dominio.

Este artículo cubre los dos caminos realistas, la forma de exportación desde la API de Rebrandly, la llamada de importación masiva a Elido y el proceso de validación antes de anunciar el cutover.

TL;DR#

• La abstracción central de Rebrandly es el dominio de marca. La migración es un traspaso de DNS primero, preservación de enlaces segundo.
• Camino A: el dominio permanece igual, solo cambia el acortador. Pre-aprovisiona slugs en Elido, cambia el CNAME, hecho.
• Camino B: el dominio también cambia. Necesitas o una cadena 301 desde el dominio antiguo (nivel Pro de Rebrandly) o aceptas un cambio de slug en el nuevo dominio.
• Las etiquetas de Rebrandly se mapean limpiamente a las etiquetas de Elido. Las categorías de Rebrandly necesitan mapeo manual - no tienen equivalente directo.

Qué tienes que inventariar primero#

Antes de comprometerte con cualquiera de los caminos, haz inventario de cuatro cosas.

Dominio o dominios de marca. El modelo de workspace de Rebrandly permite múltiples dominios personalizados por cuenta. En un workspace de agencia o multi-marca, cada dominio es una unidad de migración separada. Enuméralos antes de planificar ventanas de cutover - un dominio por noche es un horario más seguro que todos a la vez.

Enlaces activos. Usa la API REST de Rebrandly (consultada el 2026-05-12) en lugar de la exportación CSV para inventarios grandes. El endpoint /v1/links pagina con parámetros de consulta last y limit y devuelve el objeto completo del enlace incluyendo slashtag, destino, nombre del dominio, conjunto de etiquetas y createdAt. La exportación CSV desde el panel de configuración del workspace está bien para menos de unos pocos cientos de enlaces, pero trunca campos de forma inconsistente en exportaciones más grandes.

Integraciones. Si tu equipo crea enlaces a través de flujos de Zapier, Make o Workato, esos conectores apuntan a la API de Rebrandly. Cada uno necesita ser reapuntado. Esa es una tarea separada de la migración de enlaces con su propia ventana de gracia. Cúbrelo después del cambio de DNS, no antes.

Taxonomía de etiquetas y categorías. Rebrandly soporta tanto etiquetas de forma libre como categorías estructuradas. Las etiquetas se mapean uno a uno a las etiquetas de Elido. Las categorías no tienen equivalente directo en Elido - el mapeo más cercano es un prefijo de etiqueta reservado (cat:campaign, cat:region) que aplicas durante la importación. Acuerda el mapeo antes de ejecutar el script, no después.

Camino A: el dominio permanece, el acortador cambia#

Esta es la migración más limpia. Mantienes go.acme.com (o cualquiera que sea tu dominio corto de marca). Pre-aprovisionas cada slug en Elido bajo ese mismo dominio, luego cambias el CNAME. Desde la perspectiva del clic del enlace, nada cambia - el slug resuelve a la misma URL de destino, solo vía un edge diferente.

Paso 1: exportar desde Rebrandly#

Camina por la API /v1/links de Rebrandly paginada. Los objetos de respuesta incluyen slashtag, destination, domain.fullName, tags[], category.name y createdAt. Persiste como JSONL.

Dos cosas a manejar con cuidado. Primero, domain.fullName - si tu workspace tiene más de un dominio, filtra al que estás migrando en esta pasada. Segundo, los niveles de precios de Rebrandly (consultados el 2026-05-12) controlan cuántos enlaces y cuántos dominios personalizados están activos por cuenta. La API devuelve todos los enlaces independientemente; tu inventario puede incluir enlaces en dominios que ya has retirado. Filtra esos antes de importar.

Paso 2: pre-aprovisionar en Elido#

Registra el dominio en tu workspace de Elido vía el flujo de dominios personalizados antes de tocar el DNS. El dominio no necesita estar en vivo aún. Elido valida la propiedad del dominio a través de un registro TXT de DNS; puedes completar eso sin interrumpir el CNAME existente que apunta a Rebrandly.

Una vez que el dominio esté registrado, importa los enlaces en masa. El endpoint POST /v1/links/bulk acepta hasta 100 enlaces por llamada y devuelve éxito/fallo por elemento, de modo que un conflicto de slug en una fila no aborta el lote. Pasa slug explícitamente para preservar el slashtag de Rebrandly. Mapea tags[] de Rebrandly directamente a tags[] de Elido. Pasa created_at para preservar la marca de tiempo de creación original para la ordenación histórica.

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

La etiqueta rebrandly-migrated es útil para el filtrado de analítica después del cutover - puedes segmentar enlaces pre-migración de enlaces creados nativamente en Elido y comparar tendencias de clic durante los primeros 30 días.

Para el mapeo de taxonomía de categoría: si summer-promo vivía en una categoría de Rebrandly llamada Campaigns, añade cat:campaigns al array tags. No es semánticamente equivalente, pero te da un filtro en las vistas de analítica y panel de Elido. Documenta el mapeo en tus notas de migración.

Haz un dry-run primero. La mayoría de equipos ejecutan la importación masiva contra un workspace de staging o con una muestra pequeña (10-20 enlaces) antes de enviar el inventario completo. La superficie de respuesta por elemento en el endpoint masivo mostrará cualquier conflicto de slug o errores de validación de destino limpiamente antes de comprometer toda la exportación.

Paso 3: cutover de DNS#

Este es el momento. Antes de llegar aquí, verifica lo siguiente:

• Todos los slugs en la importación masiva devolvieron estado de éxito. Sin fallos pendientes.
• El dominio está registrado y TLS aprovisionado en tu workspace de Elido. Prueba un slug directamente contra el edge de Elido añadiendo temporalmente el CNAME a un subdominio de prueba, no a tu producción.
• El TTL del CNAME existente de Rebrandly se ha bajado. La página de precios de Rebrandly (consultada el 2026-05-12) muestra que la configuración de DNS está disponible desde el nivel Free hacia arriba - puedes bajar el TTL sin actualizar. Bájalo a 300 segundos al menos 24 horas antes de la ventana de cutover.

Cuando se abra la ventana, cambia el destino del CNAME:

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

El edge de Elido usa TLS automático bajo demanda. Si TLS ya fue aprovisionado durante la pre-validación (recomendado), la primera petición después de que el DNS se propague es rápida. Si no, el certificado se aprovisiona en la primera petición - típicamente 1-3 segundos, luego el certificado se almacena en caché y las peticiones subsiguientes se sirven a sub-15ms p95 desde el edge de la región de la UE.

Verifica desde múltiples resolvedores antes de cerrar la ventana de cambio. Una comprobación de propagación desde tu escritorio solo confirma tu resolvedor. Herramientas como dig @8.8.8.8 go.acme.com CNAME y dig @1.1.1.1 go.acme.com CNAME detectan la divergencia común.

Camino B: el dominio también cambia#

Algunos equipos toman la migración como oportunidad para renombrar el dominio de marca - de brand.ly (un subdominio asignado por Rebrandly) a algo que poseen completamente, o de un dominio de marca a otro después de un rebranding. Otros estaban en el subdominio de Rebrandly (yourname.rebrandly.com) y nunca configuraron un dominio personalizado.

En ambos casos, el espacio de slug cambia. La pregunta es si puedes instalar una cadena 301 desde el dominio antiguo para minimizar la rotura de enlaces.

Opción B1: cadena 301 desde el dominio antiguo de Rebrandly#

La función Traffic Routing de Rebrandly - disponible en el nivel Pro - te permite redirigir un dominio entero a una nueva URL base. Si posees el dominio antiguo y quieres reenviar tráfico, puedes configurar una redirección comodín en Rebrandly que reenvíe todas las peticiones go.old-domain.com/* a go.new-domain.com/* con coincidencia de slug.

El RFC 7231 §6.4.2 define la semántica 301 Moved Permanently: los clientes que reciben un 301 deberían actualizar cualquier URL almacenada a la nueva ubicación. En la práctica, esto significa que los códigos QR existentes, materiales impresos y enlaces publicados redirigirán correctamente durante el período de superposición. Esto es lo más cerca que puedes llegar de una migración transparente cuando el dominio cambia.

La mecánica: mantén el dominio antiguo en vivo en Rebrandly durante el período de superposición, configurado como redirector pass-through. Ejecuta el nuevo dominio en Elido desde el día uno de la migración. Después de 30-90 días (dependiendo de cuánto tiempo permanezcan tus materiales publicados en circulación), desmantela el dominio antiguo en Rebrandly.

Opción B2: acepta el cambio de slug#

Si el dominio antiguo era un subdominio asignado por Rebrandly (yourname.rebrandly.com) o un dominio del que ya no tienes control de DNS, no hay cadena 301 disponible. Los enlaces en el dominio antiguo seguirán funcionando mientras Rebrandly siga funcionando y mantengas la cuenta activa. El tráfico en esos enlaces antiguos no enruta a través de Elido; pierdes cobertura de analítica sobre él.

El enfoque práctico: migra la lista de enlaces a Elido en un nuevo dominio, crea nuevos slugs para los enlaces de mayor tráfico y actualiza las superficies publicadas que importan, y deja que la cola larga de enlaces antiguos de bajo tráfico decaiga en Rebrandly. El migrate-from-bitly-playbook cubre el mismo marco de decisión para migraciones de Bitly - el razonamiento aplica aquí.

Para equipos que deciden entre la opción B1 y B2, el cálculo es: cuántas superficies publicadas contienen los enlaces antiguos, cuán difíciles son de actualizar, y cuánto tiempo continuará llegando tráfico en esas superficies. Enlaces de archivo de email de alto tráfico y materiales impresos abogan por B1. Unos pocos documentos internos abogan por B2.

Exportación de Rebrandly: qué obtienes y qué no#

La API de Rebrandly (consultada el 2026-05-12) exporta los siguientes campos por enlace vía /v1/links:

• id - ID interno del enlace de Rebrandly (no necesario en la importación pero útil como clave de idempotencia)
• slashtag - el slug a preservar
• destination - la URL de destino completa incluyendo parámetros UTM
• domain.fullName - el hostname del dominio personalizado
• tags[] - etiquetas de forma libre; mapea directamente a etiquetas de Elido
• category.name - etiqueta de categoría; mapea a un prefijo de etiqueta manualmente
• createdAt, updatedAt - marcas de tiempo; pasa createdAt al campo created_at de Elido
• clicks.total - conteo de clic de por vida; no importable a la analítica de Elido, pero vale la pena almacenarlo en una etiqueta (clicks-baseline-1234) o en tu propia capa de datos

Lo que la API no exporta:

• Eventos de clic en bruto. Rebrandly no expone registros por clic - solo obtienes conteos agregados. El reloj de analítica empieza fresco en Elido desde el día del cutover.
• Reglas de Traffic Routing. Si has configurado redirecciones condicionales en cualquier enlace (enrutamiento por dispositivo o geo), esas reglas necesitan ser recreadas manualmente en el editor de smart links de Elido después de la importación. No hay importación masiva de reglas de enrutamiento.
• Permisos de miembros del equipo. El acceso al workspace necesita ser re-invitado en Elido.

La ausencia de eventos de clic en bruto es la misma restricción que encuentras migrando de Bitly sin romper enlaces. El patrón para manejarlo es el mismo: almacena el contador de por vida de Rebrandly, rastrea los clics de Elido desde el cutover hacia adelante, y combínalos al informar totales históricos.

Recableado de webhooks: Zapier, Make, Workato#

Si alguno de tus flujos de automatización crea enlaces de Rebrandly, esos necesitan ser reapuntados: un disparador de CRM que acuña un enlace de seguimiento por prospecto, un Zap que acorta enlaces desde una hoja de cálculo, un escenario de Make que genera códigos QR para eventos.

El mecanismo difiere por plataforma. En Zapier, encuentra cada Zap que usa la app de Rebrandly y reemplaza el paso de acción con o bien la app de Zapier de Elido (comprueba disponibilidad en el lanzamiento) o una acción de Webhook que llame POST /v1/links directamente. En Make y Workato, la misma sustitución aplica.

Dos cosas a secuenciar correctamente aquí. Primero, no reapuntes las automatizaciones hasta después de que el cutover de DNS y la importación masiva estén confirmados. Ejecutar automatizaciones contra Elido antes de que el pre-aprovisionamiento esté completo crea conflictos de slug duplicado. Segundo, añade la clave API de Elido al almacén de credenciales de cada plataforma de automatización antes del cambio - hazlo por adelantado, no durante la ventana de cutover.

La ventana de gracia: para cualquier automatización que crea enlaces a baja frecuencia (unos pocos a la semana), dejarla en Rebrandly durante 1-2 semanas después del cutover de DNS es de bajo riesgo. Los enlaces que crea estarán en la plataforma antigua pero el DNS ya está cambiado, por lo que esos enlaces resolverán vía Elido. Para automatización de alta frecuencia que crea docenas de enlaces por día, migra en el día del cutover.

Para la API y SDKs disponibles de Elido, la página de precios cubre los límites del plan, y la referencia completa de la API está en /help. Los SDKs de TypeScript, Python y Go están disponibles.

Validación antes de anunciar el cutover#

No anuncies la finalización de la migración hasta que hayas hecho una comprobación puntual estructurada. Dos cosas se rompen silenciosamente: URLs de destino que tenían problemas de codificación en la exportación, y slugs que colisionaron durante la importación masiva y fueron omitidos.

Comprobación de los 100 slugs principales#

Ordena tu lista de enlaces exportada por clicks.total descendente. Toma los 100 principales. Para cada uno, emite una petición HEAD contra la URL alojada en Elido y verifica que el encabezado Location coincida con el destino esperado:

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

Una respuesta 301 con la URL de destino correcta confirma que el slug está funcionando. Un 404 significa que el slug no fue pre-aprovisionado (comprueba el log de respuesta de importación masiva) o hubo una falta de coincidencia de sensibilidad a mayúsculas. Los slashtags de Rebrandly son insensibles a mayúsculas en la resolución; los slugs de Elido son sensibles a mayúsculas en la creación. Si tu exportación tiene slashtags con mayúsculas mixtas, normaliza a minúsculas antes de importar.

Plan de rollback de 30 días#

Mantén la cuenta de Rebrandly activa durante 30 días después del cutover de DNS. El cambio de DNS es completamente reversible en cualquier punto durante esa ventana - apunta el CNAME de vuelta al edge de Rebrandly y los enlaces antiguos funcionan de nuevo. Después de 30 días, si la analítica muestra cero anomalía en la tasa de éxito de redirección y la comprobación de slug ha pasado, la cuenta de Rebrandly es segura de degradar o cancelar.

Para el dominio: no transfieras el registrador del dominio fuera de donde está actualmente durante la ventana de migración. El cambio de CNAME es la única cirugía de DNS requerida. Una transferencia de registrador añade riesgo de propagación que es innecesario durante el cutover.

Contexto de migración interno#

La mecánica de esta migración es paralela al playbook de Bitly. Los patrones de DNS, el momento de TTL y el enfoque de preservación de slug son los mismos. Si estás evaluando el cambio a nivel de funciones antes de comprometerte al trabajo de migración, la comparación elido-vs-rebrandly cubre las diferencias de modelo de precios y la brecha de residencia UE en detalle. La documentación de configuración de dominios personalizados en /features/custom-domains cubre el lado de Elido de la verificación de DNS y aprovisionamiento de TLS. Y /pricing tiene los límites de nivel actuales - pre-aprovisionar un inventario grande de Rebrandly requiere el plan correcto antes de empezar a importar.

---

Citaciones: Documentación de la API de Rebrandly consultada el 2026-05-12. Página de precios de Rebrandly consultada el 2026-05-12. RFC 7231 §6.4.2 - HTTP 301 Moved Permanently.