Ana Kowalska es ingeniera de soluciones en Elido que ha recorrido una docena de proyectos de migración a través del cutover de Bitly. Cree que la mayor parte del dolor es evitable si auditas antes de mudarte en lugar de después.
El migrate-from-bitly-playbook cubre el arco estratégico: audita lo que tienes, expórtalo, impórtalo, cambia el DNS. Ese artículo es el lugar correcto para empezar si no has hecho una migración desde Bitly antes.
Este artículo es diferente. Se centra en lo que se rompe - los modos de fallo específicos que emergen después de que el plan conceptual está hecho y estás realmente ejecutando la migración contra datos de producción. Siete de ellos surgen repetidamente, y los siete son prevenibles si sabes mirar.
TL;DR#
- Los slugs de Bitly son sensibles a mayúsculas; muchas plataformas de redirección no lo son.
bit.ly/AbCdybit.ly/abcdson enlaces diferentes en Bitly y se comportarán diferente si tu script de migración pasa los slugs a minúsculas en la importación. - Las brechas de TTL de DNS causan una brecha de redirección incluso después de que el CNAME cambie. Baja el TTL a 60 segundos al menos 24 horas antes del cutover, no cinco minutos antes.
- Los webhooks que apuntan a endpoints
api-ssl.bitly.comdejan de disparar en cuanto cancelas o desactivas la cuenta de Bitly. Recablea cada consumidor downstream antes de tocar el estado de la cuenta. - Los deeplinks con segmentos de ruta (
bit.ly/app/account/settings) colisionan con cualquier regla de enrutamiento de Elido que también coincida en prefijo de ruta. Audita los slugs de deeplink por separado de los slugs de redirección estándar.
Las siete cosas que realmente se rompen#
Antes de cualquier discusión de tooling, ayuda tener la taxonomía de fallos delante de ti. La mayoría de los postmortems de migración apuntan a uno de estos:
1. Sensibilidad a mayúsculas del slug. Bitly preserva mayúsculas en los slugs - bit.ly/SummerSale y bit.ly/summersale son enlaces distintos. Si tu script de importación normaliza los slugs a minúsculas (un predeterminado común en librerías de manejo de URL), silenciosamente creas el slug equivocado y la variante con mayúsculas devuelve 404. Esto afecta a campañas de email donde el slug fue incrustado con mayúsculas mixtas.
2. Comportamiento de barra final. bit.ly/campaign/ y bit.ly/campaign se manejan como el mismo enlace en el enrutador de Bitly. Algunas plataformas tratan la variante con barra final como una ruta distinta. Si tu workspace de Elido está fronteado por un proxy inverso con normalización estricta de URL habilitada, una petición con barra final puede resolverse de forma diferente al slug canónico.
3. Preservación de query string. Si la URL de destino de un enlace de Bitly ya contiene parámetros de consulta - https://acme.example/landing?source=bitly - y el clic también lleva parámetros UTM añadidos en el momento de compartir, necesitas verificar que el comportamiento de fusión de destino sea idéntico en Elido. El comportamiento predeterminado de Bitly para UTMs añadidos es fusionarlos en la query string existente. Prueba esto explícitamente para cualquier enlace cuya URL de destino ya lleva parámetros.
4. Añadido de UTM a nivel de plataforma. El nivel empresarial de Bitly soporta añadido de UTM a nivel de workspace: cada redirección saliente obtiene un UTM añadido independientemente de lo que contenga la URL de destino original. Si tenías esto habilitado en Bitly y no lo documentaste, puedes tener analítica dependiendo de UTMs que Elido aún no añade. Comprueba la configuración de tu workspace en Bitly para reglas de auto-añadido antes de exportar. El equivalente de Elido son plantillas UTM a nivel de workspace o campaña - la página de funciones de dominios personalizados cubre dónde vive esa configuración.
5. Brecha de TTL de DNS. Esta es la causa más común de una brecha de redirección en el cutover. Los resolvedores de DNS cachean el CNAME antiguo durante la duración del TTL actual. Si tu TTL ha estado en 86400 segundos durante dos años, cambiarlo a 300 segundos cinco minutos antes de cambiar el registro A significa que la mayoría de resolvedores aún retienen el registro antiguo durante otras 23 horas y 55 minutos. El cutover no es instantáneo; se propaga.
6. Recableado de webhooks. Cualquier sistema que consuma eventos de webhook de Bitly - pipelines de analítica, jobs de enriquecimiento de CRM, atribución de pedidos de Shopify - dispara contra la URL del endpoint de Bitly. Ese endpoint se apaga cuando cancelas o degradas la cuenta de Bitly por debajo del nivel que soporta webhooks. La configuración de webhooks de Bitly vive a nivel de cuenta y no se exporta con los datos de enlaces. Cada consumidor necesita ser inventariado y reapuntado manualmente.
7. Colisiones de ruta de deeplinks. Los deeplinks móviles a menudo usan la ruta de URL corta para codificar el estado de navegación de la aplicación - bit.ly/app/profile/edit podría mapear a un destino como yourapp://profile/edit. Cuando migras estos slugs a Elido, el slug app/profile/edit contiene barras. El enrutador de Elido puede tratar rutas delimitadas por barras de forma diferente al tratamiento de slug opaco de Bitly. Verifica que los slugs de deeplink con segmentos de ruta se creen con la cadena de slug exacta, no reinterpretados como rutas anidadas.
Auditoría previa a la migración: segmenta por nivel de riesgo#
La API de Bitly (consultada el 2026-05-12) expone los conteos de clic por enlace vía GET /v4/bitlink/{bitlink}/clicks/summary. Antes de exportar e importar nada, usa esto para segmentar tu inventario.
La segmentación práctica:
- Nivel no-puede-romperse (top 1%): enlaces con ≥10× el conteo de clic mediano en los últimos 30 días. Estos están en vivo en emails, materiales impresos, landing pages de anuncios pagados. Necesitan verificación manual después del cutover, no solo comprobaciones automatizadas.
- Nivel de monitorización (siguiente 9%): enlaces con volumen de clic por encima de la mediana. La verificación 301 automatizada es suficiente, pero marca cualquiera que resuelva inesperadamente.
- Nivel masivo (90% restante): slugs de bajo o cero tráfico. Verifica programáticamente; acepta una pequeña tasa de error y arregla en informe.
Exporta un resumen de clic de 30 días por enlace durante el paso de inventario. Un bucle de paginación sencillo contra la referencia de la API de Bitly (consultada el 2026-05-12) te da estos datos; el campo link_clicks en el endpoint de bitlinks de grupo es el contador de por vida, que es más grueso pero suficiente para triaje:
# Paginate all links in a Bitly group and write to JSONL
NEXT_URL="https://api-ssl.bitly.com/v4/groups/${GROUP_GUID}/bitlinks?size=100"
while [ -n "$NEXT_URL" ]; do
RESP=$(curl -s -H "Authorization: Bearer ${BITLY_TOKEN}" "$NEXT_URL")
echo "$RESP" | jq -c '.links[]' >> bitly-links.jsonl
NEXT_URL=$(echo "$RESP" | jq -r '.pagination.next // empty')
done
Ordena la salida por link_clicks descendente. El top 1% es tu nivel no-puede-romperse. Exporta sus slugs a un archivo separado antes de ejecutar la importación masiva.
Preservación de slug: la llamada de importación que importa#
El endpoint de importación masiva de Elido en POST /v1/links/bulk acepta un campo slug por enlace. Si no lo estableces explícitamente, Elido genera un nuevo slug aleatorio - que es el comportamiento incorrecto para una migración. Siempre pasa el slug fuente.
# Bulk import with slug preservation - 100 links per call
curl -s -X POST "https://api.elido.app/v1/links/bulk" \
-H "Authorization: Bearer ${ELIDO_API_KEY}" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: mig-batch-$(date +%s)" \
-d '{
"workspace_id": "'"${WORKSPACE_ID}"'",
"domain_id": "'"${DOMAIN_ID}"'",
"links": [
{
"slug": "SummerSale",
"destination_url": "https://acme.example/summer",
"tags": ["bitly-migrated", "campaign-summer"]
},
{
"slug": "AbCd",
"destination_url": "https://acme.example/landing",
"tags": ["bitly-migrated"]
}
]
}'
Dos cosas a notar en esta llamada. Primero, los valores de slug son "SummerSale" y "AbCd" - mayúsculas mixtas preservadas exactamente como aparecían en Bitly. No los pases a minúsculas. Segundo, el encabezado Idempotency-Key significa que puedes reejecutar un lote parcial de forma segura; Elido devuelve el enlace existente en lugar de crear un duplicado. Este es el patrón correcto para una migración que puede necesitar reanudarse.
Para el nivel no-puede-romperse, ejecuta la importación interactivamente por enlace en lugar de en un lote, y verifica cada uno antes de proceder. Para el nivel masivo, lotifica a 100 por llamada y procesa el array de errores en la respuesta para detectar cualquier slug que entró en conflicto o falló.
Cutover de DNS sin brecha#
El cutover de DNS es el momento en que el tráfico en vivo cambia. Hecho correctamente, los usuarios no experimentan interrupción. Hecho con un TTL obsoleto, hay una brecha medida en horas, no minutos.
La secuencia importa. Mira el diagrama de timeline abajo.
El timeline en detalle:
T−7 días: Baja el TTL en el CNAME o registro A a 60 segundos. Este es el paso crítico que la mayoría de equipos pierden. El RFC 1034 §3.6 (IETF datatracker, sección sobre caching de registros de recursos) define el TTL como la duración máxima de caché que un resolvedor puede mantener el registro. Si tu TTL actual es 86400 (un día), cambiarlo solo tiene efecto después de que la versión cacheada actual expire. Necesitas bajar el TTL al menos un período completo del TTL-actual antes del cutover. Una semana es seguro; 24 horas es el mínimo.
T−1 hora: Verifica que el TTL bajo se haya propagado. Usa una herramienta como dig @8.8.8.8 links.yourbrand.com +ttl desde al menos tres endpoints de resolvedor diferentes. El TTL reportado debería estar cerca de 60 segundos.
T−0: Cambia el destino del CNAME del edge de Bitly al edge de Elido. En el lado de Elido, el dominio ya debería estar registrado y verificado en tu workspace - no cambies el DNS antes de que el edge de Elido esté listo para aceptar el tráfico. La primera petición después de la propagación desencadena la emisión automática de certificado TLS bajo demanda, que se completa en aproximadamente 2-3 segundos en esa única petición. Las peticiones subsiguientes alcanzan el caché y resuelven en milisegundos de un solo dígito en el edge de la región de la UE.
T+5 minutos: Ejecuta una comprobación puntual desde una segunda red (usa un hotspot móvil para esquivar el caché del resolvedor de tu oficina). curl -sI https://links.yourbrand.com/any-known-slug debería devolver un 301 Moved Permanently apuntando al destino esperado, originado desde los encabezados del edge de Elido.
T+1 hora: Restaura el TTL a su valor operativo normal (300 o 3600 segundos). Mantener el TTL a 60 segundos indefinidamente añade carga a tu proveedor de DNS e infraestructura de resolvedor.
T+24 horas: Ejecuta la auditoría completa de slug (mira la siguiente sección).
Según el RFC 7231 §6.4.2, una respuesta 301 Moved Permanently puede ser cacheada por intermediarios indefinidamente a menos que un encabezado explícito de control de caché la sobrescriba. Esto significa que cualquier cliente que golpeara el destino antiguo de Bitly durante la brecha de TTL puede haber cacheado un 301 apuntando a la infraestructura de Bitly. Estas redirecciones cacheadas resuelven correctamente mientras la infraestructura de Bitly esté viva, por lo que la ventana de superposición de cuenta de Bitly de 30 días importa.
La auditoría de cadena 301: verificación nocturna scriptada#
Después del cutover, ejecuta un bucle de verificación nocturno sobre tu nivel no-puede-romperse. El objetivo es detectar cualquier slug que haya cambiado de comportamiento - devolver un destino inesperado, devolver un 404 o crecer una cadena de redirección más larga de dos saltos.
# Verify top slugs resolve correctly via Elido
# top-slugs.txt: one slug per line, no protocol prefix
DOMAIN="links.yourbrand.com"
FAIL=0
while IFS= read -r slug; do
STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
--max-redirs 0 \
"https://${DOMAIN}/${slug}")
LOCATION=$(curl -s -I --max-redirs 0 \
"https://${DOMAIN}/${slug}" \
| grep -i '^location:' | tr -d '\r' | cut -d' ' -f2)
if [ "$STATUS" != "301" ]; then
echo "FAIL [$STATUS] $slug → expected 301"
FAIL=$((FAIL + 1))
else
echo "OK [301] $slug → $LOCATION"
fi
done < top-slugs.txt
echo "---"
echo "Failures: $FAIL"
exit $FAIL
Ejecuta esto contra el nivel no-puede-romperse (típicamente 50-200 slugs para la mayoría de equipos) cada noche durante las primeras dos semanas después del cutover. Conecta la salida a tu canal de alertas. Si FAIL es distinto de cero, quieres que un humano lo mire antes de los picos de tráfico de la mañana.
La bandera --max-redirs 0 es intencional: quieres la redirección de Elido, no el destino final. Si el Status es 200 en lugar de 301, algo en el lado de Elido está sirviendo el destino directamente en lugar de redirigir, lo que significa que el slug resolvió a un enlace configurado como un pass-through directo. Eso vale la pena investigar.
Para el nivel de monitorización, ejecuta un escaneo semanal más ligero. Para el nivel masivo, confía en los informes de error de sistemas downstream - enlaces rotos en emails generan cambios en la tasa de rebote que tu plataforma de email mostrará.
Recableado de webhooks#
Los webhooks de Bitly están documentados en la referencia de la API de Bitly (consultada el 2026-05-12) bajo la sección de Webhooks. Cada webhook se dispara en eventos de clic e incluye los campos bitlink, referrer y user-agent. Consumidores comunes:
- Shopify: apps de atribución que rastrean qué enlace corto impulsó una conversión. Configurado en el panel de admin de la app de Shopify, apuntando a un endpoint de terceros que llama a la verificación de webhook de Bitly.
- Stripe: algunos pipelines de atribución de facturación etiquetan los registros de prueba entrantes con los datos UTM del enlace corto originario, obtenidos vía el webhook de Bitly.
- Slack: bots de rendimiento de enlaces que publican resúmenes de clics en un canal
#marketing. - Pipelines ETL personalizados: cualquier pipeline de almacén de datos que ingiera eventos de clic de Bitly para enriquecimiento o uniones de atribución.
La lista de comprobación de migración para webhooks:
- Exporta tu configuración de webhook de Bitly antes de cualquier cambio de cuenta. La API de Bitly
GET /v4/workspaces/{workspace_guid}/webhooksdevuelve la lista. Guárdala a un archivo. - Para cada consumidor, identifica la URL del endpoint que recibe eventos de Bitly y el secreto usado para verificación HMAC.
- Configura el endpoint de webhook equivalente de Elido. Los payloads de webhook de Elido tienen un esquema diferente al de Bitly - los campos son similares pero no idénticos. Ajusta el manejador del consumidor para aceptar el nuevo esquema.
- Ejecuta ambos webhooks en paralelo durante la ventana de superposición. Configura Elido para disparar webhooks desde el día del cutover, mientras mantienes activo el webhook de Bitly. Tu consumidor recibe dos eventos por clic durante la superposición - deduplica en URL corta + marca de tiempo, o acepta el doble conteo durante la ventana de superposición como un artefacto conocido.
- Después de 72 horas de entrega confirmada del webhook de Elido, elimina la configuración del webhook de Bitly de cada consumidor.
La ventana de gracia de rotación de secreto es el período de superposición. No rotes el secreto del webhook de Elido hasta que cada consumidor haya sido verificado. Rotar el secreto antes de que un consumidor sea actualizado significa que ese consumidor descarta silenciosamente eventos sin un error - la comprobación HMAC falla y la mayoría de manejadores de webhook descartan payloads de firma inválida sin alertar.
Plan de rollback: mantén Bitly vivo durante 30 días#
El procedimiento de rollback es simple: revierte el CNAME de DNS al destino de Bitly. Como pre-escenificaste la bajada de TTL y el registro DNS aún está a 60 segundos (hasta que lo restaures), una reversión de DNS se propaga en menos de dos minutos.
Escenifica el comando de rollback antes de empezar:
# Rollback script - run this to revert DNS to Bitly (adapt for your DNS provider)
# Route 53 example using AWS CLI
aws route53 change-resource-record-sets \
--hosted-zone-id "${HOSTED_ZONE_ID}" \
--change-batch '{
"Changes": [{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "links.yourbrand.com",
"Type": "CNAME",
"TTL": 60,
"ResourceRecords": [{"Value": "cname.bitly.com"}]
}
}]
}'
Mantén esto en un archivo en tu portátil y en una ubicación compartida de runbook antes del cutover. El peor momento para estar escribiendo comandos de infraestructura es durante un incidente activo.
Mantén la cuenta de Bitly activa y en un plan de pago que mantenga la resolución de enlaces durante 30 días después del cutover. El migrate-from-bitly-playbook recomienda 90 días; 30 es el mínimo práctico para equipos que necesitan controlar costes. Durante la ventana de 30 días, cualquier tráfico que aún resuelva vía Bitly (redirecciones cacheadas, enlaces antiguos bit.ly en materiales impresos) sigue funcionando. Después de 30 días, evalúa el tráfico residual de Bitly en tu analítica y decide si extender.
Qué monitorizar durante la ventana de 30 días:
- La tasa de error de Elido en tu dominio personalizado (vigila 404 inesperados en el log de acceso).
- Cualquier pico en tráfico a Bitly (el panel de Bitly muestra el tráfico; un pico puede significar que una redirección cacheada aún está resolviendo a través de Bitly para un slug de alto volumen).
- Tasas de error del consumidor de webhook para cualquier consumidor que recableaste.
Auditoría post-migración: qué registrar#
Después de la ventana de 30 días, ejecuta una pasada final de auditoría. Qué pertenece en el log de auditoría:
| Comprobación | Método | Criterio de éxito |
|---|---|---|
| Conteo de slugs coincide | wc -l bitly-export.jsonl vs conteo de API de Elido | Dentro del 1% (cuenta para enlaces archivados intencionalmente descartados) |
| Comprobación 301 del nivel no-puede-romperse | Script de auditoría nocturna | Cero fallos durante 7 días consecutivos |
| Reconciliación de volumen de clics | Compara el total de clics de Elido de 30 días vs el total de Bitly de 30 días del mismo período del año pasado | Dentro de la variación estacional esperada |
| Confirmación del consumidor de webhook | Verifica que cada consumidor está recibiendo eventos de Elido y procesando correctamente | Sin pérdidas silenciosas durante 7 días |
| TTL de DNS restaurado | dig +ttl links.yourbrand.com | TTL en valor operativo (300+ segundos) |
Registra esto en la tabla de auditoría de tu equipo. Si tu workspace está en un plan Business o Enterprise, el log de auditoría de Elido captura todas las operaciones de API durante la importación y es consultable vía la API. Saca los registros de lote de importación y almacena una instantánea junto a esta tabla.
Gotchas comunes: tres patrones del campo#
La marca de ecommerce DACH que perdió una semana de atribución de email. Un minorista en Alemania ejecutó una campaña de newsletter usando slugs de Bitly con UTMs por suscriptor añadidos en el momento de envío. El script de migración normalizó todos los slugs a minúsculas antes de importarlos a Elido. Después del cutover, la plataforma de email estaba generando enlaces con los slugs originales con mayúsculas mixtas. Esos enlaces devolvían 404 de Elido porque el caso del slug no coincidía. La solución fue reejecutar la importación con slugs con mayúsculas preservadas, pero para entonces siete días de tráfico de email habían aterrizado en 404. La atribución era irrecuperable para esa cohorte. La lección: prueba un enlace en vivo de cada canal activo antes de declarar la migración completa.
La startup SaaS que triple-redireccionó a usuarios móviles. Un equipo de crecimiento tenía un dominio personalizado de Bitly fronteado por Cloudflare en modo proxy (nube naranja). Después del cutover, los usuarios móviles estaban obteniendo tres redirecciones: Cloudflare → edge de Elido → destino. El salto extra venía de una Page Rule de Cloudflare que reescribía HTTP a HTTPS antes de pasar a Elido, luego Elido emitía su propio 301. iOS Safari cacheó la redirección intermedia de Cloudflare como una redirección permanente durante 30 días. La solución fue establecer el registro de Cloudflare a nube gris (solo DNS) y eliminar la Page Rule conflictiva. Las redirecciones cacheadas en Safari tardaron 30 días en expirar naturalmente. Verifica tu modo proxy de CDN antes del cutover, no después.
La agencia que perdió un grupo de Bitly. Una agencia gestionaba tres marcas de cliente bajo una sola cuenta de Bitly, cada una bajo un grupo de Bitly diferente con su propio dominio personalizado. El script de migración consultó solo el grupo predeterminado - aquel bajo el que se creó el token del usuario de API. Dos dominios de cliente migraron limpiamente. El tercero, bajo un grupo secundario, nunca se exportó. Después del cutover, una campaña de email de lanzamiento de producto salió apuntando al dominio personalizado no migrado. El dominio aún tenía el CNAME de Bitly a TTL completo, y Bitly estaba sirviendo los enlaces correctamente - pero la ventana de cutover para ese dominio había sido declarada hecha. La carrera fue una migración completa de nuevo bajo deadline. La lección: enumera todos los grupos vía GET /v4/user/groups antes de comenzar cualquier paso de exportación. Comprueba que el token tiene acceso a cada grupo.
Hacia dónde ir desde aquí#
El migrate-from-bitly-playbook cubre la secuencia estratégica completa para equipos que empiezan desde cero en planificación de migración. Este artículo es el compañero de modos de fallo - úsalos juntos.
Para el lado de producto a lo que estás migrando, la página solutions/marketers cubre las funciones de atribución y seguimiento de campañas que la mayoría de proyectos de migración intentan obtener. La página /compare/vs-bitly es la referencia de paridad de funciones si aún estás confirmando que el cambio vale la pena.
Si estás evaluando Elido junto a Rebrandly o Short.io, la comparación elido-vs-bitly cubre los compromisos de precios y funciones en cuatro volúmenes de tráfico. La página de funciones de dominios personalizados documenta la verificación de DNS y la mecánica de provisión de TLS en detalle - vale la pena leerla antes de tu ventana de cutover de DNS.
Los fallos de migración son casi siempre evitables. El script de auditoría, la disciplina de TTL y el inventario de webhook llevan dos horas de trabajo antes del cutover. Te ahorran días de respuesta a incidentes después.
Citaciones y fuentes
- Referencia de la API de Bitly - dev.bitly.com/api-reference, consultado el 2026-05-12
- RFC 1034 - Nombres de Dominio: Conceptos e Instalaciones, §3.6 (caching de registros de recursos) - datatracker.ietf.org/doc/html/rfc1034
- RFC 7231 §6.4.2 - HTTP/1.1 Semántica y Contenido: 301 Moved Permanently - datatracker.ietf.org/doc/html/rfc7231#section-6.4.2
- API de Bitly - Endpoints de Grupos y Bitlinks - dev.bitly.com/api-reference, consultado el 2026-05-12
Prueba Elido
Pega una URL, obtén un enlace corto
Sin registro. El enlace vive 30 días. Crea una cuenta para conservarlo.
Gratis, sin registro · 2 por día