Muchas guías indican que la migración de un servicio de asistencia técnica tarda entre 4 y 12 semanas. Este plazo describe un proyecto planificado y probado manualmente, con la transferencia programada desde cero. Con una herramienta de migración probada, la mayoría de esas semanas no se producen: la configuración se realiza en minutos con un asistente, una prueba también lleva minutos y la transferencia se ejecuta en segundo plano mientras su equipo sigue trabajando.
El factor determinante son las plataformas. Zendesk permite 200 solicitudes de API por minuto en su plan Team y 2500 en Enterprise Plus (Zendesk Documentación para desarrolladores). Halo limita el uso de la API a 300 llamadas cada cinco minutos (HaloPSA). Desde el 2 de marzo de 2026, Atlassian ha aplicado Jira Cloud (Atlassian Developer). A continuación, encontrará los tiempos típicos por tipo de proyecto, volumen de datos y plataforma, además de los pasos que componen un proyecto de migración.
¿Cuánto tiempo tarda un proyecto de migración de mesa de ayuda, de principio a fin?
La transferencia de datos es solo un paso. La mayor parte del proyecto consiste en la preparación y la verificación, así que planifique todo el cronograma, no solo la ejecución.
Preparación Help Desk Migration : 10 pasos antes de la puesta en marcha
Comience definiendo los objetivos del proyecto y auditando los registros existentes; luego, limpie los datos, configure la plataforma de destino y pruebe la asignación de campos. Cada paso ayuda a prevenir retrasos y problemas con los datos. A continuación, se detallan las etapas clave de la migración y sus plazos habituales.
| Fase | ¿Qué hacer? | Tiempo típico |
|---|---|---|
| 1. Definir el alcance y los objetivos | Acuerden el motivo del cambio, la plataforma de destino y la fecha de lanzamiento | 1-2 días |
| 2. Alinear al equipo | Designa a un responsable del proyecto, informa a los agentes y gerentes, y acuerda un plazo para la transición | 1–3 días |
| 3. Audita tus datos | Enumera lo que tienes: tickets, contactos, empresas, archivos adjuntos, campos personalizados, macros | 2–5 días |
| 4. Decide qué migrar | Marque los datos como "deben moverse", "deben moverse más tarde" o "debéis archivar". Los tickets cerrados más antiguos a menudo se pueden dejar fuera sin problema | 1-2 días |
| 5. Limpiar los datos | Fusionar duplicados, cerrar tickets obsoletos, eliminar correo basura | 2–7 días |
| 6. Prepara el objetivo | Configura campos personalizados, agentes y automatizaciones para que los registros importados tengan un lugar donde almacenarse | 3–10 días |
| 7. Ejecutar una migración de demostración | Realice pruebas con una muestra, verifique la asignación de campos y los archivos adjuntos, y solucione los problemas | 1–3 días |
| 8. Migración completa | Transferencia de todos los registros (de horas a varios días, dependiendo del volumen y los límites de la API) | 1–5 días |
| 9. Transición | Mueva los registros creados desde la ejecución completa y cambie de agente | 1 día |
| 10. Verificar y respaldar | Comparar recuentos de registros, datos de verificación aleatoria y capacitar a los agentes | 1-2 semanas |
En general, la mayoría de los proyectos de migración completos duran de 2 a 6 semanas, y la transferencia de datos suele completarse en menos de una semana. Las fases 3 a 6 pueden superponerse, por lo que comenzar la preparación con anticipación es la mejor manera de acortar el proyecto.
El proceso de migración: plazos estimados de migración según el tamaño y la complejidad del proyecto
La tabla que aparece a continuación resume todas las etapas de un proyecto para tres escenarios comunes. Los tiempos de transferencia provienen de nuestros registros. Las demás etapas corresponden a rangos de planificación basados en la duración de cada paso, que se detalla más adelante en este artículo.
| Guión | Configuración y demostración | Correcciones de pruebas y mapeo | Migración completa (transferencia) | Delta y transición | Total típico |
|---|---|---|---|---|---|
| Configuración pequeña y estándar: menos de 10 000 registros, pocos campos personalizados. | 15–30 min | 1–2 h | ~35 min (9 de cada 10 en ~4,5 h) | 1–2 h | Aproximadamente 1 día |
| Tamaño mediano con campos personalizados: 10 000–100 000 registros, varias repeticiones de demostración. | 1–2 h | 1–3 días | ~4 h (9 de cada 10 en ~1 día) | 2–4 h | 2–5 días |
| Empresa o fusión de varios servicios de asistencia técnica: más de 1 millón de registros, objetos personalizados, objetivo de límite bajo. | 1-2 días de planificación | 3–7 días | ~2 días (9 de cada 10 en ~8,5 días) | mediodía | 2–6 semanas |
En un proyecto grande, la mayor parte del tiempo se dedica a la revisión y la toma de decisiones, no al tiempo de procesamiento. Por eso, los mayores ahorros se consiguen realizando pruebas desde el principio y manteniendo un alcance bien definido. Los consejos para acelerar el proceso que se presentan a continuación abarcan ambos aspectos.
Tiempos típicos de migración de datos según el volumen de datos
La tabla a continuación muestra la duración de la transferencia de datos en las ejecuciones Help Desk Migration observadas, agrupadas por la cantidad de registros transferidos. Las columnas indican el número de ejecuciones, el rango cubierto por la mitad central de las ejecuciones, la mediana y el tiempo en el que finalizaron 9 de cada 10 ejecuciones.
| Volumen de datos (registros) | Corre | Rango típico (50% central) | Mediana | 9 de cada 10 terminan dentro |
|---|---|---|---|---|
| Pequeño: menos de 10.000 | 496 | 15 min – 1,5 h | ~35 min | ~5 h |
| Medio: 10.000 – 100.000 | 572 | 1,5 h – 11 h | ~4 h | ~1 día |
| Grande: 100.000 – 1 millón | 457 | 5 h – 1 día | ~12 h | ~2 días |
| Muy grande: 1M+ | 263 | 21 h – 5 días | ~46 h | ~8,5 días |
Estas son duraciones observadas en migraciones reales, no una fórmula. Cubren las rutas de API a API en cualquier nivel de plan que haya utilizado cada cliente. Las fuentes CSV, databasey de correo electrónico funcionan a velocidades diferentes y están excluidas. Los mismos 30 000 registros pueden transferirse en una hora o tardar casi un día, según las plataformas que se describen en la siguiente sección.
Tiempo de migración por plataforma (límites de la API)
El límite de API de cada plataforma determina la velocidad a la que se pueden leer (exportar) o escribir (importar) registros. La tabla enumera 13 plataformas con sus límites de API documentados en los niveles estándar y superior, además de los tiempos de exportación e importación observados para migraciones de aproximadamente 100 000 registros.
| Plataforma | Límite de API (estándar / nivel superior) | Exportar, ~100.000 registros | Importar, ~100.000 registros | Notas |
|---|---|---|---|---|
| Zendesk | 200 / 2.500 rpm | 7 h | 24 horas | Objetivo común más rápido |
| Freshdesk | 100 / 700 rpm | 6,5 h | 23 h | Rápido en ambos sentidos |
| Freshservice | 100 / 500 rpm | 17 h | 23 h | Lento como fuente; la velocidad de exportación apenas aumenta con el volumen |
| Jira Service Management | basado en puntos (cuota por hora) | 25 h | 25 h | El objetivo común más lento con diferencia: ~1250 registros/hora en cualquier tamaño |
| Intercom | 10.000 rpm por aplicación; mayor velocidad bajo petición | 5 h | 5 h | Rápido en ambos sentidos; los límites se contabilizan en intervalos de 10 segundos |
| HubSpot Service Hub | 600 / 1.140 rpm | 1 h | 6 h | Exportación muy rápida |
| Salesforce Service Cloud | diario: ~100.000 solicitudes/día | 30 h | 70 h | Límite diario; la caída es pronunciada por encima de 1 millón de registros (ver más abajo) |
| Zoho Desk | créditos diarios | 2,5 horas | 13 h | Créditos diarios; amplia cobertura |
| ServiceNow | configurable por el administrador | 2 h | 19 h | Depende de los límites de la instancia |
| Halo | 60 rpm (300 requirido / 5 min) | 4,5 h | 12 h | Límite mínimo documentado en la tabla |
| Pylon | no documentado | n/a (solo objetivo) | 23 h | Confirma el límite con Pylon |
| Front | 50 / 200 rpm | 32 h | 20 h | Los partidos de límite bajo son lentos |
| Gorgias | 120 rpm (40 req / 20 s) | n / A | 19 h | Objetivo lento |
Los límites de la API se verificaron con la documentación para desarrolladores de cada proveedor en noviembre de 2026. Los proveedores cambian estos límites con frecuencia, y la mayoría vende planes superiores o complementos, así que revise su propio plan antes de planificar una migración. Para obtener una cifra exacta para sus propios datos,
Relokia Help Desk Migration completó la migración de Freshservice de Vanta a Jira Service Management en tan solo 21 días, transfiriendo más de 128 000 tickets y conservando el contexto histórico, los archivos adjuntos y la integridad del registro de auditoría. Así es como lo logramos:
Vanta: Más de 128.000 tickets migrados en tan solo 21 días
Relokia Help Desk Migration completó la migración de Freshservice de Vanta a Jira Service Management en tan solo 21 días, transfiriendo más de 128 000 tickets y conservando el contexto histórico, los archivos adjuntos y la integridad del registro de auditoría. Así es como lo logramos:
Desde el lanzamiento del proyecto hasta su finalización exitosa en tan solo 21 días, Vanta migró más de 128 000 tickets, 512 000 comentarios, 86 000 archivos adjuntos y más de 4200 solicitantes y agentes de Freshservice a Jira Service Management, preservando el contexto histórico y la integridad completa del registro de auditoría.
El ajustado plazo se logró mediante opciones de migración automatizadas, configuraciones personalizadas y un enfoque iterativo. Las imágenes se transfirieron como archivos adjuntos a los tickets, mientras que las etiquetas personalizadas basadas en los campos de grupo mantuvieron los registros migrados organizados y fáciles de identificar.
El paquete de soporte Premium incluía la remigración, lo que le daba a Vanta tiempo para aplicar personalizaciones, validar los resultados y completar la transferencia final sin extender el plazo de 21 días del proyecto.
¿Qué factores influyen en la duración de una migración de datos?
Los límites de la API establecen el tope. Otros cuatro factores determinan qué tan cerca se acerca una migración a ese tope y cuánto tiempo lleva el proyecto.
- Número de registros. Cada ticket trae consigo sus comentarios; un ticket puede incluir cientos o miles de comentarios, y cada comentario forma parte de la transferencia. El volumen establece el valor de referencia.
- Archivos adjuntos. Cada archivo se carga por separado, por lo que los archivos adjuntos pueden ser más importantes que la cantidad de tickets. Una cuenta grande con pocos archivos adjuntos puede completarse antes que una cuenta pequeña llena de capturas de pantalla y archivos PDF. Además, es difícil estimar la cantidad de archivos con anticipación, lo que hace que las migraciones con muchos archivos adjuntos sean las más difíciles de predecir.
- Nivel del plan en ambos lados. La mayoría de los proveedores ajustan los límites de la API según el plan: cuanto mayor sea el plan, más llamadas a la API podrá realizar. Por ejemplo, Freshservice pasa de 100 solicitudes por minuto en el plan Starter a 500 en el plan Enterprise, con paquetes adicionales de hasta 2000 (Freshservice documentación de la API).
- Integración de varios servicios de asistencia técnica en uno solo. La consolidación no consiste en una sola migración, sino en varias hacia el mismo destino. Cada origen se ejecuta como una migración independiente, y cada ejecución posterior a la primera se realiza en un destino que ya contiene datos. Nuestros ingenieros técnicos pueden evaluar sus requisitos de migración y determinar si un enfoque de migración en paralelo (multihilo) o secuencial ofrece los resultados más eficientes en cuanto a tiempo. Mayvik migró datos de Freshdesk, Zendesk, Desk.com y Groove a Help Scout de esta manera.
Nuestra guía sobre los desafíos de la migración de datos de atención al cliente enumera todo lo que puede ralentizar un proyecto, junto con sus soluciones.
Cronograma de migración de datos, paso a paso
El tiempo de transferencia es solo una parte de un proyecto de migración. El cronograma que se muestra a continuación abarca todo el proceso y la duración habitual de cada paso.
Paso 1: Mapea tus datos y ejecuta una migración de demostración (15-30 minutos)
Entonces, aquí están las principales opciones que puedes considerar al elegir una forma de transición de datos:
Una demostración gratuita suele durar entre 15 y 30 minutos. En el Asistente de migración, conectas las plataformas de origen y destino (necesitas acceso de administrador a ambas). A continuación, seleccionas los registros que deseas transferir, vinculas agentes y grupos, y asignas los campos de organización, cliente, ticket y artículo. Los pasos exactos de asignación varían según el par de migración. También puedes elegir opciones automatizadas predefinidas para personalizar la importación.
La demostración tarda más si no se ha realizado la configuración previa a la migración. Antes de comenzar, recopile las credenciales de acceso para ambas plataformas, cree perfiles y grupos de agentes coincidentes en la plataforma de destino y configure los campos personalizados de tickets necesarios. Si hay muchos campos personalizados, planifique varias rondas de mapeo en lugar de una sola.
Paso 2: Revise los resultados de la demostración (de minutos a 2 horas)
Revisar una demostración lleva un par de minutos. Probar los resultados de una migración de datos completa lleva al menos 1 o 2 horas. La demostración reproduce la migración completa, por lo que si algo no se migra en la demostración, tampoco se migrará en la migración completa. Ejecute la demostración tantas veces como sea necesario para ajustar la asignación.
Compruebe lo siguiente:
- Los comentarios tienen los autores correctos
- Los boletos se asignan a los agentes correctos
- Los campos personalizados contienen los valores correctos
- Las empresas y los clientes están vinculados
- Los archivos adjuntos llegan con sus nombres
- Los artículos se ubican en las secciones y categorías correctas
- Compartir el acceso a la migración permite que tu equipo ayude a validarla.
Compartir el acceso a la migración permite que tu equipo ayude a validarla.
Paso 3: Prepare a su equipo y el servicio de asistencia técnica objetivo (menos de 2 horas)
Comience a incorporar agentes lo antes posible. El tiempo que lleva depende del número de agentes y de la plataforma de destino. La transición en sí es breve:
- Desactive las automatizaciones en el objetivo o solicite una etiqueta: 5–30 minutos
- El equipo de soporte deja de funcionar en la fuente: 5 minutos
- Desactive los canales de comunicación en la fuente: 5–15 minutos
- Activar los canales de comunicación con el objetivo: de 15 minutos a 1 hora
Paso 4: Ejecutar la migración completa (de horas a días)
Este es el tiempo de transferencia que se muestra en las tablas de volumen y plataforma. Su equipo puede seguir trabajando en el servicio de asistencia de origen mientras se ejecuta. Puede realizar un seguimiento del progreso en la tabla de registros, que muestra los registros recuperados y transferidos, y recibirá un correo electrónico cuando finalice la migración. Si la ejecución debe ajustarse al horario laboral, la Migración por intervalos le permite pausar y reanudar la Migración completa en coordinación con nuestro equipo.
Paso 5: Ejecutar una migración delta para los nuevos registros
Los tickets creados o actualizados en el origen durante la migración completa se pueden transferir posteriormente mediante la migración incremental, disponible en el plan Premium. Valide el resultado antes de cambiar de agente al destino.
8 maneras de acelerar la migración de datos
Para acelerar la migración de un servicio de asistencia técnica, ITSM o RMM, puede tomar diversas medidas para reducir el tiempo de transferencia de datos, simplificar la preparación y evitar retrasos innecesarios. Desde la optimización de los límites de la API y la limpieza de los datos de origen hasta la simplificación de la asignación de campos y el uso de la migración en paralelo, el enfoque adecuado puede hacer que todo el proyecto sea más rápido y predecible. Considere las siguientes maneras de acelerar su migración sin comprometer la precisión de los datos ni la continuidad del negocio.
- Solicite al proveedor un aumento temporal del límite de la API. Intercom acepta solicitudes de límites más altos, Freshdesk vende llamadas adicionales a la API y Zendesk ofrece un complemento de API de alto volumen que aumenta los planes elegibles a 2500 solicitudes por minuto.
- Omitir archivos adjuntos. La opción "Omitir archivos adjuntos" mueve los registros sin
archivos. Excluya los archivos adjuntos de todos los tickets o de los tickets actualizados hace más de 6, 12 o 24 meses. Reduzca el tiempo de migración y los costos de almacenamiento transfiriendo solo los archivos que su equipo necesita. Ideal para migraciones grandes, archivos obsoletos y para evitar exceder el límite de almacenamiento. - Filtra los registros antiguos o irrelevantes. Menos registros significan menos llamadas a la API. No es necesario migrar todo a tu nueva plataforma. Usa las opciones de filtrado del Asistente de migración para seleccionar qué registros transferir y excluir datos irrelevantes, como todos los tickets o los tickets actualizados hace más de seis meses. Si los filtros estándar no cubren tus necesidades, puedes solicitar opciones de filtrado adicionales a nuestro equipo técnico. Ellos te ayudarán a configurar filtros personalizados según el alcance de tu migración, para que transfieras solo los datos que necesitas, reduzcas las llamadas a la API y ahorres tiempo de migración.
- Migración multihilo con Help Desk Migration. Migre en paralelo. La transferencia asíncrona multihilo se ejecuta en paralelo, enviando múltiples solicitudes simultáneamente en lugar de una por una, lo que reduce el tiempo de espera para las respuestas. Se recomienda usar un límite de API más alto, ya que las solicitudes paralelas también se contabilizan. Disponible en los planes Premium y Enterprise.
- Actualiza el nivel del plan durante la migración. Un nivel superior en la plataforma más lenta generalmente aumenta su límite de API durante el tiempo que dure la ejecución.
- Migra primero los registros más recientes. Transfiere primero los tickets más recientes para que tu equipo pueda priorizar los problemas activos de los clientes mientras los registros más antiguos se migran en segundo plano. Esta opción es ideal para periodos de inactividad limitados, soporte ininterrumpido, presupuestos ajustados y para probar los tickets activos antes de la migración. Disponible solo para la migración completa.
- Utilice la migración incremental para la transición. Transfiera los tickets creados o actualizados en el origen después de la migración completa, lo que garantiza que su nueva plataforma cuente con los datos más recientes antes de su puesta en marcha. Esto minimiza el tiempo de inactividad y evita la pérdida de datos. Disponible en el plan Premium.
- Utilice la migración por intervalos para adaptarla al horario laboral. Pause la migración completa durante las horas pico y reanúdela después. Puede pausarla hasta cinco veces, durante un máximo de cinco días cada vez, en coordinación con nuestro equipo.
Para migraciones complejas, nuestros Servicios de Migración Gestionada proporcionan asistencia experta en planificación, personalizaciones, mapeo de datos, límites de API y validación para garantizar una transición fluida con mínimas interrupciones.
Pandora: Migración empresarial completada en tan solo 4 semanas
En tan solo 4 semanas, sin interrupciones, Pandora completó una migración a nivel empresarial de Zendesk a Salesforce Service Cloud, consolidando los datos de atención al cliente en más de 6500 puntos de venta y 37 000 empleados en todo el mundo.
La migración transfirió el historial completo de tickets y clientes, las grabaciones de llamadas, los archivos adjuntos, las notas internas, las conversaciones paralelas y los flujos de trabajo empresariales, preservando al mismo tiempo las relaciones entre los datos.
Para mantener el proyecto dentro del plazo previsto, el equipo empleó un enfoque iterativo con cinco migraciones de demostración para validar la asignación de campos y las configuraciones antes de la transferencia final. Los activadores del backend Salesforce se deshabilitaron temporalmente para evitar bloqueos del sistema y garantizar una transición sin problemas.
Migración manual, automatizada o gestionada: comparación de plazos
Un script desarrollado en equipo, una herramienta de migración de autoservicio y un servicio de migración gestionado se diferencian principalmente en el tiempo que se invierte antes y después de la transferencia, no durante la misma.
| Criterio | Manual (script personalizado) | Herramienta automatizada (de autoservicio) Help Desk Migration | Servicio de migración gestionado por el equipo de soporte técnico y de asistencia Help Desk Migration |
|---|---|---|---|
| Tiempo de configuración | De semanas a meses estudiando ambas API | Minutos para conectar y mapear en un asistente | Nuestro equipo define el alcance del proyecto y mapea los datos con usted |
| Pruebas | Construido y replicado por tu equipo | Migración de demostración en un ejemplo, vuelva a ejecutarlo según sea necesario | Se realizarán demostraciones y se elaborará un plan de validación para el proyecto |
| Gestión de los límites de la API | Tu código tiene que limitar y volver a intentarlo | Integrado en la herramienta | Integrado, además de las solicitudes de límite de proveedores planificadas con antelación |
| Campos personalizados, filtros, combinaciones | Lo que sea que construya tu equipo | Mapeo estándar y opciones automatizadas, filtrado. Solicite filtros personalizados o personalizaciones adicionales para la migración a nuestro equipo técnico para adaptar el proceso a sus datos y necesidades del proyecto. | Filtrado personalizado, mapeo personalizado, consolidación de múltiples fuentes |
| Duración típica del proyecto | Semanas a meses | De horas a unos pocos días | De días a algunas semanas, dependiendo del alcance |
| Costo | Tiempo de ingeniería, a menudo oculto | Precio según volumen de grabación y opciones, paquete de soporte (precios) | Cotizado por volumen de registros, opciones, paquete de soporte (servicios de migración) |
Un servicio gestionado no tiene por qué implicar código personalizado para cada proyecto. El equipo de Help Desk Migrationutiliza el mismo motor probado que la herramienta de autoservicio, por lo que la velocidad de la transferencia se mantiene, pero la planificación, la asignación de tareas y la validación dejan de ser responsabilidad de su equipo.
para ver cómo se comportan sus propios registros en su ruta, o hable con un experto sobre un proyecto empresarial o de múltiples fuentes.
Preguntas frecuentes
En nuestros registros, las migraciones de más de un millón de registros tardaron una media de unas 46 horas. La mitad de las ejecuciones se completaron en un plazo de 21 horas a 5 días, y 9 de cada 10 en unos 8,5 días. Un objetivo con un límite bajo, como Jira Service Management tardaría aproximadamente un mes, mientras que uno con un límite diario, como Salesforce Service Cloud, extiende la ejecución al extremo superior de ese rango. Si añadimos entre unos días y una semana de mapeo y pruebas en torno a la transferencia, un proyecto de un millón de tickets suele completarse en una o tres semanas, no en tres meses.
Estos plazos suelen describir el proyecto completo con un enfoque manual o personalizado: semanas de planificación, una migración de prueba automatizada, la transferencia y semanas de control de calidad. Con una herramienta de migración probada, el mapeo y las pruebas se realizan en cuestión de minutos o días, y la transferencia en sí lleva horas en la mayoría de los casos. Los proyectos muy grandes o con múltiples fuentes de datos siguen requiriendo una planificación minuciosa, pero un cronograma que se mide en meses generalmente implica mucho trabajo manual.
Sí. Cada archivo adjunto se carga por separado, por lo que una cuenta con muchos archivos puede tardar más que una cuenta más grande con pocos. Los artículos de la base de conocimientos suelen ser pocos en comparación con los tickets, pero las imágenes integradas y la estructura de los artículos (secciones y categorías) aumentan el tiempo de mapeo y verificación. Si los archivos adjuntos ralentizan la transferencia, la opción "Omitir archivos adjuntos" mueve los registros sin archivos.
Para los datos de la mesa de ayuda en Salesforce Service Cloud (casos, contactos y artículos de la base de conocimientos), ZendeskaSalesforce en nuestros registros tardaron una media de 6 horas para entre 10 000 y 100 000 registros, y unas 12 horas para entre 100 000 y 1 millón. Por encima de 1 millón de registros, Salesforceempieza a ralentizar el proceso: ZendeskaSalesforce de ese tamaño tardaron una media de 3,4 días. Estas cifras no incluyen una migración completa de Sales Cloud CRM. Consulte nuestra Salesforce Service Cloud de migración a para ver los registros compatibles.
La migración en paralelo se ejecuta en varios hilos, enviando múltiples solicitudes a la vez para reducir el tiempo de espera de las respuestas. Resulta especialmente útil en cuentas grandes con muchos tipos de registros, y menos si ya se ha alcanzado el límite de la API del proveedor; en ese caso, conviene aumentar dicho límite primero. Los registros relacionados, como los tickets y sus solicitantes, se siguen creando en el orden correcto, y una migración de demostración permite comprobar el resultado antes de la ejecución completa.
Sí. Los agentes siguen trabajando en el servicio de asistencia de origen mientras se ejecuta la migración completa, ya que la transferencia lee los datos a través de la API sin bloquear la cuenta. Desactive primero las automatizaciones en el destino para que los tickets importados no generen correos electrónicos a los clientes. La guía de migración sin interrupciones describe la secuencia de transición.
Los tickets creados o actualizados en el origen después de que comience la migración completa no forman parte de esa ejecución. Una migración incremental los transfiere en una fase posterior mucho más corta, para que los agentes puedan pasar al destino con el historial completo. La migración incremental está disponible en el plan Premium. La lista de verificación general de migración de datos muestra dónde encaja la migración incremental en la transición.
Sí, con la Migración por Intervalos. Puede pausar la Migración Completa hasta cinco veces, durante un máximo de cinco días cada vez, y reanudarla en coordinación con el Help Desk Migration . Por ejemplo, puede mantener las horas pico de soporte libres de carga de API. La Migración por Intervalos no es lo mismo que la Migración Delta, que mueve los registros creados después de la ejecución principal. Los pasos para pausar y reanudar se encuentran en la sección de ayuda "Primeros pasos".
Durante una migración de demostración, el asistente de migración muestra una barra de progreso con el porcentaje de datos de muestra transferidos. Durante la migración completa de datos, una tabla muestra cuántos registros se recuperaron y transfirieron. Recibirá un correo electrónico cuando finalice la migración de demostración o la migración completa.
Compara el destino con el origen: recuentos de registros por tipo, autores de comentarios, responsables de tickets, valores de campos personalizados, archivos adjuntos y categorías de artículos. Revisa una muestra de tickets antiguos, recientes y con muchos archivos adjuntos, y luego activa los disparadores, las automatizaciones y las notificaciones en el destino. Recopila comentarios de los agentes durante sus primeros días en el nuevo servicio de asistencia. La lista de verificación posterior a la migración detalla cada comprobación.
Primero, revisa la tabla de la plataforma: una ejecución lenta hacia un destino con límites bajos, como Jira Service Management, Haloo Front suele ser normal. Si el contador de registros en la tabla de progreso no ha variado en varias horas, es posible que un límite diario de la API o un token caducado hayan pausado la ejecución. En ese caso, ponte en contacto con nuestro equipo de soporte con tu ID de migración para que puedan revisar los registros.
