Migración de datos para empresas de servicios de TI: del recuento de incidencias al alcance total
Empecemos por algo en lo que la mayoría de los equipos no piensan hasta que es demasiado tarde: su mesa de ayuda no es una herramienta. Es la información de cada relación con sus clientes. Por lo tanto, cuando decida cambiar de plataforma ITSM, todo ese historial debe acompañarlo.
Help Desk Migration traslada a los agentes y mapea de forma precisa el historial de tickets, contactos y empresa, proporcionándole una integridad total de los datos ITSM.
Sin tarjeta de crédito Montaje rápido
Con la confianza de más de 60.000 empresas
Alcance de la migración de datos: Siete conjuntos de registros, un proyecto
Antes de planificar la migración de datos, haga un inventario de todos los tipos de registros dentro de su plataforma de soporte. Revise sus datos actuales para decidir qué migrar y luego compare sus sistemas de origen y destino para crear un plan preciso de asignación de campos con anticipación.
| Récord establecido | Lo que incluye | Qué observar en una película |
|---|---|---|
| Datos de la mesa de ayuda y del servicio de asistencia | Casos, tickets, conversaciones, estados, etiquetas, campos personalizados | Esto determina el volumen de todo el proyecto. Primero, define su alcance. |
| Registros ITSM | Incidentes, solicitudes de servicio, registros de cambios, registros de problemas, políticas de SLA, cadenas de aprobación, elementos de configuración | Tres de estos siete tipos normalmente necesitan una reasignación o una reconstrucción, no una transferencia directa |
| Base de conocimientos | Artículos, categorías, carpetas, visibilidad interna frente a pública, archivos adjuntos de artículos | La configuración de visibilidad no siempre se corresponde con una equivalente en la plataforma de destino |
| Datos del cliente y de contacto | Empresas, contactos, sitios, jerarquía organizativa, estructura de agentes y grupos | La estructura de los grupos a menudo necesita ser reajustada cuando la plataforma de destino modela los equipos de manera diferente |
| Archivos multimedia y adjuntos | Imágenes en línea, archivos adjuntos | El volumen de archivos adjuntos puede extender su ventana de migración más que el número de tickets |
| Historial de correo electrónico | Hilos de entrada y salida vinculados a tickets, preservación de encabezados | La conservación de los encabezados depende de lo que la plataforma de origen almacena realmente, no solo de lo que muestra |
| Registros y grabaciones de llamadas | Registros telefónicos y enlaces de grabación adjuntos a los billetes | Normalmente se trata de un enlace a un sistema de telefonía, no de una grabación almacenada. Se migra la referencia, no el audio. |
Nota al pie: la cobertura por conjunto de registros depende de lo que expone la plataforma de origen y de los modelos de destino.
¿Entraste aquí pensando solo en tickets? A todos nos pasa. Una vez que ves la lista completa, el alcance de los registros ITSM se vuelve mucho más claro, rápidamente. Tomemos un proyecto típico: una migración a Ivantio a ServiceNow.
¿Quieres conocer más detalles sobre una plataforma específica? Consulta las páginas Jira Service Management de migración Freshservice de o para ver cómo se comporta un conjunto de registros individual dentro de esa plataforma.
La de migración de la base de conocimientos cubre la estructura y la visibilidad de los artículos por sí sola. ¿Sigues buscando plataformas antes de siquiera acercarte a la migración? Empieza con la guía de software de mesa de ayuda para empresas de TI.
Un punto importante a destacar:la migración de datosabarca dos proyectos que esta página no trata. Database y aplicaciones traslada los sistemas de su negocio, no el servicio de asistencia técnica. La migración de dispositivos o cuentas de usuario traslada dispositivos y cuentas de usuario, no casos ni incidencias. Ambas son reales. Ninguna requiere la guía que se presenta a continuación.
Integraciones de migración de ITSM compatibles
Accelo
Atera
Atlas
Autotask PSA
BMCHelixITSM
BoldDesk
Chatwoot
ConnectWise
Crisp
CSV
Custify
Deskpro
DevRev
Dixa
Document360
Drift
Dynamics 365
eDesk
eGain
Enchant
Forumbee
FreeScout
Freshchat
Freshdesk
Freshservice
Front
FyneDesk
Gladly
Glassix
Gleap
GLPI
Gmail
Google Docs
Gorgias
Groove
Halo Service Solutions
HappyFox
Harmony
HelpCrunch
HelpDesk
HelpDocs
Helpjuice
Help Scout
HelpShift
HelpSpot
HubSpot Service Hub
InstantDocs
Intercom
Ivanti
Jira Service Management
Jitbit HelpDesk
Kayako
Kayako Classic
KnowledgeOwl
Kundo
Kustomer
Lansweeper
Live Agent
LiveChat
Manage Engine
Mayday
Missive
NinjaOne
Odoo Helpdesk
Oracle Service Cloud (RightNow)
osTicket
((OTRS)) Community Edition
Outlook
Paligo
Plain
Planhat
Pylon
Reamaze
Request Tracker
Respond.io
Richpanel
Salesforce Service Cloud
ServiceDesk Plus
ServiceNow
SherpaDesk
Siit
SmarterTrack
SolarWinds Service Desk
SolarWinds Web Help Desk
SparrowDesk
Spiceworks
Spiceworks Cloud
SQLite
SuperOps
SupportBee
SupportPal
Syncro
SysAid
SysAid (Cloud)
Tawk.to
TeamSupport
TeamworkDesk
Thena
Thulium
Tidio
TOPdesk
Trengo
Unthread
Vitally
Vivantio
Zammad
Zendesk
Znuny
Zoho Desk
Zoho Mail
Revisa el nombre para ver si tiene errores tipográficos o déjanos un mensaje.
Los tipos de discos que se mueven con facilidad y los tres que rara vez lo hacen
No todos los tipos de registros migran de la misma manera. Los registros ITSM principales, como los tickets y los archivos adjuntos, se transfieren con una fidelidad casi perfecta, pero la lógica operativa —en concreto, los SLA, las cadenas de aprobación y las relaciones de elementos de configuración (CI)— no se puede simplemente trasladar. Los planes de migración exitosos deben tener en cuenta la reasignación y reconstrucción personalizadas necesarias para estos tres tipos de activos que dependen de la plataforma.
| Tipo de registro | Patrón típico | Condición |
|---|---|---|
| Incidentes | Se mueve directamente | La estructura básica de los tickets suele corresponderse uno a uno entre plataformas |
| Solicitudes de servicio | Se mueve directamente | Mismo patrón estructural que los incidentes en la mayoría de los esquemas objetivo |
| Registros de cambios | Se mueve directamente | Estructuralmente similar a los tickets en la mayoría de las plataformas ITSM |
| Registros de problemas | Se mueve directamente | Estructuralmente similar a los tickets en la mayoría de las plataformas ITSM |
| Campos personalizados | Se mueve directamente, condicionado a la coincidencia de esquema | La fidelidad depende de que el esquema de destino tenga un campo equivalente |
| Archivos adjuntos | Se mueve directamente | Transferencia a nivel de archivo, generalmente sin modificaciones |
| Políticas de SLA | Necesita ser remapeado | Reconstruya manualmente sus objetivos de SLA (como los límites de tiempo de primera respuesta y resolución) en el sistema de destino antes de la transferencia principal de datos. También puede conservar las métricas históricas de SLA como datos estáticos de solo lectura en tickets individuales mediante la personalización. |
| Cadenas de aprobación | Generalmente se reconstruye en el objetivo | La plataforma calcula la lógica de aprobación y el estado por sí misma, en lugar de almacenarlos como un registro portátil |
| Elementos de configuración | Necesita ser remapeado | Las relaciones de CI dependen de cómo el CMDB de destino modela los activos y las dependencias |
¿Por qué solo tres tipos de registros causan problemas? Porque las políticas de SLA y las cadenas de aprobación nunca fueron "datos" en primer lugar. Son lógica. La plataforma de destino recalcula los plazos de SLA y los estados de aprobación mediante sus propias reglas de escalamiento y su propio motor de flujo de trabajo. No se puede simplemente copiar un número de una plataforma y aplicarlo a otra esperando que siga significando lo mismo. Los elementos de configuración se topan con un obstáculo similar desde otro ángulo: las relaciones de CI dependen de cómo la CMDB de destino estructura los activos y las dependencias, y esa estructura rara vez coincide con la de la plataforma de origen, campo por campo.
Los incidentes, las solicitudes de servicio, los registros de cambios y los registros de problemas no presentan este problema. Suelen ser registros planos: un estado, una descripción, algunos campos personalizados y algunos archivos adjuntos. Basta con conservar la estructura y reasignar los campos donde el esquema no coincide, y así se integran sin mayores complicaciones.
Historia de un cliente
e-Core migró a un cliente de Zendesk a Jira Service Management
Migración de Zendesk a Jira Service Management
Boletos, contactos, agentes, empresas, archivos adjuntos, notas: todo se transfirió correctamente. Pero entonces surgió un problema. La asignación de organización de cada boleto se desorganizaba constantemente tras la migración, y tuvieron que crear una solución personalizada para mantenerla en su lugar.
Así que dividieron el trabajo en dos fases: primero los tickets cerrados, luego el resto. Este es el patrón que se repite en todas las migraciones de ITSM. La mayor parte de la estructura de un servicio de asistencia técnica sobrevive al proceso intacta. Las excepciones son las que merecen una planificación previa a la transición, no una solución improvisada posterior.
Las pruebas detectan estas tres excepciones cuando aún son fáciles y económicas de corregir. Audita tus tipos de registro con esta matriz antes de definir el alcance del proyecto, no después.
Cómo se lleva a cabo realmente la migración de datos para las empresas de servicios de TI
La migración de su mesa de ayuda de TI con Help Desk Migration sigue cinco pasos claros en el asistente de migración de autoservicio.
Conecta tus plataformas
Conecte sus plataformas de origen y destino dentro del Asistente de migración. Ingrese las credenciales de acceso para ambas herramientas ITSM y Help Desk Migration autenticará cada conexión. No se requiere instalación ni scripts. El asistente lee ambos esquemas y muestra todos los tipos de registros disponibles para la transferencia.
Seleccione sus datos
Seleccione los conjuntos de registros que desea migrar: incidentes, agentes, tickets, tareas y artículos de la base de conocimientos. Puede migrar todo o limitar la transferencia a un subconjunto específico: el asistente transferirá únicamente lo que seleccione. Aquí es donde define los límites del proyecto antes de que se transfiera un solo registro desde el origen.
Mapea tus campos
Asigne sus campos a través de esquemas que no coincidan. Alinee los estados de los tickets, las prioridades, los tipos de solicitud, los agentes y los campos personalizados entre el origen y el destino para evitar confusiones. El asistente sugiere asignaciones predeterminadas automáticamente, y usted puede ajustar cualquier elemento que requiera un manejo personalizado. Este paso protege la integridad referencial cuando se transfieren grandes volúmenes de registros.
Ejecutar una migración de demostración
Antes de tomar una decisión definitiva, realice una migración de demostración gratuita. El asistente transferirá un pequeño lote de registros para que pueda verificar la asignación de campos, los archivos adjuntos y las relaciones en la plataforma de destino. Revise los resultados, descargue los informes y confirme que todo se haya asignado correctamente. Realice los ajustes necesarios y vuelva a ejecutar la demostración tantas veces como lo requiera.
Iniciar la migración completa
Inicie la migración completa una vez que la demostración le parezca correcta. Help Desk Migration transfiere todos los registros seleccionados a la plataforma de destino sin interrupciones, para que su equipo pueda seguir trabajando. Posteriormente, ejecute una migración incremental para transferir los tickets creados durante la transferencia y complete la transición sin dejar ningún registro pendiente.
¿Cuánto cuesta la migración y cuánto dura?
Tanto el coste como el plazo de entrega dependen de las mismas cuatro variables:
Volumen récord
¿Cuántos tickets, incidentes y registros relacionados vas a trasladar?
Profundidad de campo personalizada
¿Cuánto trabajo de cartografía necesita cada campo?
Número de instancias de origen
Un escritorio que se consolida en uno, o varios que se consolidan en uno
Disponibilidad de API
Ya sea que su plataforma de origen exponga una, o que necesite una ruta de campo personalizada como la que proporcionó Hexagon Software Group
En el plan Estándar de Help Desk Migration, una migración básica sin personalización predefinida cuesta $100 por 1000 registros, pero 10 000 registros en las mismas condiciones cuestan $514, ni mucho menos diez veces el precio. Cuanto mayor sea la migración, menor será el costo por registro, y la profundidad de los campos personalizados influye más en este precio que el volumen.
Casos de éxito en la migración de datos ITSM
Un cambio de ITSM entre ecosistemas
e-Core, una empresa de consultoría y externalización de aplicaciones de Atlassian con sede en Porto Alegre, Brasil, necesitaba migrar a uno de sus clientes de Zendesk a Jira Service Desk. La database del cliente era extensa y deseaban conservarla por completo, en lugar de empezar de cero. Help Desk Migration dividió la transferencia en dos fases: primero los tickets cerrados y luego el resto, e implementó una solución personalizada para que cada ticket conservara la asignación correcta de la organización tras su llegada. Todo lo demás se transfirió correctamente: tickets, contactos, agentes, empresas, archivos adjuntos y notas. e-Core realizó varias migraciones de prueba antes de comprometerse con la transferencia completa, que es precisamente el paso de validación al que se hace referencia en esta página. Su responsable técnico confirmó que los datos necesarios llegaron intactos a Jira Service Desk.
La historia de la migración de e-Core
Ventana corta, consolidación Zendesk , instancia de un socio como fuente
Lenovo Private Cloud Solution necesitaba transferir rápidamente un volumen considerable de tickets desde la instancia de Zendesk de un socio a la suya propia para una división ubicada en Bucarest, Rumania. En lugar de una gestión integral, el equipo optó por el autoservicio con el Asistente de Migración y transfirió el volumen de tickets entre instancias en poco tiempo. Sin embargo, la velocidad no lo era todo. Lenovo necesitaba conservar los datos históricos para futuras consultas, y el gerente de operaciones destacó posteriormente el seguimiento realizado por el equipo de cuentas durante todo el proceso.
La historia de la migración de la solución Lenovo Private Cloud Solution
Una fuente heredada sin API
Hexagon Software Group, desarrollador británico de software especializado en gestión inmobiliaria y financiera, necesitaba migrar de ReadyDesk a Freshdesk sin conexión API en el lado de origen. Help Desk Migration diseñó una ruta de migración personalizada que abarcaba tanto los datos del servicio de asistencia como la base de conocimientos. Preservar el historial de llamadas era fundamental. Los ingresos de Hexagon dependen en gran medida de los servicios profesionales, no solo de las licencias de software, y el consultor sénior del cliente señaló posteriormente que el historial migrado proporcionaba al equipo un registro consultable que podían recuperar bajo demanda, en lugar de empezar desde cero.
La historia de migración de Hexagon Software GroupAquí se presentan tres variantes del problema: una migración entre plataformas de diferentes ecosistemas, una limitación en el volumen de registros y los plazos, y una fuente heredada sin API. En conjunto, estas tres variantes abarcan gran parte de lo que probablemente implicará su propia migración. Ya sea que la llame migración de datos para proveedores de servicios de TI o migración de ITSM, el objetivo es el mismo: trasladar los registros, no solo el ticket.
Antes de definir el alcance del proyecto: mapee sus propios tipos de registros
Aquí está la clave: la matriz anterior es el patrón de Help Desk Migration, creado a partir de proyectos reales, no una suposición. Pero aún no es tu patrón. Adóptalo. Integra tu propia plataforma. Llega a la reunión de definición del alcance sabiendo ya dónde encontrarás dificultades, en lugar de descubrirlo tres semanas después, cuando solucionarlo sea costoso.
| Tipo de registro | Patrón general | ¿Confirmado para su par de plataformas? | ¿Necesita reconfiguración? | Dueño |
|---|---|---|---|---|
| Incidentes | Se mueve directamente | Sí (compatible con API) | Mapeo de estado y prioridad estándar | Responsable de la mesa de ayuda |
| Solicitudes de servicio | Se mueve directamente | Sí (compatible con API) | Solicitar la asignación de elementos del catálogo | Responsable de la mesa de ayuda |
| Registros de cambios | Se mueve directamente | Sí (coincidencia de esquema) | Mapeo de campos de riesgo, tipo y motivo | Gestor de cambios |
| Registros de problemas | Se mueve directamente | Sí (coincidencia de esquema) | Causa raíz y relaciones con incidentes relacionados | Gestor de problemas |
| Campos personalizados | Se mueve directamente, condicionado a la coincidencia de esquema | Se requiere auditoría | Cree campos personalizados coincidentes en el destino | Administrador de ITSM |
| Archivos adjuntos | Se mueve directamente | Sí (Transferencia directa de archivos) | No (Conservar archivos adjuntos en línea y de archivo) | Responsable de migración |
| Políticas de SLA | Necesita ser remapeado | Reconstruir en el objetivo | Recrear objetivos; métricas históricas a través de campos personalizados | Gerente de prestación de servicios |
| Cadenas de aprobación | Generalmente se reconstruye en el objetivo | Reconstruir en el objetivo | Configurar el motor de flujo de trabajo en el sistema de destino | Responsable del proceso ITSM |
| Elementos de configuración | Necesita ser remapeado | Depende del modelo | Alinear los modelos de activos y la jerarquía de dependencias de CI | Administrador de activos/CMDB |
Rellena este formulario. Tráelo a tu demostración gratuita de migración. Esa es la diferencia entre presentarte sin un plan y presentarte con un plan, y es la forma de minimizar los riesgos en la conversación sobre el alcance antes de que comience.
Preguntas frecuentes: Migración de datos para empresas de servicios de TI
La migración de ITSM implica trasladar los registros de una plataforma de gestión de servicios de TI (incidentes, solicitudes de servicio, registros de cambios, registros de problemas, políticas de SLA, cadenas de aprobación y elementos de configuración) de una plataforma a otra. Se diferencia de una migración de mesa de ayuda convencional porque la plataforma calcula varios de estos tipos de registros sobre la marcha en lugar de almacenarlos, por lo que normalmente se reasignan en lugar de transferirlos directamente. Esto ocurre siempre que se migra a ServiceNow o a una herramienta ITSM de la competencia.
La mayoría de las fuentes coinciden en cuatro: migración de almacenamiento, database , migración de aplicaciones y migración a la nube. La migración de almacenamiento transfiere datos entre sistemas de almacenamiento físicos o virtuales. Database los transfiere entre database . La migración de aplicaciones los transfiere como parte del reemplazo de un sistema de software por otro. La migración a la nube los transfiere a la infraestructura en la nube. Ninguna de estas cuatro se centra en el servicio de asistencia técnica. Consulte Help Desk Migrationel proceso de para la versión específica para el servicio de asistencia técnica.
Depende del volumen de registros, la complejidad de los campos personalizados, la cantidad de instancias de origen que se consolidan y si la plataforma de origen ofrece una API. La clave está en que un volumen pequeño de tickets con lógica compleja en los campos personalizados puede costar más que uno grande y sencillo, ya que el trabajo de mapeo influye más en el precio que la cantidad de tickets. Consulte de precios .
Depende de la plataforma de origen, la plataforma de destino y la cantidad de tareas que requieren gestión y las que pueden realizarse de forma autónoma. Para migraciones de mesas de ayuda y ITSM, Help Desk Migration transfiere datos de proyectos propios a más de 100 plataformas compatibles, lo que la diferencia de una herramienta ETL de propósito general diseñada para databaseo aplicaciones. Compare los modos de entrega en la Help Desk Migration de servicios de .
Por lo general, implica trasladar incidentes, solicitudes, registros de cambios y elementos de configuración a ServiceNow desde otra plataforma, o desde ServiceNow a una diferente. ServiceNow calcula internamente el estado de los SLA y las aprobaciones, por lo que la migración suele implicar la reasignación de estos tipos de registros en lugar de su transferencia tal cual. Consulte la ServiceNow página de migración para obtener información específica de la plataforma.
Según el marco ITIL: estrategia de servicio, diseño de servicio, transición de servicio, operación de servicio y mejora continua del servicio. Una migración de plataforma generalmente se incluye dentro de la transición de servicio, ya que modifica la forma en que se prestan los servicios existentes sin necesariamente cambiar la estrategia subyacente. Las funciones de asistencia de IA en la plataforma de destino también influyen cada vez más en esta etapa. Consulte la sección "IA en ITSM" para comprender las implicaciones para su historial migrado.
Ningún proveedor es la mejor opción para todas las empresas de servicios de TI. La clave está en el volumen de datos, la plataforma y la disponibilidad de la API en su sistema de origen. Help Desk Migration ha gestionado proyectos de migración de datos de servicios de TI de diversos tamaños, con más de 60 000 migraciones completadas a lo largo de su trayectoria. Compare Help Desk Migrationlos clientes de con los de su sector y plataforma antes de tomar una decisión.
Depende de las plataformas ITSM específicas involucradas y de los tipos de registros incluidos. Help Desk Migration funciona con ServiceNow, Jira Service Management, Freshservice, Zendesk, SysAid, Ivantiy ManageEngine ServiceDeskeDesk , entre otras. revise los casos de éxito publicados sobre migraciones específicas de ITSM similares a su par de plataformas.
A menudo se les llama las 7 R. Provienen de la migración de infraestructura en la nube: rehost, replatform, repurchase, refactor, retire, retain y relocate. Describen cómo se migran las aplicaciones y las cargas de trabajo a la nube, no cómo se transfieren los registros de la mesa de ayuda entre plataformas. Una migración de mesa de ayuda es un proyecto independiente, con sus propios tipos de registros y su propia secuencia. Consulte cómo Help Desk Migration gestiona esto.
La gestión de servicios de TI (ITSM) abarca las prácticas que se utilizan para diseñar, entregar y dar soporte a los servicios de TI: gestión de incidentes, gestión de cambios, atención de solicitudes y más. Se ejecuta en una plataforma dedicada, como Jira Service Management, donde estos procesos se almacenan como registros estructurados. Consulte sobre migración a Jira Service Management para obtener información sobre cómo se transfiere este conjunto de registros entre plataformas.
¿Listo para migrar su mesa de ayuda ITSM?
Realice una migración de demostración gratuita para probar sus datos reales en la plataforma de destino. Sin entorno de prueba ni datos ficticios. Sus registros reales, en el lugar correcto, listos para su inspección.
Solicitar una consulta de migración
Sin tarjeta de crédito Certificado SOC 2 Más de 40.000 migraciones completadas