Según Gartner, más del 70 % de los proyectos de migración de sistemas de atención al cliente presentan pérdida parcial de datos o interrupciones operativas durante el proceso. No porque la tecnología falle, sino porque la migración se trata como una tarea técnica cuando en realidad es un proceso de negocio. Tickets sin historial, contactos duplicados, adjuntos que no se transfieren y flujos de trabajo que dejan de funcionar son consecuencias frecuentes de una migración mal planificada.
Decidir migrar a Zendesk o a Freshdesk es una decisión que afecta directamente la operación de atención, telemarketing, ventas y cobranzas. Hacerlo sin perder datos requiere entender qué implica el proceso, qué métodos existen y en qué puntos del camino ocurren la mayoría de los errores. Este artículo cubre todo eso, paso a paso.
Qué implica migrar a Zendesk o Freshdesk
Migrar a una nueva plataforma de atención no es exportar un archivo CSV y abrirlo en otro sistema. Es un proceso de traslado estructurado que involucra múltiples tipos de datos, configuraciones y dependencias entre sistemas. Entender eso desde el inicio es lo que distingue una migración exitosa de una que genera semanas de reproceso.
Los elementos que están en juego en una migración típica incluyen los tickets históricos con todos sus estados y etiquetas, los perfiles de contacto y de empresa, los hilos de conversación con sus adjuntos, las notas internas de los agentes, las macros y respuestas predefinidas, los flujos de automatización y los datos de SLA configurados en la plataforma anterior.
Cada uno de esos elementos tiene una estructura diferente en Zendesk y en Freshdesk, y no siempre existe una equivalencia directa con la plataforma de origen. El proceso de mapeo —es decir, definir cómo cada campo del sistema antiguo se traduce al nuevo— es el trabajo central de cualquier migración. Sin ese mapeo bien hecho, los datos llegan al destino, pero en el lugar equivocado o sin el contexto que los hace útiles.
Qué datos se pueden migrar y cuáles no
No todos los datos de una plataforma de atención son portables. Saber qué es compatible con la migración y qué no lo es permite planificar el proceso con expectativas realistas y evitar sorpresas en producción.
Datos que generalmente se migran sin problemas
La mayoría de las plataformas modernas permiten migrar sin dificultades los tickets con su estado, prioridad y fechas de creación y cierre; los perfiles de usuario y de empresa; las etiquetas asociadas a los tickets; las notas internas de los agentes; y los hilos de conversación en formato texto. Estos son los datos estructurados y más estandarizados entre plataformas.
Datos que requieren tratamiento especial
Los archivos adjuntos —imágenes, documentos, grabaciones— suelen requerir configuración adicional porque se almacenan en servidores distintos al de los tickets. Si la plataforma de origen usa almacenamiento externo, los adjuntos pueden no transferirse automáticamente y hay que tratarlos por separado.
Las automatizaciones, disparadores y macros pueden existir en ambas plataformas, pero la lógica de configuración es diferente. En la mayoría de los casos hay que recrearlas manualmente en el nuevo sistema, no migrarlas directamente.
Datos que generalmente no se migran
Los reportes históricos y dashboards personalizados no son portables: están construidos sobre la estructura de datos de la plataforma anterior y no tienen equivalente directo en el destino. Los registros de actividad interna del sistema —logs de auditoría, registros de cambios de estado— tampoco suelen migrar. Conviene exportarlos y archivarlos antes de cerrar la plataforma anterior.
Cómo evaluar tu plataforma actual antes de migrar
El diagnóstico previo a la migración determina el alcance del proyecto y el nivel de riesgo. Saltarse esta etapa es la causa más frecuente de migraciones que se extienden semanas más de lo previsto.
Volumen y antigüedad de los registros
El volumen total de tickets, contactos y adjuntos define el tiempo estimado de migración y el método más adecuado. Una operación con 10,000 tickets tiene necesidades muy distintas a una con 500,000. La antigüedad de los registros también importa: datos de hace más de cinco años suelen tener estructuras inconsistentes que hay que limpiar antes de migrar.
Integraciones activas
Identifica qué sistemas están conectados a tu plataforma actual: CRM, ERP, herramientas de telefonía, plataformas de pago o sistemas de cobranzas. Cada integración activa es una dependencia que puede romperse durante la migración si no se planifica con anticipación.
Si quieres saber cómo se ve esto en la práctica, mira este video. 👇
Calidad de los datos existentes
Contactos duplicados, tickets sin asignar, campos vacíos o con datos incorrectos complican la migración y contaminan el nuevo sistema. Hacer una limpieza de datos antes de migrar reduce significativamente los errores en destino. No es el paso más visible, pero es uno de los que más impacto tiene en el resultado final.
Métodos disponibles para hacer la migración
Existen tres vías principales para migrar a Zendesk o Freshdesk. La elección depende del volumen de datos, la complejidad de la estructura y los recursos técnicos disponibles.
Migración manual
Consiste en exportar los datos de la plataforma anterior en formatos estándar (CSV, JSON, XML) e importarlos manualmente en el nuevo sistema usando las herramientas nativas de importación. Es viable solo para volúmenes pequeños —menos de 5,000 registros— y cuando la estructura de datos es simple. Para operaciones más grandes o con datos complejos, el riesgo de error es alto y el tiempo invertido es desproporcionado.
Herramientas nativas de importación
Tanto Zendesk como Freshdesk ofrecen herramientas propias para importar datos desde algunas plataformas específicas. Son rápidas de configurar cuando el origen es compatible, pero tienen limitaciones en el tipo de datos que transfieren —generalmente solo tickets y contactos básicos— y no siempre preservan el historial completo de conversaciones ni los adjuntos.
Plataformas de migración especializadas
Herramientas como Help Desk Migration, Trujay o Import2 están diseñadas específicamente para trasladar datos entre plataformas de soporte. Permiten mapear campos de forma visual, ejecutar migraciones de prueba antes de la definitiva y manejar adjuntos y conversaciones complejas con mayor fidelidad. Son la opción más completa para operaciones con alto volumen o con requerimientos de integridad de datos estrictos. Tienen un costo, pero ese costo generalmente es menor al reproceso que genera una migración manual mal ejecutada.
Pasos para migrar sin perder datos
Una migración ordenada sigue una secuencia clara. Cada paso tiene un propósito específico y saltarse alguno aumenta el riesgo de pérdida de información.
1. Exportación y auditoría de datos
Antes de iniciar, exporta todos los datos de la plataforma actual en el formato más completo disponible. Guarda esa exportación como respaldo independientemente de cómo resulte la migración. Luego audita los datos: identifica duplicados, campos vacíos y registros inconsistentes que hay que resolver antes de migrar.
2. Mapeo de campos
Define cómo cada campo de la plataforma de origen se corresponde con un campo en Zendesk o Freshdesk. Este es el paso más crítico: un mapeo incorrecto produce datos en el lugar equivocado, lo que es difícil de detectar y más difícil de corregir en producción. Documenta el mapeo en una tabla de referencia que el equipo técnico pueda revisar y validar.
3. Migración de prueba
Ejecuta una migración de prueba con un subconjunto representativo de datos —por ejemplo, los últimos 500 tickets— en un entorno de staging o en una instancia de prueba de la nueva plataforma. Verifica que los campos coinciden, que los adjuntos están disponibles y que el historial de conversaciones es completo.
4. Validación con el equipo
Antes de ejecutar la migración definitiva, involucra al equipo de atención en la validación. Ellos conocen los datos mejor que nadie y pueden detectar inconsistencias que el equipo técnico no identifica. Una ronda de revisión con los agentes evita sorpresas el día que el sistema entra en producción.
5. Migración definitiva y verificación post-migración
Ejecuta la migración en el horario de menor demanda operativa. Al terminar, verifica un muestreo aleatorio de registros en la nueva plataforma para confirmar la integridad de los datos. No desactives la plataforma anterior hasta que la operación haya estado corriendo al menos 48 horas sin incidencias en la nueva.
Errores frecuentes durante una migración a Zendesk o Freshdesk
La mayoría de los problemas en una migración son predecibles. Conocerlos de antemano permite tomar medidas preventivas antes de que afecten la operación.
-
Campos sin mapear: ocurre cuando la plataforma de origen tiene campos personalizados que no tienen equivalente en el destino. Si no se crean esos campos en Zendesk o Freshdesk antes de migrar, los datos se pierden o se acumulan en campos incorrectos.
-
Adjuntos que no se transfieren: especialmente frecuente cuando los archivos están alojados en servidores externos. La migración traslada el ticket pero no el enlace al archivo, que queda roto en el nuevo sistema.
-
Duplicados de contactos: si el sistema de origen tiene el mismo contacto registrado con variaciones en el nombre o el correo, la migración puede crear múltiples registros para la misma persona. Limpiar duplicados antes de migrar es más fácil que resolverlos después.
-
Pérdida de historial de conversaciones: sucede cuando la migración solo transfiere el último mensaje del hilo en lugar de toda la conversación. Hay que verificar explícitamente que el método elegido migra el hilo completo.
-
Automatizaciones que dejan de funcionar: las reglas de negocio y los disparadores configurados en la plataforma anterior no se migran automáticamente. Si el equipo asume que van a funcionar sin verificarlo, los flujos de atención se rompen en silencio.
-
No hacer migración de prueba: ejecutar la migración definitiva sin una prueba previa es el error más costoso. Detectar un problema en producción con miles de registros afectados implica un reproceso que puede durar días.
Cómo mantener la operación activa durante el proceso
Una migración bien ejecutada no tiene por qué detener la atención al cliente. La clave está en planificar el proceso de forma que los períodos de mayor riesgo coincidan con los momentos de menor demanda.
Período de congelamiento de datos
Define una ventana de tiempo —generalmente entre 2 y 6 horas— durante la cual no se crean ni modifican tickets en la plataforma anterior mientras se ejecuta la migración definitiva. Comunicar ese período al equipo con anticipación evita confusión y garantiza que los datos del origen están estables durante el traslado.
Migración por fases
En operaciones grandes, migrar todo de una sola vez es innecesariamente riesgoso. Es posible migrar primero los datos históricos —tickets cerrados de años anteriores— y luego los datos activos en una segunda fase. Así, el equipo puede empezar a operar en la nueva plataforma con el historial ya disponible, y la migración de datos activos se hace en un período de tiempo mucho más acotado.
Para que la transición a tu nueva plataforma sea más ordenada, mira este video. 👇
Ejecución en horario de baja demanda
Programar la migración definitiva en un horario de baja demanda —madrugada, fin de semana o festivo— reduce el impacto sobre el equipo y sobre los clientes. También da margen para detectar y corregir problemas antes de que el volumen de atención del día siguiente los amplifique.
Qué configurar en Zendesk o Freshdesk después de migrar
La migración de datos es solo el punto de partida. La operación no está realmente en marcha hasta que el nuevo sistema está correctamente configurado y el equipo lo usa con fluidez.
Verificación de integridad de datos
Antes de declarar la migración completada, verifica un muestreo de registros en cada categoría: tickets abiertos, cerrados y en proceso; contactos con y sin historial; adjuntos de distintos períodos. Una verificación sistemática detecta problemas que la migración de prueba no anticipó.
Reconfiguración de flujos y automatizaciones
Recrea en la nueva plataforma las reglas de negocio, los disparadores, las macros y los flujos de escalamiento que tenías configurados antes. Este paso hay que hacerlo con el equipo de atención, no solo con el equipo técnico, porque son los agentes quienes conocen qué flujos son críticos y cuáles pueden simplificarse.
Reintegración con CRM y otras herramientas
Reconecta la nueva plataforma con el CRM, las herramientas de telefonía, los sistemas de cobranzas y cualquier otra integración que estaba activa. Prueba cada integración de forma independiente antes de darla por operativa.
Capacitación del equipo
Por más completa que sea la migración técnica, si el equipo no sabe usar la nueva plataforma la operación va a ser ineficiente desde el primer día. Una sesión de capacitación focalizada en los flujos más frecuentes —crear tickets, asignar casos, usar macros y revisar el historial del cliente— reduce el tiempo de adaptación significativamente.
Conclusión
Decidir migrar a Zendesk o a Freshdesk es una decisión que tiene impacto directo en la continuidad operativa del equipo de atención. Hacerlo bien requiere diagnóstico previo, mapeo cuidadoso de datos, una migración de prueba antes de la definitiva y configuración completa del nuevo entorno antes de apagar el anterior. Los errores más costosos no son técnicos: son de planificación.
Si quieres evaluar cómo una plataforma omnicanal puede ser el destino de esa migración y simplificar la gestión de tu operación desde el primer día, conoce cómo funciona Beex y solicita una demostración.
