La pregunta que frena casi todas las migraciones de soporte no es «¿cuál es mejor?». Es «¿y qué pasa con los cinco años de tickets que tengo ahí dentro?».
Es una preocupación legítima y tiene respuesta. Lo que suele salir mal en una migración no son los datos —eso está resuelto— sino tres cosas que nadie inventaría hasta que ya no funcionan: las direcciones de correo, los enlaces publicados y las costumbres del equipo.
Lo que sí te llevas
El histórico de tickets. Zendesk exporta conversaciones con su autor, su fecha, sus etiquetas y sus adjuntos. Sale en JSON o CSV según el plan. Es el trozo que más miedo da y el más fácil.
Los artículos del centro de ayuda. Salen con su estructura de secciones y categorías. Si tienes varios idiomas, salen los dos.
Los contactos y las organizaciones. Con sus campos personalizados, que suele ser donde está la información que de verdad usáis.
Los adjuntos. Van por separado, referenciados desde el ticket. Ojo con esto: si el enlace del adjunto apunta a un dominio de Zendesk, deja de resolver el día que cierras la cuenta. Hay que descargarlos, no solo exportar la referencia.
Lo que no se exporta
Aquí es donde conviene ser honesto, porque ninguna herramienta de migración lo resuelve del todo.
Las macros y los automatismos. Se exportan como texto, pero no como comportamiento. Cada disparador hay que volver a montarlo en el destino. La buena noticia: normalmente descubres que la mitad ya no se usaban.
Los informes históricos. Los datos de origen viajan; los cuadros de mando no. Si tienes un informe que la dirección mira cada mes, haz una captura antes de cerrar.
Las integraciones. Cada una tiene su propia autenticación y hay que rehacerla. Inventaríalas antes: casi siempre hay dos o tres que nadie recordaba que existían.
Las métricas de nivel de servicio ya calculadas. El tiempo de primera respuesta de 2024 no se recalcula en la herramienta nueva. Si lo necesitas para una auditoría, expórtalo como informe, no como dato.
El orden que evita el corte
El error clásico es migrar el correo el primer día. El correo es lo último.
1. Inventario (medio día)
Antes de tocar nada, apunta: cuántos tickets hay, cuántos artículos, qué direcciones de correo entran, qué integraciones están vivas y quién tiene acceso. Esta lista es la que te dice si has terminado.
2. Monta el destino en paralelo (unos días)
Sin apagar nada. La herramienta nueva funcionando, con el centro de ayuda cargado y el agente conectado a tu documentación. En nuestro caso esto es conectar el centro de ayuda y decidir qué acciones puede ejecutar sobre tu API.
3. Importa el histórico (una noche)
Con los dos sistemas vivos. Si algo sale mal, no te has quedado sin soporte: sigues teniendo el de siempre.
4. Prueba con un canal pequeño (una o dos semanas)
Un canal secundario, o un segmento de clientes. Lo que buscas no es que funcione: es enterarte de qué preguntas no sabe responder todavía y con qué frecuencia escala a una persona.
5. Mueve el correo (un día)
Ahora sí. Cambias el registro MX o el reenvío, y dejas Zendesk recibiendo en paralelo unas semanas por si algo estaba apuntando ahí sin que lo supieras.
6. Redirige los enlaces publicados (media hora, y es la que se olvida)
Las URLs de tu centro de ayuda están enlazadas desde tu producto, tus correos automáticos y, si has tenido suerte, desde Google. Si las apagas sin redirigir, se convierten en 404 y pierdes tanto las visitas como el posicionamiento que costó años ganar.
Redirige cada artículo antiguo a su equivalente nuevo con un 301, no con un 302. Un 302 le dice al buscador que la dirección vieja sigue siendo la buena, así que la mantiene indexada y no traspasa nada a la nueva.
7. Cierra la cuenta antigua (cuando el inventario esté en verde)
No antes. Y guarda una copia del volcado completo fuera de las dos herramientas.
Cuánto se tarda de verdad
Para un equipo de dos o tres personas con unos años de histórico: entre dos y cuatro semanas de calendario, de las cuales el trabajo real son unos tres días. El resto es el periodo en paralelo, y es tiempo bien gastado.
Lo que alarga una migración no es el volumen de datos. Es descubrir en la semana tres que había un formulario en la web que enviaba a una dirección que nadie recordaba.
Antes de empezar, la pregunta previa
Una migración solo compensa si el problema que tienes lo resuelve el destino. Antes de mover nada, coge las últimas cien conversaciones y mira cuántas necesitan consultar la cuenta del cliente para responderse.
Si son muchas, ninguna suite ni ningún bot documental te va a bajar el volumen, y habrás migrado para quedarte igual. Si son pocas, quizá no necesitas migrar: te vale con añadir algo encima de lo que ya tienes.
Ese ejercicio, con las dos herramientas al lado, está en la comparativa entre Intake y Zendesk.
Sobre los datos
Migrar significa mover conversaciones de clientes de un proveedor a otro, así que conviene mirar dónde acaban. Nuestra plataforma, las copias de seguridad y los modelos de lenguaje que usa el agente se ejecutan en regiones de la Unión Europea; el detalle está en la página de seguridad y en el anexo de tratamiento de datos.
