Imagínese esto: Es viernes por la tarde. Su organización se está preparando para una migración a gran escala de la plataforma de soporte durante el fin de semana. Para el lunes por la mañana, sus equipos necesitan acceso a años de historial de tickets, datos de clientes y flujos de trabajo, sin interrupciones ni pérdida de contexto.
En situaciones como esta, la prioridad de la migración se vuelve crucial. No todos los registros deben migrarse en el mismo orden, y tratar todos los datos por igual puede ralentizar la transición. Los equipos de soporte suelen necesitar acceso inmediato a los tickets activos, las conversaciones recientes, los clientes prioritarios o grupos específicos, mientras que los datos históricos pueden seguir migrando en segundo plano. Sin una estrategia de migración y una priorización claras, los equipos pueden encontrarse con datos incompletos, notificaciones duplicadas o una presión operativa innecesaria durante la puesta en marcha.
La migración exprés de la mesa de ayuda adopta un enfoque más inteligente: la lógica de dos fases. Primero, ponemos a su equipo en funcionamiento y, a continuación, migramos sus datos históricos discretamente en segundo plano. No se trata de dejar datos atrás, sino de migrarlos en el orden correcto.
1. ¿Qué diferencia a la migración Express de una migración estándar?
Una migración estándar intenta trasladar todo en una sola operación compleja: tickets abiertos, registros cerrados, archivos adjuntos de gran tamaño y registros del sistema. Para conjuntos de datos grandes, esta única ejecución puede extenderse fácilmente más allá del tiempo habitual de una noche.
Esto crea un período de incertidumbre de varios días. Los agentes se ven obligados a manejar dos sistemas a la vez; nadie sabe qué plataforma contiene la información fidedigna, y los errores de datos se acumulan con el paso de las horas.
Una migración exprés del servicio de asistencia técnica elimina este problema. Al establecer una clara distinción entre dos fases de migración, este modelo de migración sin interrupciones mantiene las colas de soporte en movimiento. Sin interrupciones prolongadas. Ningún agente se queda sin atención.
1. ¿Qué diferencia a la migración Express de una migración estándar?
Una migración estándar intenta trasladar todo en una sola operación compleja: tickets abiertos, registros cerrados, archivos adjuntos de gran tamaño y registros del sistema. Para conjuntos de datos grandes, esta única ejecución puede extenderse fácilmente más allá del tiempo habitual de una noche.
Esto crea un período de incertidumbre de varios días. Los agentes se ven obligados a manejar dos sistemas a la vez; nadie sabe qué plataforma contiene la información fidedigna, y los errores de datos se acumulan con el paso de las horas.
Una migración exprés del servicio de asistencia técnica elimina este problema. Al establecer una clara distinción entre dos fases de migración, este de migración sin interrupciones mantiene las colas de soporte en movimiento. Sin interrupciones prolongadas. Ningún agente se queda sin atención.
- Paso 1: Transferencia limpia del conjunto mínimo de datos que tu equipo necesita para brindar soporte a los clientes desde el primer día. Esto incluye tickets abiertos, tickets pendientes, contactos, empresas y tu base de conocimientos activa. Dado que este conjunto de datos representa solo una fracción de tu archivo total, se completa fácilmente durante la noche.
- Paso 2: El archivo histórico. Todo lo demás, es decir, el archivo de tickets cerrados, se transfiere en partes manejables y calculadas una vez que su equipo ya esté trabajando en la nueva plataforma. Sin prisas, sin estrés los fines de semana y sin interrupciones en su soporte diario.
Tu equipo completa una transición limpia a la plataforma justo a tiempo. El historial completo se ejecuta de forma segura en segundo plano.
1.1plainde la lógica de dos recorridos
Piensa en el Paso 1 como una clase magistral sobre "carga diferida". En lugar de hacer que el usuario espere a que se carguen todos los elementos pesados del pie de página, los scripts de seguimiento y las imágenes de fondo, renderizas el contenido esencial que se ve sin necesidad de desplazarse para que pueda empezar a interactuar con la página inmediatamente.
El lunes por la mañana, tus agentes solo necesitan la información esencial que aparece en la parte superior de la página: conversaciones activas, perfiles de clientes actualizados y documentación técnica para resolver incidencias. No necesitan una incidencia resuelta hace tres veranos para cumplir con sus acuerdos de nivel de servicio (SLA) iniciales.
El paso 2 es la carga asíncrona en segundo plano. Esta carga el resto del archivo histórico según sus necesidades, mucho después de que la transición crítica haya finalizado. Ambos pasos comparten el mismo objetivo: una transferencia completa de datos. Este enfoque de migración por fases garantiza que su equipo mantenga el control total del cronograma operativo.
1.2 Lo que NO es Express Migration
Seamos claros: la migración exprés no implica tomar atajos ni eliminar permanentemente sus archivos. Cada ticket cerrado, resolución anterior y archivo histórico se transfiere de forma segura durante el paso 2. Todo su historial llega intacto. Estamos modificando estratégicamente los plazos de entrega.
La principal preocupación de los responsables de TI es que los datos históricos se pierdan. Pero no es así. El paso 2 es una fase fundamental de ingeniería, no una opción secundaria. Para los equipos sujetos a estrictos marcos de cumplimiento, auditorías regulatorias o modelos de éxito del cliente donde los agentes consultan constantemente interacciones anteriores, completar el paso 2 es una parte indispensable de nuestro proceso. La migración exprés es una estrategia de secuenciación, no una eliminación selectiva.
2. Lista de verificación previa a la migración: Todo lo que debe configurarse antes de transferir los datos
Todas las tareas de esta sección deben finalizarse antes de que comience la migración de datos en el Paso 1. Omitir estos pasos es la forma más rápida de convertir una migración nocturna bien planificada en un gran problema interno. Utilice esta lista de verificación como guía principal para la migración de su helpdesk .
2.1 Deshabilitar las automatizaciones, las notificaciones y los activadores activos en la plataforma de destino
Cuando se importan registros antiguos a una plataforma en vivo, el motor de automatización del sistema los interpreta como eventos nuevos. Si sus reglas de negocio están activas, se ejecutarán al instante.
El resultado es una pesadilla de notificaciones masivas: miles de correos electrónicos obsoletos y confusos se envían a los clientes sobre incidencias que se resolvieron hace meses. Peor aún, los temporizadores de los acuerdos de nivel de servicio (SLA) se reinician incorrectamente con datos históricos, y las reglas de enrutamiento activas transfieren accidentalmente registros obsoletos a las colas live agent .
Este es el paso que con mayor frecuencia se omite en la lista de verificación para la migración helpdesk , y su omisión provoca los daños operativos más graves.
Antes de iniciar el Paso 1, vaya al panel de administración de su plataforma de destino y desactive todas las automatizaciones, los activadores de notificaciones y las reglas comerciales en vivo:
- Zendesk: Administración > Reglas de negocio > Disparadores
- Freshdesk: Administrador > Flujos de trabajo > Automatizaciones
- Intercom: Ajustes > Bandeja de entrada > Automatización
2.2 Verificar la creación del agente y asignar los perfiles del equipo en el objetivo defront
Si no se configura la asignación de agentes defront , los tickets quedan huérfanos. Los registros llegan a la nueva plataforma sin un propietario válido, asignándose por defecto a un usuario del sistema no supervisado. En un entorno de soporte en vivo, los tickets huérfanos conllevan directamente la pérdida de conversaciones y fallos en los niveles de servicio.
Antes de iniciar el Paso 1, verifique que todos los perfiles de agente, tanto activos como históricos, existan en la plataforma de destino. A continuación, abra la asignación en el Asistente de migración para vincular las identidades de origen y destino. La forma más sencilla de garantizar una coincidencia automática es utilizar direcciones de correo electrónico idénticas en ambas plataformas. Si las convenciones de correo electrónico difieren, asigne manualmente a esos usuarios antes de que comience la transferencia de datos.
3. Paso 1. Abrir boletos durante la noche
Objetivo: Lograr que tu equipo empiece a trabajar en la plataforma objetivo a la mañana siguiente.
El paso 1 es la parte más urgente del proceso. Cada decisión sobre qué incluir y qué excluir se reduce a una sola pregunta: ¿El equipo necesita esto para empezar a trabajar el lunes?
3.1 Qué incluir en el paso 1
Limita tu transferencia inicial a lo que tus agentes necesitan para gestionar las colas activas y migrar los tickets abiertos a nuevos entornos helpdesk de forma limpia:
- Tickets abiertos y pendientes: Esto representa su carga de trabajo operativa en tiempo real y su cartera actual de tickets activos. Todo lo demás queda pendiente para el paso 2.
- Contactos y empresas asociadas: El contexto lo es todo. Importar un ticket sin su perfil de cliente correspondiente interrumpe la conversación y ralentiza a tus agentes.
- Artículos de la base de conocimientos en todos los idiomas: Su base de conocimientos es una herramienta operativa vital. Los agentes necesitan acceso instantáneo a la documentación interna, y los centros de ayuda de autoservicio deben permanecer activos para los clientes desde el momento de la transición.
3.2 Qué excluir del paso 1
- Historiales de tickets cerrados y resueltos: Esto pertenece por completo al Paso 2. Trasladar estos registros a su ejecución inicial agrega un volumen de datos masivo, lo que aumenta peligrosamente su ventana nocturna para activos que nadie tocará el lunes por la mañana.
- Archivos adjuntos de registros archivados: Los archivos adjuntos generan un volumen de datos totalmente desproporcionado a su valor operativo inmediato durante la transición. Posponlos al paso 2. (Los archivos adjuntos vinculados a tickets activos y abiertos pueden incluirse si el tiempo disponible durante la noche lo permite).
- Historial de actividad del agente: Los registros históricos de auditoría interna y los historiales de rendimiento con el archivo de tickets cerrados deben permanecer y moverse junto con el archivo histórico.
Mantener la primera fase optimizada es clave para que el plazo de lanzamiento nocturno sea viable. Cada megabyte que se ahorra en la ejecución inicial supone una garantía para el lanzamiento del lunes por la mañana.
3.3 Uso de la migración multihilo para alcanzar la ventana de transición
Los límites de la API de la plataforma de destino representan el límite absoluto de velocidad para cualquier migración digital. Un motor de migración estándar de un solo hilo procesa las solicitudes de forma secuencial. Esto supone una gran pérdida de velocidad, ya que el rendimiento es mucho menor del que la nueva plataforma puede soportar.
La migración de un helpdesk mediante multihilo cambia las reglas del juego. Al ejecutar varios hilos de solicitud simultáneos, se fuerza el proceso de importación al límite absoluto de la capacidad de la API de la plataforma de destino.
Por ejemplo, un conjunto de datos de 50 000 tickets que tarda 8 horas en transferirse en un solo hilo puede completarse en 3 o 4 horas mediante una transferencia multihilo. Ese ahorro de tiempo suele ser la diferencia entre una implementación exitosa y dejar a los agentes frontlínea sin un sistema activo al inicio de su turno.
Con nuestro paquete de servicios Signature, obtendrá automáticamente la funcionalidad multihilo, y lo recomendamos encarecidamente para el paso 1. Tenga en cuenta que los límites de la API varían considerablemente según su proveedor y plan. Un plan Freshdesk Growth tiene límites mucho más estrictos que una cuenta Enterprise, y Zendesk ajusta su velocidad estrictamente según el nivel. ¿No está seguro de si su configuración puede soportar una ventana de implementación nocturna? Consulte con nuestro equipo de ingeniería antes de fijar una fecha de transición en su calendario.
3.4 Paso 1: Desde el lanzamiento del viernes hasta el cambio de rumbo
Inicie el asistente de migración el viernes por la noche. Supervise el flujo de datos en tiempo real a través del panel de control y no cierre la pestaña del navegador (las actualizaciones se envían automáticamente). No pierda tiempo actualizando la página manualmente; recibirá notificaciones automáticas en su bandeja de entrada en cuanto finalice el proceso.
En cuanto termine el Paso 1, pase directamente a los pasos siguientes:
- Cambia inmediatamente todos tus canales de comunicación a la plataforma de destino. Activa el reenvío de correo electrónico, reemplaza los widgets de chat en vivo de tu sitio web y redirige los enlaces de tu centro de ayuda a la nueva plataforma. Esto evitará que el tráfico de nuevos clientes llegue a tu antiguo sistema.
- Establezca la plataforma de origen en modo de solo lectura. Elimine los permisos de edición de su equipo o agregue un banner de solo lectura. El antiguo servicio de asistencia ahora es solo una fuente de solo lectura, no un espacio de trabajo activo.
Esto prepara a tu equipo a la perfección para el lunes por la mañana. Tus agentes inician sesión y trabajan desde la nueva plataforma, pero el sistema antiguo no puede recibir ni generar nuevas conversaciones.
3.5 ¿Qué sucede si el paso 1 no se completa antes de la mañana?
Si llegan nuevos tickets o se actualizan las conversaciones existentes durante el período de migración, la Migración Delta actúa como una capa de sincronización integrada. Transfiere automáticamente los registros recién creados y actualizados recientemente tras la migración inicial.
La migración Delta revisa tu antiguo servicio de asistencia técnica en busca de actividad nueva tras del Paso 1 y la sincroniza con tu nuevo espacio de trabajo. Gracias a que la sincronización Delta gestiona estos tickets pendientes en segundo plano, tus agentes pueden empezar a trabajar inmediatamente el lunes por la mañana sin perder ningún dato.
Debes ejecutar la Migración Delta dentro de los 10 días posteriores a la finalización de la fase de migración inicial, y está incluida en nuestro plan Signature. Muchos equipos también mantienen su plataforma anterior disponible en modo de solo lectura durante el período de transición, lo que permite a los agentes acceder a datos de referencia históricos mientras el nuevo espacio de trabajo se estabiliza por completo.
4. Lanzamiento del primer día: Los pasos finales para la transición
Este es el flujo de trabajo oficial para el día de la puesta en marcha. Sigue estos pasos al pie de la letra antes de que el equipo empiece a trabajar el lunes por la mañana.
4.1 Cambiar todos los canales de comunicación a la plataforma de destino
Traslada el tráfico de tus clientes al nuevo sistema. Redirige el correo electrónico de soporte a la nueva bandeja de entrada, actualiza el código del chat en vivo de tu sitio web y redirige las URL de tu centro de ayuda. Esta redirección de canal es imperceptible; tus clientes no notarán nada, ya que todos sus puntos de contacto habituales permanecen iguales. Realiza estos cambios antes de que los agentes inicien su primer turno.
4.2 Configurar la plataforma de origen en modo de solo lectura
Bloquea el sistema antiguo y aplica el modo de solo lectura para evitar que los agentes lo utilicen accidentalmente. Revoca sus permisos de edición o añade un aviso claro que los dirija al nuevo sistema. Si un agente actualiza un ticket en la fuente de solo lectura por costumbre, se genera un gran desorden de datos que anula el propósito de la migración nocturna.
Tu equipo aún puede iniciar sesión para consultar el contexto de conversaciones anteriores, pero el sistema antiguo ya no admitirá nuevos trabajos a partir del momento de la transición.
4.3 Ejecutar la migración delta para detectar cualquier actualización de ticket que se haya omitido
Incluso con un Paso 1 sin incidencias, aún necesitas registrar los tickets que cambiaron de manos durante la sincronización. Inicia la migración Delta como parte de la transición justo antes de que tu equipo inicie sesión. Ten en cuenta que esta función está disponible en el plan Signature y debe iniciarse dentro de los 10 días posteriores a la finalización para garantizar que tu nuevo espacio de trabajo esté actualizado.
4.4 Realizar una reunión informativa de equipo de 10 minutos antes de que comience el primer turno
Evita las largas sesiones de capacitación el día del lanzamiento. Céntrate en lo táctico. El día de la puesta en marcha, tu equipo debe brindar soporte a los clientes, no ver presentaciones interminables.
Cubre exactamente cuatro cosas:
- Nuevas credenciales de inicio de sesión.
- Dónde encontrar entradas disponibles.
- Cómo funcionan la búsqueda y el historial.
- A quién contactar si falta algo.
Si ya ha utilizado un entorno de pruebas o ha realizado una migración de demostración, sus agentes estarán familiarizados con la interfaz. Esta reunión inicial es solo una verificación rápida de alineación, no un tutorial sobre las nuevas funciones.
5. Paso 2: Mover tickets cerrados en bloques en segundo plano
Objetivo: Transferir todo su archivo histórico sin interrumpir las operaciones en curso.
Sus agentes ya están ejecutando sus colas, por lo que la intensa vigilancia del reloj del Paso 1 ha terminado. El Paso 2 no tiene un límite de tiempo estricto. El único enfoque ahora es la ejecución en segundo plano que evita:
- Impacto en el rendimiento live agent o en la velocidad del espacio de trabajo.
- Sobrecargar su cuota de API durante el horario comercial habitual.
5.1 Por qué el historial de tickets cerrados sigue siendo importante
No confunda los tickets cerrados con datos inútiles. Son vitales por tres razones principales después de la puesta en marcha:
- Auditorías de cumplimiento y normativas: Dependiendo de su sector, es posible que esté legalmente obligado a conservar las conversaciones con sus clientes durante años. El paso 2 garantiza que la retención de datos cumpla plenamente con la normativa.
- Contexto del agente: Los clientes suelen mencionar problemas anteriores. Cuando un agente abre un nuevo ticket y ve un historial vacío, trabaja a ciegas. Mantener el historial de tickets cerrados a mano conserva las soluciones, notas y preferencias anteriores.
- Continuidad en los informes: Para realizar un seguimiento de las tendencias a largo plazo, los volúmenes estacionales o las puntuaciones históricas de satisfacción del cliente, necesita tener todos sus datos en un solo lugar. Los datos fragmentados dan lugar a métricas confusas e incompletas.
5.2 Organizando tu archivo por fases: Cómo dividir tus rangos de fechas
Utiliza filtros de fecha para dividir tu extenso archivo histórico en fragmentos más pequeños y manejables. La estrategia más inteligente es retroceder en el tiempo. Comienza migrando primero los datos más recientes, ya que son los que tus agentes activos probablemente consultarán con mayor frecuencia.
Hoja de ruta para la migración por fases
| Fase | Alcance | Momento/Método | Estado |
| Paso 1. Día de la puesta en marcha | Tickets abiertos y en curso + KB migrados mediante sincronización nocturna | Sincronización nocturna | Vivir |
| Paso 2. Archivo histórico | Boletos antiguos cerrados e historial a largo plazo | Carga en segundo plano | En curso |
Configure cada lote como una tarea de migración independiente dentro del Asistente de migración. Segmentar los datos de esta manera minimiza la carga del sistema. Si una API de un proveedor falla durante la transferencia, solo afectará a ese fragmento aislado, en lugar de obligarle a recargar toda database.
5.3 Uso de la migración por intervalos para pausar durante el horario laboral
El uso de la lógica de tickets de soporte para la migración por intervalos le permite pausar la transferencia de datos durante las horas pico de actividad y reanudarla automáticamente por la noche o durante los fines de semana.
En lugar de ejecutar una sincronización masiva de datos que consume los límites de tu API y ralentiza tu espacio de trabajo activo, cada pausa a intervalos divide el trabajo en ventanas inteligentes.
Esto mantiene el Paso 2 invisible para tu equipo:
- Sin ralentizaciones por parte de los agentes: Su equipo de soporte no experimentará retrasos ni demoras en la interfaz durante las horas pico.
- Creación silenciosa en segundo plano: El archivo histórico se llena mientras todos están desconectados.
- Programación automatizada: No es necesario detener ni iniciar la herramienta manualmente; se encarga de la programación por usted.
Para equipos empresariales con un alto volumen de incidencias y acuerdos de nivel de servicio (SLA) estrictos, la migración por intervalos convierte una gran carga de datos en un proceso silencioso que se ejecuta en segundo plano.
5.4 ¿Cuánto tiempo dura el paso 2?
A diferencia del impulso urgente del Paso 1, el Paso 2 no tiene una fecha límite fija.
Algunas empresas completan la transferencia de sus datos históricos en tan solo dos noches. Otras optan por un enfoque más conservador, distribuyendo el trabajo a lo largo de dos o tres semanas mediante la ejecución de procesos en segundo plano únicamente durante los fines de semana.
En definitiva, el ritmo de migración ideal depende de tres cosas:
- tu volumen total de registros.
- límites de la API de su plataforma de destino.
- cuánto ancho de banda tienes realmente para supervisar los trabajos.
Consejo de experto: Si su archivo supera los 200 000 registros o si su equipo tiene plazos de cumplimiento estrictos, no tiene que hacerlo solo. Nuestro equipo de Servicios Profesionales puede planificar, segmentar y ejecutar la sincronización histórica de principio a fin.
6. Notas sobre la sincronización específica de la plataforma
Si bien el procedimiento para el paso 2 siempre es el mismo, el cronograma exacto de sincronización en segundo plano depende del par de plataformas con las que esté trabajando.
Cada servicio de asistencia técnica tiene sus propios límites de velocidad de API, reglas de limitación de velocidad y estructuras de datos. Por ejemplo, migrar de Zendesk a Freshdesk requiere una estrategia de ritmo diferente a la de un Freshdesk a Intercom o una Intercom a Zendesk migración.
Los mismos principios se aplican a proyectos como la migración de Zendesk a Intercom , la Intercom a Freshdesk a gran escala Zendesk a Zendesk la consolidación. Cada plataforma gestiona las estructuras de datos, las conversaciones, los archivos adjuntos y la sincronización de forma diferente, lo que puede influir en los plazos y la planificación de la migración.
Al mismo tiempo, la mayoría de las plataformas modernas de soporte técnico ofrecen planes empresariales o complementos de API con mayor capacidad de procesamiento, lo que permite que las migraciones a gran escala se ejecuten mucho más rápido cuando sea necesario. Por eso, el éxito de una migración depende menos de limitaciones técnicas y más de una planificación inteligente, la priorización y la elección de la estrategia de migración adecuada para su cronograma operativo.
Aquí tienes un breve resumen de lo que puedes esperar de cada ecosistema para que puedas planificar tus procesos en segundo plano sin sorpresas.
6.1 Migración Zendesk Express
Zendesk limita la velocidad de extracción e importación según estrictos límites de velocidad de la API. Dependiendo de su plan, puede esperar entre 400 y 700 solicitudes por minuto. Una helpdesk maximiza este rendimiento.
Sin embargo, debes ajustar tus configuraciones previamente para evitar bucles masivos de correo electrónico automatizados. Antes de ejecutar el Paso 1, inicia sesión en Zendesk, ve a Administración > Reglas de negocio > Activadoresy desactiva todos los activadores activos. También debes auditar las configuraciones activas en Reglas de negocio > Automatizaciones.
Dejar activa incluso una sola notificación permite que la plataforma envíe actualizaciones accidentales a los clientes antiguos, lo que corrompe los metadatos históricos durante la transición.
Al mismo tiempo, la migración también ofrece la oportunidad de eliminar campos obsoletos o innecesarios. No es necesario transferir todos los campos heredados, y muchos equipos dejan intencionadamente campos personalizados sin usar para evitar saturar el nuevo espacio de trabajo.
6.2 Migración Freshdesk Express
Freshdesk ajusta la velocidad de ingesta e importación según límites estrictos de la API. Dependiendo de tu plan, puedes esperar entre 40 solicitudes por minuto en los planes básicos y aproximadamente 1000 en el plan Enterprise. Si tu equipo opera con un plan Growth, este menor rendimiento limita considerablemente el rendimiento durante la noche.
Gestiona cuidadosamente tus bloques de datos activos para evitar bloqueos de integración en toda la cuenta. La migración por intervalos te permite pausar la transferencia en segundo plano durante las horas pico y reanudarla automáticamente cuando disminuye el tráfico. Esta opción operativa evita que las cargas de datos elevadas ralenticen tu espacio de trabajo o provoquen tiempos de espera del sistema para los agentes de soporte en vivo.
6.3 Migración de Intercom Express
Intercom regula la velocidad de importación mediante un sistema de cuotas diarias único, en lugar de límites por minuto. Según el nivel de contrato contratado, los espacios de trabajo reciben un presupuesto fijo para llamadas a la API que se restablece a medianoche UTC.
Asegúrese de frontel contenido de la base de conocimientos (KB) directamente en el paso 1. Al cargar los artículos con anticipación, se asegura de que live agenty las funciones de IA financiera cuenten con una database de alta calidad lista para resolver problemas desde el primer día. Para datos heredados que puedan afectar su presupuesto diario, verifique la cuota restante en su Centro de desarrolladores Intercom antes de establecer la fecha de lanzamiento.
7. Preguntas frecuentes sobre la migración exprés: Gestión de la secuencia de migración en dos pasos
¿Cuánto tiempo tarda el Paso 1 de la Migración Express?
Para equipos de soporte con menos de 50 000 tickets abiertos y pendientes, el Paso 1 generalmente se completa durante la noche, en un plazo de 4 a 8 horas. La velocidad exacta depende del volumen de registros, los límites de velocidad de la API de la plataforma y el uso de multihilo. Ejecutar una demostración rápida es la forma más sencilla de determinar el tiempo exacto que tardará su plataforma.
¿Mis clientes se darán cuenta de que hemos cambiado de plataforma?
No, siempre y cuando redirijas tus canales de correo electrónico, widgets de chat y URL del portal del cliente al nuevo sistema antes de que los agentes inicien sesión. Tus principales canales de comunicación seguirán siendo los mismos; solo cambia el software de backend que los gestiona. Si se hace correctamente, el cambio de plataforma será imperceptible para los usuarios finales.
¿Qué sucede con los tickets creados durante el Paso 1?
La migración Delta registra todos los tickets creados o actualizados en su plataforma anterior una vez iniciado el Paso 1, transfiriéndolos de forma segura al nuevo destino. Esta medida de seguridad elimina cualquier pérdida de datos durante el período de transición. Recuerde iniciar la sincronización Delta dentro de los 10 días posteriores a la finalización del Paso 1. Esta opción está disponible en el plan Signature.
¿Necesito desactivar las automatizaciones antes de migrar?
Sí. Omitir este paso es un error sumamente costoso en una migración Express. Mantener activados los activadores o flujos de trabajo automatizados en el nuevo sistema durante la importación provoca que la plataforma envíe miles de notificaciones heredadas a los antiguos contactos de clientes. Además, altera permanentemente los temporizadores de seguimiento de SLA en todo el archivo histórico.
¿Cuándo debo utilizar servicios profesionales en lugar de autoservicio?
Recomendamos servicios profesionales para migraciones complejas que involucren más de 200 000 registros, plazos de entrega estrictos según los acuerdos de nivel de servicio (SLA) o asignaciones de campos personalizados complicadas. Si está consolidando varias plataformas de origen en una sola, nuestro equipo de ingeniería puede definir el alcance, asignar los parámetros y ejecutar la secuencia completa de forma segura en su nombre.
8. Configuración recomendada para la migración rápida
Si tu equipo de soporte trabaja con una databaselimpia (es decir, con menos de 50 000 tickets activos y abiertos) y tienes todo el fin de semana por delante, nuestro asistente de autoservicio puede gestionar la carga fácilmente. Solo tienes que configurar el Paso 1 en tu panel de control, marcar los elementos de tu lista de premigración y pulsar el botón de inicio.
Pero cuando databaseson enormes o están llenas de información obsoleta, las cosas se complican. Si quieres que tu equipo inicie sesión sin problemas el lunes por la mañana, tu éxito depende completamente de cómo aproveches dos características de ingeniería fundamentales:
- Migración multihilo: Este protocolo fuerza la API de la plataforma de destino a alcanzar su máximo rendimiento para reducir el tiempo de la Fase 1. Disponible en nuestro Paquete de Servicios Signature, esta es su herramienta principal para procesar grandes conjuntos de datos del primer día.
- Migración por intervalosplano nunca ralentiza a sus frontagentes de soporte.
Si se enfrenta a una fecha límite de vencimiento de contrato de software muy ajustada, volúmenes de archivo enormes o una combinación de plataformas extremadamente restrictiva, un enfoque de bricolaje podría no ser suficiente. Nuestro equipo de servicios profesionales está disponible para diseñar su arquitectura específica y gestionar todo el proceso de migración de principio a fin.
Migración Express: Empiece a publicar el lunes, archive según su calendario
Una migración exprés salva la distancia entre velocidad y seguridad de datos. Tus agentes de soporte simplemente inician sesión en la nueva plataforma el lunes por la mañana y comienzan a trabajar, mientras que tus archivos históricos se actualizan discretamente en segundo plano a un ritmo que se adapta a tu flujo de trabajo.
La lógica principal no cambia según el proveedor de su mesa de ayuda. Priorizar los datos esenciales del primer día y transmitir los archivos a largo plazo después es un marco que funciona para cualquier configuración empresarial. Los únicos elementos que varían son sus métricas de tiempo específicas:
- La velocidad del paso 1 depende totalmente del volumen de tickets activos y de los límites de la API de la plataforma.
- Los plazos del paso 2 se ajustan en función de la profundidad total de su archivo y las ventanas de sincronización diarias.
El resultado es predecible. No hay tiempo de inactividad operativa, ningún agente tiene que manejar dos sistemas diferentes y no hay riesgo de que los correos masivos no deseados molesten a sus clientes.
Gestionar una infraestructura empresarial compleja implica ir más allá de la transición inicial del fin de semana. Consulta nuestra Guía completa de migración de datos para auditar la arquitectura completa de tu canalización de datos, o lee la Guía de migración con IA como prioridad para configurar tu nueva plataforma con herramientas de soporte automatizadas.
