La escena suele empezar así: la empresa decidió cambiar de CRM. La decisión vino de arriba, el contrato nuevo ya está firmado, y la noticia le llega a quien gestiona la atención junto con un detalle que nadie había mencionado: el sistema viejo se apaga en dos semanas.
Dentro del sistema viejo hay cuatro años de tickets. Cada reclamo, cada intercambio de correos, cada promesa hecha a un cliente, cada adjunto con una factura. Está el historial que el equipo consulta todos los días para responder "¿esto ya pasó antes?". Y ahora todo eso tiene que aparecer del otro lado, entero, en dos semanas.
El miedo que da en ese momento tiene fundamento. Ya vi migraciones en las que todos los tickets entraron al sistema nuevo con la fecha de creación del día de la importación. Cuatro años de historial se volvieron un jueves. ¿Informe de volumen? Perdido. "¿Desde cuándo este cliente se queja de esto?" Desde el jueves, aparentemente.
Por eso me robé el consejo de la tapa de la Guía del autoestopista galáctico: que no cunda el pánico, en letras grandes y amigables. La migración de datos tiene método. Antes de trabajar con CRM pasé cinco años en Adobe moviendo datos a gran escala con Hadoop y Spark, y trato una migración de helpdesk como aprendí a tratar un pipeline de datos allá: como una secuencia de etapas, y no como un copiar y pegar gigante.
Este artículo es el proceso que sigo, de punta a punta, armado en migraciones con Zendesk, Freshdesk, Salesforce, Movidesk y Zenvia. Sirve para quien va a contratar una migración y quiere entender qué está comprando, y sirve para quien va a ejecutar una y quiere un mapa.
Los tres tipos de migración
La primera conversación que tengo con un cliente sobre migración no es sobre herramientas. Es sobre qué quiere que pase con el historial. De esa conversación salen tres respuestas posibles, y yo las llamo tipo I, II y III.
Tipo I: el archivo muerto. Exportamos todo del sistema viejo y lo guardamos en un lugar consultable: una base de datos, un conjunto de hojas de cálculo bien organizado, a veces el propio sistema viejo mantenido en modo lectura por unos meses más. Nada de eso entra al CRM nuevo. Elige este tipo cuando el historial importa por obligación, auditoría o consulta eventual, pero no forma parte de la operación del día a día. El precio: cuando alguien necesite un ticket de 2023, va a buscarlo fuera del CRM. Es de lejos la opción más barata, y para muchas empresas alcanza. Parte de mi trabajo es decirlo en voz alta incluso cuando ganaría más vendiendo el tipo III.
Tipo II: la migración con campos legados. Los registros principales entran al CRM nuevo: clientes, tickets, conversaciones. Pero los campos específicos del sistema viejo no se traducen al modelo del sistema nuevo. Quedan estacionados en campos de legado, un "legacy_status" por aquí, un "legacy_categoria" por allá. Elige este tipo cuando necesitas continuidad rápida: el equipo abre el cliente y ve el historial entero en la misma pantalla, aunque una parte siga con las maletas hechas. El precio: te llevas el formato del sistema viejo adentro del nuevo. Un informe montado sobre un campo de legado siempre sale medio torcido, y un día alguien va a preguntar por qué existe un campo llamado legacy_fila_n2.
Tipo III: la migración completa. Cada campo del origen se mapea deliberadamente a un campo del destino, o se descarta de forma consciente. Status se vuelve status, prioridad se vuelve prioridad, el campo personalizado de allá se vuelve un campo personalizado equivalente de este lado. El historial se comporta como si siempre hubiera vivido en el sistema nuevo: se puede filtrar, se puede hacer informes, se puede automatizar encima. Elige este tipo cuando el CRM nuevo es la casa definitiva y el historial es parte de la operación. El precio es tiempo y dinero, porque la mayor parte del esfuerzo de una migración completa está en el mapeo, y un buen mapeo se hace con gente del negocio en la sala.
No trates esto como un ranking donde el tipo III es la respuesta correcta y los demás son la versión pobre. Es una perilla entre costo y fidelidad, y el punto correcto depende de cuánto vale el historial para la operación. Y los proyectos reales casi siempre mezclan los tipos: tipo III para los tickets abiertos y recientes, que tienen que funcionar de verdad en el sistema nuevo, y tipo I para los miles de tickets cerrados de hace años, que solo necesitan existir en algún lugar. Pagar precio de migración completa por datos que nadie va a abrir es quemar presupuesto.
El archivo muerto
Un export completo, guardado en algún lugar consultable. Nada entra al CRM nuevo.
Campos legados
Los registros principales entran; los campos viejos van de colados como legacy_*, sin traducción.
Mapeo completo
Cada campo mapeado o descartado a propósito. El historial se comporta como nativo.
Las precondiciones (o: nunca pierdas de vista tu toalla)
En la Guía del autoestopista, el viajero que se precie siempre sabe dónde está su toalla. En la migración, la toalla es el export completo de los datos. Antes de discutir mapeo, cronograma o cualquier otra cosa, lo primero es garantizar una copia íntegra de todo lo que existe en el sistema de origen, guardada en un lugar que es tuyo. Si el sistema viejo se apaga en dos semanas, esto no es la primera tarea de la lista. Es la tarea de hoy. Un CRM apagado no atiende pedidos de "un export más, por favor".
Después de la toalla, el resto de las precondiciones:
Acceso de administrador en los dos sistemas. No es cuenta de agente, es admin. La migración se ejecuta sobre API, y las APIs de exportación en general solo entregan todo a quien tiene permiso sobre todo. Buena parte de los atrasos de arranque de proyecto que ya vi era exactamente eso: esperando a que alguien descubriera quién es el dueño de la cuenta.
Alguien del negocio con tiempo reservado. El mapeo (ya llegamos a eso) no se escribe solo. Necesita a una persona que sepa responder qué significa aquel campo "Fila 2 - especial" creado en 2021, y por qué la mitad de los tickets lo tiene vacío. Sin esa persona la migración se traba. O peor: no se traba, y alguien decide solo.
La decisión de tipo, por escrito. Tipo I, II o III, o la mezcla, decidida y acordada antes de la primera línea de código. Cambiar de tipo a mitad del proyecto es rehacer el proyecto.
El acceso a los datos
Con las precondiciones en su lugar empieza la parte técnica, y con ella la primera sorpresa: "exportar los datos" significa algo distinto en cada sistema. Zendesk y Freshdesk tienen APIs maduras y bien documentadas, que entregan tickets, conversaciones y contactos sin drama. Salesforce te da informes y APIs poderosas, pero el dato vive en un modelo tan personalizable que primero necesitas entender qué hizo la empresa con él a lo largo de los años. Movidesk y Zenvia tienen APIs más escuetas, y a veces el camino incluye exports en hoja de cálculo para completar lo que la API no entrega.
Y está el detalle que separa a quien ya lo hizo de quien lo hace por primera vez: los adjuntos. El export te da el ticket y el texto de las conversaciones, pero los archivos, las capturas, el PDF de la factura, la imagen pegada en medio de una respuesta, todo eso en general viene como URL autenticada apuntando al servidor del sistema viejo. Migra el ticket e ignora los adjuntos, y el día en que el sistema viejo se apague cada uno de esos links se vuelve un 404. Bajar, guardar y re-hospedar adjuntos suele ser la parte más lenta de toda la extracción, y es la que nadie pone en el presupuesto.
El mapeo
El mapeo es la hoja de cálculo más importante del proyecto: de un lado, cada campo del sistema de origen; del otro, adónde va en el destino, más la regla de transformación en el camino. Campo por campo, con una columna de decisión: migra, se vuelve legado o muere. Parece burocrático y lo es. También es lo que decide si la migración va a servir.
origen (Movidesk) destino (Freshdesk) decisión
Status "Aguardando" Status "Pending" de-para directo
Urgencia 1 a 4 Priority Low a Urgent traduce la escala
Fila N2 legacy_fila (texto) pasa a legado
Motivo del contacto (ninguno) muere, decisión del negocioSolo que los campos son la parte fácil del mapeo. La parte difícil son las relaciones. Un ticket no existe solo: apunta al cliente que lo abrió, al agente que respondió, a la empresa del cliente. En el sistema de origen esos vínculos se hacen con IDs, y ninguno de esos IDs existe en el destino. La migración tiene que cargar primero las empresas, después los contactos, después los tickets, guardando en cada paso una tabla de traducción: el cliente 4471 de allá es el cliente 892 de este lado. Si te equivocas en ese orden, o pierdes esa tabla, el resultado es un CRM lleno de tickets huérfanos, sin dueño y sin cliente. Técnicamente migrado. En la práctica, inútil.
Y está la trampa que mencioné al principio: las fechas y las autorías. Todo CRM, al recibir un registro nuevo, estampa la fecha de creación como ahora y el autor como el usuario de la API. Es el comportamiento por defecto. Si la migración no hace nada al respecto, todos los tickets nacen el día de la carga, creados por el "usuario integración". Los buenos sistemas tienen alguna forma de preservar los valores originales en la importación, pero casi nunca es el camino por defecto de la API, y descubrirlo después de la carga es demasiado tarde. Esa es la pregunta que yo le haría a cualquier proveedor de migración: ¿cómo preservan la fecha y el autor originales? Quien ya lo hizo responde al instante.
El área de staging
Ahora el concepto que traje de la ingeniería de datos, el que sostiene todo junto: el área de staging. La idea viene de Ralph Kimball, de un libro clásico sobre ETL, y es simple: entre el origen y el destino existe un terreno neutral, una base de datos intermedia que es tuya, donde el dato extraído aterriza antes de cualquier transformación.
Todo el trabajo pasa ahí: la limpieza, el de-para de campos, la traducción de IDs, el chequeo de lo que llegó. El sistema de origen se lee una vez y después se lo deja en paz. El sistema de destino solo recibe datos cuando los datos están listos. Y cuando algo sale mal a mitad de camino, y algo siempre sale mal a mitad de camino, corriges en el staging y recargas, sin estresar la API de nadie y sin depender de que el sistema viejo siga vivo.
La alternativa, transformar el dato en vuelo, leyendo del origen y escribiendo directo en el destino, funciona en la demo y cobra caro en producción. Sin staging, cada error te obliga a extraer todo de nuevo. Con staging, el error cuesta una corrección y una recarga. En una migración con plazo apretado, esa diferencia es el proyecto.
Tickets y conversaciones
extraídos una vez, vía APIContactos y empresas
quién apunta a quiénAdjuntos
URLs autenticadasTerreno neutral
Tickets
fechas y autores originalesClientes
vínculos rehechosAdjuntos
re-hospedados, sin 404La prueba con muestra
Con el staging armado y el mapeo escrito, la tentación es cargar todo. Aguanta. Primero va una muestra: cien tickets, elegidos a dedo para incluir los casos raros. El ticket con veinte respuestas y tres adjuntos. El que fue fusionado con otro. El del cliente que fue borrado del registro. El que tiene emoji en el asunto y acentos en todos los campos, porque escribimos en portugués y el encoding roto es una tradición.
La muestra entra al CRM nuevo y ahí viene la parte importante: quien valida no soy yo, es el cliente. La persona del negocio abre esos cien tickets en el ambiente nuevo y verifica si cuentan la historia correcta: las fechas coinciden, las conversaciones están en orden, el adjunto abre, el campo que importa está donde debería. Es en esa validación donde aparecen las sorpresas baratas de encontrar temprano, del tipo "ah, ese campo nosotros lo leíamos de otra forma". Corriges el mapeo, ejecutas otra muestra, y solo cuando una muestra sale limpia la carga grande entra en el calendario.
La carga
La carga completa es la parte más previsible del proyecto y la peor entendida en el cronograma. El motivo tiene nombre: rate limit. La API del CRM de destino acepta un número limitado de requests por minuto, y la matemática no perdona. Una base con 180 mil tickets, cada uno con sus conversaciones y adjuntos, puede significar fácilmente más de un millón de llamadas a la API. Divide eso por el límite de la plataforma y el resultado se mide en días, no en horas. Quien promete migrar una base grande "en el fin de semana" o no hizo la cuenta o va a reventar el límite, ser bloqueado por la plataforma y ver la migración frenar a la mitad.
Por eso la carga se diseña para ejecutarse sola y sobrevivir a tropiezos: en lotes, con pausa entre llamadas para respetar el límite, con retry para cuando la API se atragante, e idempotente, una palabra fea para una idea simple: si el proceso se cae a la mitad y lo ejecutas de nuevo, sigue desde donde paró en vez de duplicar los diez mil tickets que ya habían entrado. El staging ayuda otra vez aquí, porque es ahí donde está la contabilidad: lo que ya pasó, lo que todavía falta.
La fecha de corte
Mientras la carga se ejecuta, la operación sigue atendiendo, y a cada hora que pasa nacen tickets nuevos en el sistema viejo. Es aquí donde entra la decisión más operativa del proyecto: la fecha de corte. A partir de este momento, toda conversación nueva nace en el sistema nuevo; lo que está en el viejo se congela y se vuelve pasado.
El diseño que suele funcionar: primero migra el historial, esa masa de datos que ya no cambia, con calma, durante la semana. Llegando la fecha de corte, el equipo cambia la llave y pasa a atender en el sistema nuevo. Y ahí se ejecuta una segunda migración, pequeña, solo del delta: los tickets que nacieron o cambiaron en el viejo entre el inicio de la carga y el corte. Así nadie deja de atender mientras el historial cruza, y el tramo incómodo con un pie en cada canoa dura horas, no semanas. Vale la pena acordar también el plan B: si algo sale mal en el cambio, el sistema viejo sigue accesible en modo lectura hasta que todo esté verificado. Nadie apaga nada el día del corte.
El chequeo posmigración
¿Migraste, terminaste? Todavía no. La última etapa es la verificación, y tiene dos niveles.
El primero es el de los números: conteo por entidad, origen contra destino. Tantos mil clientes allá, tantos mil aquí. Tickets, conversaciones, adjuntos, la misma cuenta. Cualquier diferencia necesita explicación por escrito, y "se perdieron algunos" no es explicación. En general la diferencia tiene una causa buena, tipo tickets de spam dejados atrás a propósito, pero eso tiene que estar en el papel.
El segundo nivel es el humano: una ronda final de verificación por muestreo, con el equipo de atención abriendo tickets viejos en el sistema nuevo durante los primeros días de operación y reportando cualquier cosa rara. Es el mismo espíritu de la muestra, ahora con la base entera y con quien lo usa de verdad.
Y dos providencias de despedida. El export completo del principio, la toalla, queda archivado, porque es tu copia de seguridad de la verdad original. Y el área de staging, que carga datos personales de clientes, se destruye después de que todo fue validado. Una copia intermedia de datos personales no es un souvenir de viaje. No se guarda.
Que no cunda el pánico
Vuelvo al gerente del principio, con el sistema apagándose en dos semanas. Lo que el proceso de esta página cambia no es el plazo, es el pánico. Dos semanas siguen siendo poco, pero se vuelven una secuencia de decisiones conocidas: garantiza el export hoy, decide el tipo, mapea con alguien del negocio al lado, prueba con una muestra antes de cargar, cambia la llave en una fecha acordada y verifica antes de festejar.
La migración de datos de CRM es uno de esos trabajos que, bien hecho, nadie nota. El equipo abre el sistema nuevo el lunes, el historial está ahí, las fechas coinciden, el adjunto abre, y la vida sigue. Es exactamente ese anticlímax el que perseguimos.
Si tienes una migración de esas en el horizonte, con plazo apretado o no, ven a conversar con nosotros en Red Lotus.
Leandro es fundador de Red Lotus Tecnologia, especializada en la implementación, soporte y evolución de Freshdesk para equipos de atención en Brasil.
Citados en este artículo
- Ralph Kimball y Joe Caserta. "The Data Warehouse ETL Toolkit." Wiley, 2004.
- Douglas Adams. "Guía del autoestopista galáctico." 1979. La parte de la toalla es el capítulo 3.