Un cliente nos contactó recientemente con un problema que la mayoría de las empresas de servicios en crecimiento reconocerán. Su trabajo estaba distribuido entre ClickUp y Freshservice. Necesitaban permisos más detallados para sus interacciones con clientes altamente reguladas, así como la capacidad de automatización necesaria para brindar un servicio al cliente consistente a gran escala. Decidieron cuál sería su solución: HaloPSA, y concluyeron que esta podría reemplazar ambas herramientas. Sin embargo, existía un obstáculo: necesitaban conservar años de datos históricos de los que dependían sus propios clientes para la continuidad del servicio. Esto significaba que el principal obstáculo para migrar a una nueva herramienta sería la tarea que nadie quiere realizar: la migración de datos.
La respuesta tecnológica suele ser clara cuando nos llaman: hay una plataforma objetivo que funcionaría mejor. El obstáculo no es qué herramienta usar, sino el temor a que el proceso sea lento, costoso e impredecible. Se perderán tickets, fallarán los informes, los equipos se rebelarán, los reguladores o los clientes podrían oponerse, y los costos se dispararán.
Pero nada de eso es inevitable. Bien hecha, la migración de datos no debería ser una barrera para operar su negocio con las herramientas adecuadas. La consolidación puede —y debe— ser una oportunidad para mejorar la forma en que el negocio realmente opera, no solo para mover datos de A a B. Así es como lo abordamos.
Las dos mitades de la consolidación
Un proyecto de consolidación consta de dos partes que son fáciles de confundir, pero que son muy diferentes en naturaleza.
El primer paso es la transferencia de datos : transferir tickets, comentarios, archivos adjuntos, usuarios, campos personalizados y registros históricos desde las plataformas de origen a las de destino. Este es un trabajo puramente técnico. Para cualquier caso que vaya más allá de los más sencillos, se trabaja con API, a menudo siguiendo un orden estricto, ya que los archivos adjuntos dependen de los tickets, los comentarios de los usuarios, los campos personalizados de los esquemas, etc. Las importaciones de archivos planos facilitan el proceso en parte, pero no lo completan del todo. Este es precisamente el tipo de trabajo para el que existen herramientas especializadas, como Help Desk Migration .
El segundo aspecto es el del modelo operativo : decidir cómo debería funcionar la nueva plataforma para la empresa. ¿Qué categorías de trabajo se gestionan a través de ella? ¿Cómo debería ser un buen sistema de informes? ¿Quién gestiona cada cola? ¿Qué nuevas funcionalidades están ahora disponibles (facturación, autoservicio al cliente, gestión integrada de cambios) que antes no eran posibles, y cuáles conviene activar ahora en lugar de más adelante?
Estas dos partes se necesitan mutuamente. Si solo implementas la primera, tendrás el mismo problema en un sistema nuevo. Si solo implementas la segunda, te quedarás estancado porque no podrás recuperar los datos históricos.
El error más común en los proyectos de consolidación es tratarlos simplemente como una migración de datos. Las mayores ventajas —y los mayores riesgos— residen en el modelo operativo.
Por qué la consolidación es más difícil de lo que parece
Parte de la complejidad es genuinamente técnica. Parte es organizativa. Las trampas que vemos con más frecuencia:
1. El mapeo de datos no es ordenado. Diferentes herramientas estructuran los mismos conceptos de manera diferente. Nombres de estado, niveles de prioridad, tipos de tickets, campos personalizados, categorías, tipos de solicitud: casi nada se mapea uno a uno. La parte difícil no es escribir el mapeo; es decidir cómo debería ser el mapeo, lo que obliga a tomar decisiones sobre el modelo operativo antes de que estés preparado para ellas.
2. El modelo agente/usuario/cliente varía entre herramientas. Algunas plataformas separan a los agentes internos de los usuarios externos y los clientes externos como tres tipos de entidades distintos. Otras los fusionan. Algunas permiten que los agentes sean socios externos; otras no. La forma en que Freshservice modela a las personas no es la misma que la Halo , ni la misma que la Jira Service Management . Migrar usuarios rara vez es un copiar y pegar; es una traducción, y las decisiones que tomes aquí dan forma a los permisos, los informes y las licencias durante años.
3. Los campos personalizados y los tipos de tickets se acumulan. La mayoría de los sistemas de origen tienen años de personalización acumulada, parte de ella útil, gran parte olvidada. Migrarlo todo recrea el mismo problema de mantenimiento en una nueva herramienta. Migrar solo lo necesario obliga a tener conversaciones difíciles con las personas que crearon esos campos.
4. Los permisos se vuelven más complicados, no menos. Una plataforma consolidada suele tener más equipos que la utilizan que cualquier fuente individual. Eso significa nuevos modelos de permisos, nuevas reglas de visibilidad y un listón más alto para hacerlo bien, porque los errores son más visibles.
5. Los informes son donde aparecen primero los errores. Los sistemas de origen a menudo tienen informes que dependen de estructuras de campos, estados o convenciones de nomenclatura específicas. Cuando estos cambian en el destino, los informes fallan y las partes interesadas lo notan de inmediato. Los requisitos de informes deben diseñarse en la migración, no añadirse después.
6. Normalmente necesitarás una migración de prueba completa. No una muestra, ni una parcial, sino una migración UAT completa con datos reales, contra el destino configurado, ejecutada por las personas que realmente usarán el nuevo sistema. Aquí es donde surgen las verdaderas sorpresas: formas de datos que no esperabas, decisiones de mapeo que resultan erróneas, integraciones que necesitan ajustarse. Presupuesta el tiempo y el costo para ello. Intentar saltarse esta etapa es el atajo más costoso en la consolidación.
7. Los requisitos regulatorios y de los clientes a menudo dictan qué debe conservarse. A veces, un cliente quiere "dejar atrás el sistema antiguo y empezar de cero", pero sus propios clientes, o sus reguladores, exigen que se conserven los tickets, comentarios y archivos adjuntos históricos para fines de auditoría. Esto cambia por completo el alcance de la migración, porque el registro de comentarios y archivos adjuntos es la parte que requiere más trabajo con la API y una secuenciación más cuidadosa. Hemos tenido proyectos donde el requisito de retención de datos fue la única razón por la que el diseño de la migración se complicó. Averígüelo con anticipación.
Un enfoque práctico
Todas las consolidaciones que hemos realizado han seguido prácticamente el mismo patrón. El orden importa menos que las etiquetas.
1. Entienda qué se está usando realmente. Antes de mapear nada, averigüe cómo se usan realmente los sistemas de origen hoy en día, no cómo se pretendía que se usaran, ni lo que dice la documentación. Obtenga informes de uso. Hable con las personas que hacen el trabajo. Por lo general, encontrará que una parte significativa de la personalización en el sistema de origen está inactiva o ya no es relevante. Eso no es un problema; es una oportunidad para consolidar en un objetivo más simple.
2. Defina el modelo operativo objetivo. Esta es la pregunta a la que volvemos una y otra vez: ¿qué quiere que la nueva plataforma haga por el negocio que las antiguas no hacen? ¿Mejores informes de SLA? ¿Facturación integrada? ¿Portales de solicitud de autoservicio? ¿Gestión de cambios vinculada a una CMDB? Cada uno de estos lleva la configuración en una dirección particular. Decida qué está optimizando antes de comenzar a mapear datos.
3. Diseñe el mapeo de datos en función del nuevo modelo, no del antiguo. El error que cometen la mayoría de los equipos es mapear la estructura de datos de origen directamente en el destino. El enfoque correcto es mapear los datos de origen a través del modelo operativo de destino: qué campos ganan su lugar, cuáles se archivan, cuáles se retiran, cuáles se consolidan juntos. Aquí es donde convergen las decisiones del modelo operativo y la migración técnica.
4. Ejecutar migraciones de prueba dirigidas. Antes del ensayo general completo, (tickets de un solo equipo, o un flujo de trabajo personalizado, o un grupo de usuarios) para validar que la lógica de mapeo y la secuencia de API realmente funcionan de extremo a extremo. Estas pruebas cortas detectan problemas cuando son baratos de solucionar.
5. Ejecutar una migración UAT completa. El ensayo general. Datos completos, configuración completa, usuarios reales probando escenarios reales. Presupuestar el tiempo. Esta es la etapa que determina si la transición real es tranquila o caótica.
6. Transición con un plan, no con una esperanza. Comunicaciones, criterios de reversión, cobertura de soporte, quién decide qué durante el período. La transición en sí suele ser decepcionante si la UAT fue exhaustiva.
7. Apoyar la adopción adecuadamente. Una herramienta nueva que funciona a la perfección pero que nadie usa es un proyecto fallido. Su adopción requiere promotores internos, documentación clara, capacitación adaptada a la forma de trabajar real y un respaldo visible por parte del liderazgo. Este es el aspecto que los proyectos de migración puramente técnicos suelen subestimar.
Un ejemplo reciente
La migración tuvo que gestionar tres formatos de datos diferentes:
- Documentos de ClickUp, donde la estructura era similar a la de una wiki y estaba vinculada a proyectos
- Tareas de ClickUp, donde el modelo estaba anidado y tenía en cuenta las dependencias
- Tickets de Freshservice, donde el modelo era un esquema de ticket clásico con comentarios, archivos adjuntos y relaciones con el solicitante
Cada uno de estos elementos debía ser mapeado , no en una réplica exacta de cómo existían en el sistema de origen, sino en el modelo operativo que habíamos diseñado para el sistema de destino. Los documentos iban por un camino, las tareas por otro, los tickets por un tercero, y en algunos casos era necesario realizar referencias cruzadas porque el mismo trabajo empresarial estaba representado en diferentes sistemas.
Existe una alternativa para este tipo de trabajo: escribir scripts de migración directamente en las API de origen y destino. Es algo que hemos hecho en proyectos anteriores, y las herramientas de IA lo están haciendo más rápido. Pero en proyectos donde la estructura de los datos es variada, la configuración de destino es compleja y el plazo es crucial, usar las herramientas especializadas de Help Desk Migrationreduce considerablemente los riesgos de la migración de datos y acorta el plazo. Esto nos permitió centrarnos en lo que el cliente realmente necesitaba: la configuración, el diseño de la automatización y el modelo de permisos.
Lo que le importaba al cliente no era simplemente "haber migrado los datos con éxito". Lo que le interesaba era que la nueva plataforma les proporcionara los controles y las automatizaciones que su negocio necesitaba, sin perder el historial de datos en el que confiaban sus propios clientes. Esa es la diferencia entre un proyecto de migración de datos y un proyecto de consolidación.
Observamos dinámicas similares cuando el destino es una plataforma PSA, que incorpora funciones de facturación, gestión de cobros, rentabilidad de proyectos y control horario, además del trabajo operativo. Para ver un ejemplo práctico de consolidación en HaloPSA, consulte nuestro reciente caso de estudio en bdq.cloud.
Dónde encaja Help Desk Migration
No pretendemos ser una empresa de herramientas para la migración de datos. El trabajo técnico de crear y ejecutar scripts de migración en múltiples API de plataforma, en la secuencia correcta, manejando casos especiales para archivos adjuntos, comentarios y asignaciones de usuarios, es un oficio especializado, y Help Desk Migration es realmente bueno en ello.
Igualmente importante, las herramientas especializadas permiten prever tanto el coste como el plazo de la migración de datos. El gasto en migración debe ser un concepto fijo, no un riesgo incierto; y cuando se conoce, resulta mucho más fácil aprobar el análisis de viabilidad para una consolidación más amplia.
El punto al que volvemos una y otra vez
La migración de datos no debería ser un obstáculo para gestionar tu negocio con las herramientas adecuadas. Puede ser costosa, consumir mucho tiempo y ser arriesgada, pero con los socios y el enfoque correctos, no es motivo para permanecer en una plataforma que ya no te sirve.
Las organizaciones que más se benefician de la consolidación son aquellas que la ven como una oportunidad para mejorar el modelo operativo, no solo para transferir datos. El valor empresarial no reside en los aspectos técnicos de la programación de API y la asignación de campos. El valor empresarial reside en mejores informes, mejores procesos, mejor automatización y equipos que realmente pueden ver y actuar sobre el trabajo que importa.
Si estás considerando una consolidación, la pregunta que vale la pena plantearse no es "¿cómo movemos los datos?", sino "¿cómo debería ser esto una vez que hayamos terminado?". La parte de los datos vendrá después.
Acerca de BDQ
BDQ Cloud es una consultora de TI con sede en Londres, especializada en la migración, consolidación y modernización de plataformas de gestión de servicios. Trabajamos con HaloITSM, Atlassian, Freshworks, Asana y otras herramientas modernas, y colaboramos con Help Desk Migration para la migración técnica de datos que sustenta nuestros proyectos de consolidación. Si desea analizar un desafío de consolidación específico, ofrecemos una evaluación de migración de 30 minutos centrada en el modelo operativo y los resultados, no solo en los datos.
