Migración de datos para proveedores de servicios gestionados: Su PSA, no la de sus clientes
Si buscas "migración de datos para proveedores de servicios gestionados", encontrarás un sinfín de artículos sobre cómo trasladar los buzones de correo de los clientes a Microsoft 365.
Esta página abarca su PSA, sus tickets y su mesa de ayuda: el sistema que sustenta su negocio. Como MSP, esos datos pertenecen a decenas, a veces cientos, de clientes simultáneamente, por lo que el aislamiento por cliente, la continuidad de la facturación y una transición sin problemas son cruciales aquí. Descubra cómo funciona la planificación de migraciones específica del sector y aplíquela a la migración de un MSP PSA, donde las consecuencias son mayores.
Sin tarjeta de crédito Montaje rápido
Con la confianza de más de 60.000 empresas
Tipos de migración de datos: ¿Qué se traslada en una migración de PSA?
Un cambio a PSA no es una migración de tickets con pasos adicionales. Internamente, un solo ticket se vincula a paneles, colas, campos personalizados, políticas de SLA y configuraciones que también deben conservarse tras la migración. A continuación, se presenta el alcance completo, comenzando por los datos del servicio de asistencia, en el orden en que la mayoría de los MSP los procesan:
| Récord establecido | Lo que incluye | Qué observar en una película | Nota de aislamiento por cliente |
|---|---|---|---|
| Tickets de mesa de ayuda y PSA | Casos, tickets, hilos de tickets, tableros, colas, estados, etiquetas, campos personalizados | Las estructuras de los tablones de anuncios y las colas rara vez coinciden exactamente entre las distintas plataformas | Los boletos deben mantener la relación correcta con la empresa o el cliente |
| Registros de tiempo y contratos | Registros de tiempo, registros de contratos, configuraciones, referencias de facturación | El estado de facturación normalmente no se transfiere con el registro, véase más abajo | Los términos del contrato son específicos para cada cliente y no se aplican a otros clientes |
| Base de conocimientos | Artículos, categorías, visibilidad por cliente frente a visibilidad interna, archivos adjuntos de artículos | La configuración de visibilidad requiere una decisión, no solo una regla de mapeo | Los artículos compartidos requieren una decisión explícita sobre qué clientes pueden acceder a ellos |
| Datos del cliente y de contacto | Empresas, contactos, sitios, jerarquía organizativa, estructura de agentes y grupos | Esta es la columna vertebral del resto de las claves de migración | Dónde el aislamiento tiene éxito o fracasa primero |
| Archivos multimedia y adjuntos | Imágenes en línea, archivos adjuntos, límites de tamaño y retención | Los límites de tamaño del objetivo pueden ser más estrictos que los de la fuente | Los archivos adjuntos heredan el aislamiento del ticket o registro al que pertenecen |
| Historial de correo electrónico | Hilos de entrada y salida vinculados a tickets, preservación de encabezados | La conservación de la cabecera varía mucho según el par de plataformas | Los hilos permanecen aislados mientras el ticket principal lo esté |
| Registros y grabaciones de llamadas | Registros telefónicos y enlaces de grabación adjuntos a los billetes | En ocasiones, los enlaces de grabación apuntan a un sistema de terceros que se mueve de forma independiente | Misma dependencia que los archivos adjuntos |
Se trata de siete conjuntos de registros, no de uno. Los tickets son el elemento central: constituyen el conjunto más grande, y es fácil confundir un cambio de PSA con una migración de tickets. Sin embargo, cada uno de los otros seis conjuntos de registros mantiene su propio nivel de aislamiento por cliente para protegerlo durante la migración. Los registros de tiempo y los contratos tienen un peso financiero que los tickets no tienen. Los datos del cliente son la base sobre la que se sustenta todo lo demás. Incluso elementos tan comunes como los archivos adjuntos y los registros de llamadas heredan su aislamiento del ticket o registro al que están vinculados. Ninguno de ellos es opcional solo porque nadie los haya mencionado antes.
Lo que se transfiere realmente depende de lo que publique tu plataforma de origen y de lo que pueda gestionar tu plataforma de destino. Considera esta tabla como un documento de alcance que debes evaluar antes de comprometerte con una plataforma.
Plataformas de migración compatibles para empresas MSP
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.
Por qué el aislamiento por cliente es el requisito real, no el número de tickets
El aislamiento no es una función que se pueda activar sin más. Depende de cómo se mapean y verifican los datos durante la migración. Esto es lo que diferencia la migración de un servicio de asistencia técnica gestionado (MSP) de un proyecto de un solo inquilino: los datos pertenecen a varios clientes, por lo que el mapeo y la validación deben realizarse para cada cliente, no una sola vez para todo el conjunto de datos.
Ese simple hecho añade más tiempo a un proyecto que el volumen de registros. Una migración que involucre a 40 clientes con volúmenes de datos moderados puede requerir más tiempo para su planificación y validación que una migración de un solo cliente con muchos más registros. Cada cliente necesita su propia revisión y validación de mapeo antes de la transición.
El aislamiento no es algo que una plataforma te regale. Proviene de decisiones tomadas durante la fase de mapeo y se confirma mediante la validación por cliente antes de la puesta en marcha, no se da por sentado solo porque ambas plataformas incluyan la palabra "multiusuario" en sus páginas de marketing.
Cómo se ve el mapeo deliberado en Autotask PSA
¿Qué significa realmente "diseñado deliberadamente"? En Autotask PSA, cada contacto debe estar vinculado a una empresa. No hay atajos. Los contactos independientes de su sistema de origen se asignan a una empresa durante el proceso de mapeo, sin que se les permita gestionarse por sí solos.
Autotask PSA tampoco permite cambiar la empresa de un contacto después de su creación, razón por la cual una migración de demostración para verificar la asignación de la empresa es más importante en este caso, especialmente si se están fusionando cuentas.
En cuanto a los informes, la validación se realiza a través del panel de control en tiempo real del Asistente de Migración, que rastrea los tickets, agentes, contactos y empresas como entidades separadas durante la transferencia, y finaliza con un informe sobre qué se migró, qué no y por qué. Nada de esto es automático. Se trata de una regla de mapeo y un panel de control que alguien consulta, lo cual es una afirmación menos precisa que "el aislamiento está integrado", y más cierta.
Aspecto del mapeo por cliente: Migración desde ConnectWise
Tomemos ConnectWise como ejemplo concreto ConnectWise la migración se consolida en una empresa, y esta se divide en sitios para los clientes que operan en más de una ubicación. Durante la migración, es necesario asignar correctamente estas relaciones para cada cliente.
Esto cobra mayor importancia cuando la plataforma de origen tiene varios clientes agrupados bajo un mismo registro de empresa. Este problema debe resolverse antes de que comience la migración, no durante su ejecución. Ninguna herramienta separa automáticamente los datos de clientes mezclados; esto requiere la intervención de una persona, una decisión y una asignación minuciosa. La misma disciplina se aplica a la migración de datos para empresas de servicios de TI en general; el aislamiento no es exclusivo de los MSP, simplemente tiene mayores implicaciones en este caso.
Otro mito que conviene desmentir: la multitenencia es una característica del producto, no el resultado de una migración. Que una plataforma sea multitenencia significa que puede albergar clientes independientes sin que estos se vean entre sí mientras está en funcionamiento. Esto no garantiza que los registros se almacenen en el lugar correcto durante una migración entre dos plataformas multitenencia. Ahí radica la imprecisión de las afirmaciones de los proveedores. Si alguien le está ofreciendo una migración, pregúntele a qué se refiere exactamente.
Validar cada cliente antes de la transición
En la práctica, la validación por cliente antes de la transición significa comprobar los registros asignados a cada cliente individualmente, sin muestrear el conjunto agregado:
Para un proveedor de servicios gestionados (MSP) con pocos clientes, ese pago se procesa rápidamente. Para uno con docenas o cientos, es la parte del proyecto que consume más tiempo que la transferencia de datos en sí.
Un buen consejo es validar cada cliente por separado antes de la migración. Si algo falla, se puede revertir la migración de ese cliente sin afectar a los que ya han superado la validación. Esto permite aislar los problemas y facilita el control de la migración en general.
Las cuestiones de seguridad y cumplimiento normativo surgen desde el principio para los proveedores de servicios gestionados (MSP) que evalúan a un socio de migración, y con razón. Lea Help Desk Migrationla política de seguridad de junto con el enfoque de aislamiento que proponga el proveedor para su migración específica.
Los discos de PSA que tienen un precio
La migración del servicio de asistencia de un MSP no se limita a los tickets. Un PSA almacena registros de tiempo y contratos junto con los tickets, y estas dos categorías tienen un peso financiero que los tickets simplemente no tienen. Si se pierde el historial de un ticket, se genera un gran problema de servicio. Si se pierde el estado de facturación de un registro de tiempo, tres semanas después de la migración, uno se encuentra con una gran cantidad de horas facturables del mes anterior que nunca se facturaron. Cualquier propietario de un MSP le dirá que no se trata de la misma situación de emergencia.
| Tipo de registro | Se mueve directamente | Mapeo de necesidades | Tiene consecuencias en la facturación |
|---|---|---|---|
| Entradas | Sí | A nivel de campo, generalmente sencillo | No |
| Registros de tiempo | Según los registros | Sí, la estructura varía según el par | Sí |
| Contratos | Parcialmente | Ver marcador de posición a continuación | Sí |
| Configuraciones | Parcialmente | Depende del modelo de activo | A veces |
| Empresas | Sí | Aislamiento crítico, ver más arriba | No |
| Contactos | Sí | Vinculado al mapeo de la empresa | No |
| Sitios | Sí | Vinculado al mapeo de la empresa | No |
| Políticas de SLA | Rara vez uno a uno | Generalmente se reconstruyen, no se trasladan | No |
| Campos personalizados | No | Configuración manual en el objetivo | A veces |
| Archivos adjuntos | Sí | Los límites de tamaño y retención varían | No |
Registros de tiempo vs. Estado de facturación
Los registros de tiempo generalmente se migran como registros, pero no como estado de facturación, y la razón es estructural: el estado de facturación normalmente reside en la capa financiera de la plataforma, no en el ticket ni en el registro de tiempo en sí. Autotask PSA lo explica bien. Un registro de tiempo asociado a un ticket necesita aprobación y contabilización antes de convertirse en una línea facturable. Lo que se hizo y cuánto tiempo tomó se migra correctamente con el registro. Si alguien ya lo aprobó, contabilizó o facturó, eso es otra cuestión.
Es un tipo de transacción que normalmente se resuelve en el flujo de trabajo de facturación de la plataforma de destino, en lugar de transferirse automáticamente.
Opciones del asistente y matices de la plataforma
Help Desk Migration incluye "Migrar registros de tiempo" como una opción seleccionable en el Asistente de migración, que describe la transferencia de los registros que los agentes utilizan para registrar el tiempo dedicado a los tickets. Esta es una opción real y compatible, no una solicitud especial de trabajo personalizado. Lo que la descripción publicada no especifica es si el estado de aprobación, publicado o facturado se transfiere con esta opción para su conjunto específico de plataformas.
Se trata de una laguna legítima en la información pública, así que considere el comportamiento general del estado de facturación mencionado anteriormente como fiable y la pregunta sobre la bandera específica para cada par de datos como una que debe consultar directamente con su especialista en migración.
Contratos como objetos personalizados
Los contratos reciben el mismo tratamiento. Ni la lista de campos publicada de ConnectWise PSA ni la de Autotask PSAincluyen los contratos como un tipo de registro estándar. Los campos documentados de ConnectWise PSA abarcan miembros, contactos, empresas y tickets. Los de Autotask PSAabarcan agentes, empresas, contactos y tickets. Los contratos se incluyen en la migración de objetos personalizados, en la misma categoría que los activos y las garantías, y se gestionan a través de Servicios Profesionales en lugar del flujo de asignación de campos estándar.
En resumen: los contratos no se incluyen automáticamente en la migración de tickets. Presupóngalos como un proyecto independiente con un alcance definido.
Estructura de la relación empresa-contacto
Help Desk Migration traslada los registros de tickets y contactos entre plataformas PSA, conservando la estructura de empresa a contacto que mantiene separados los registros de cada cliente, y trata la conciliación del estado de facturación como un paso independiente del traslado de los registros subyacentes. Si su evaluación depende del comportamiento exacto de los indicadores de facturación para su par específico, conviene confirmarlo directamente antes de definir el alcance.
Consulte la Autotask PSA importación de datos para obtener detalles específicos de la plataforma.
Hágalo usted mismo, gestionado o personalizado: cómo elegir su migración para proveedores de servicios gestionados
Existen tres maneras de llevar a cabo la migración del servicio de asistencia técnica para operaciones de MSP, y cuál se adapta mejor a usted depende más del número de clientes que del volumen de registros:
Asistente de migración, autoservicio
Ideal si eres un pequeño proveedor de servicios gestionados (MSP), con pocos clientes, y quieres migrar una plataforma consolidada sin configuraciones complejas para cada cliente. Defines los campos, realizas una migración de prueba, la revisas y, finalmente, ejecutas la migración completa.
Servicio gestionado
La opción predeterminada para la mayoría de los proyectos de MSP es la siguiente: la asignación de clientes individuales para decenas o cientos de clientes requiere una conversación, no una simple lista de verificación. Este es Help Desk Migrationde el servicio de migración gestionada: definimos el alcance del proyecto junto con usted, creamos la asignación, realizamos una migración de prueba para su revisión y, finalmente, gestionamos la migración.
Consultoría
Para los casos más complicados: datos de origen inusuales, objetos personalizados, varias plataformas de origen que consolidar a la vez o un problema de secuenciación junto con un proyecto independiente del lado del cliente.
En este sentido, los importadores nativos de PSA merecen un reconocimiento especial. La mayoría de las plataformas PSA cuentan con una CSV herramienta de importación nativa o Entonces, ¿dónde se justifica realmente un servicio de migración gestionada? En los aspectos para los que un importador nativo no fue diseñado: la asignación de datos por cliente a gran escala, la conciliación de registros de facturación entre plataformas con diferentes modelos financieros y la validación que verifica los datos de cada cliente individualmente, en lugar de muestrear el conjunto y darlo por válido.
Imaginemos dos proveedores de servicios gestionados (MSP) uno al lado del otro. Uno gestiona dos clientes y un volumen de tickets moderado en plataformas bien documentadas con una correspondencia casi uno a uno. En este caso, el autoservicio es una buena opción. El otro gestiona 50 clientes, y su número total de registros puede parecer menor sobre el papel que el del MSP con dos clientes. Pero eso no importa. 50 clientes implican 50 asignaciones y 50 validaciones, porque ese trabajo se escala con el número de clientes, no con el número de filas, y no se reduce como ocurre con el esfuerzo de una migración de un solo inquilino cuando baja el volumen.
¿No tienes ninguna API en tu fuente? Eso cambia la conversación sobre el alcance desde el primer día. Algunas configuraciones de PSA antiguas o muy personalizadas solo exportan en formato CSV, lo cual es viable, pero modifica la cantidad de tareas del proyecto que se pueden automatizar frente a las que se realizan manualmente.
En lo que respecta a una versión específica de la plataforma, Halo Service Solutions la migración y ConnectWise a Freshdesk la migración cubren dos de los pares entre los que los MSP realizan más migraciones.
Reducción sin dejar ninguna brecha visible en el servicio
La fase de transición es donde la migración del servicio de asistencia técnica para las operaciones de MSP se vuelve real: no puedes tomarte un periodo de mantenimiento que tus clientes notarán.
Esa limitación es la razón por la que la transición parece una operación paralela en lugar de un simple cambio instantáneo: ambas plataformas permanecen activas durante un tiempo después de que se ejecute la migración principal, y una migración Delta traslada todo lo creado o actualizado en ese lapso: nuevos tickets, respuestas, registros de tiempo, antes de que se retire definitivamente la fuente.
Operar dos plataformas simultáneamente tiene una consecuencia que conviene planificar con antelación: los agentes gestionarán incidencias en ambos sistemas durante el período de solapamiento, y el esquema de numeración debe ser coherente en ambos. Esta es una decisión que se toma con tiempo, no un detalle que se resuelve el día de la puesta en marcha.
Dos decisiones concretas, ambas programadas antes del inicio del cambio
En primer lugar, la numeración de los tickets: ¿puede la plataforma de destino mantener la numeración de la fuente o inicia su propia secuencia?
Esto depende realmente de adónde te dirijas. Los campos documentados de los tickets de Autotask PSAmuestran tanto el ID como el número de ticket como campos separados, por lo que el número de origen tiene dónde ubicarse. Los campos documentados de ConnectWise PSA muestran el ID, pero no un campo separado para el número de ticket, lo que significa que llega como un valor en lugar de reproducir necesariamente la secuencia propia de ConnectWise. Si tus clientes ven números de ticket, confírmalo específicamente para tu plataforma objetivo antes de definir el alcance del proyecto. La plataforma que estás dejando no es un indicador fiable de la que vas a utilizar.
Segundo: ¿cuándo se realizará el cambio al portal de atención al cliente? Esta es una pregunta aparentemente sencilla, pero con consecuencias mucho mayores. Los clientes tienen esa URL guardada en sus marcadores y han accedido a través de ella innumerables veces. Programar ese cambio a última hora, una vez que los datos ya se han transferido, es precisamente la forma en que una migración técnicamente impecable se convierte en una mala experiencia para el cliente.
No existe una migración de PSA sin interrupciones, y cualquiera que diga lo contrario está vendiendo, no describiendo. En la experiencia de Help Desk Migration, lo realista es un impacto prácticamente nulo para el cliente, y el grado de impacto depende del número de clientes, la configuración del portal y cómo la plataforma de destino gestiona la numeración de tickets. Un MSP cuyos clientes solo envían solicitudes por correo electrónico suele tener una transición más sencilla que uno que utiliza un portal de clientes muy concurrido. Un sistema menos que migrar en directo, un problema menos que pueda surgir.
Reserva una llamada para definir el alcance de la migración →
¿Cuánto cuesta realmente la migración a un proveedor de servicios gestionados (MSP) y cuánto tiempo tarda?
La fijación de precios de la migración de datos de MSP sigue una lógica diferente a la de un proyecto de un solo inquilino, y la pregunta inicial es la misma: ¿cuánto va a costar y cuánto tiempo tardaré en terminar? Es una pregunta válida. Esto es lo que realmente influye en el precio:
El número de clientes es la variable que distingue un proyecto de MSP de uno de un solo inquilino, y a menudo influye más en el coste y el plazo que el volumen bruto de registros. Una migración de bajo volumen que abarca 40 clientes puede resultar más cara y tardar más que una migración de alto volumen para una sola empresa, ya que el mapeo y la validación se escalan con el número de clientes, no con el número de filas. El tiempo de entrada y la complejidad de los contratos agravan esta situación: un PSA con varios tipos de contrato y reglas de facturación detalladas por cliente tarda más en mapearse que uno que utiliza una estructura plana simple, independientemente del volumen de tickets.
El hecho de que su fuente cuente con una API también influye directamente en el costo y el plazo de entrega. El acceso a la API generalmente implica un proceso más automatizado. Las fuentes que solo admiten CSVo que están altamente personalizadas suelen requerir un mapeo más manual antes incluso de que comience la migración. Los precios de migración de Help Desk Migrationreflejan estas variables, no un precio fijo por registro.
Vamos a poner cifras reales en lugar de andarnos con rodeos. Help Desk Migration se basan en la cantidad de registros, y la tarificación no es lineal: cuanto más migres, menos pagarás por registro. En el plan Estándar, sin personalización, una Los precios de migración de 1000 registros cuesta 100 $ . Una migración de 10 000 registros cuesta 514 $ . La lógica favorece el volumen, y por eso 40 migraciones pequeñas por cliente no resultan tan rentables como una migración grande para un solo inquilino.
Los paquetes de servicios se adaptan a la complejidad: el paquete Estándar cubre una migración de conmutación por hardware única, el paquete Premium gestiona hasta 50.000 registros con soporte especializado, y los paquetes Signature y Enterprise añaden migración Delta, migración por intervalos, migración multihilo y un equipo de cuentas dedicado para los proyectos más grandes y con múltiples clientes.
Nada de esto sustituye a un presupuesto real. Help Desk Migration solo ofrece un precio definitivo por escrito después de que una migración de demostración gratuita confirme con qué sistema estás trabajando realmente.
Calcula el coste de tu migración como punto de partida, basándote en el número de clientes y plataformas que utilizas, sobre todo si eres un MSP pequeño donde el autoservicio podría ser la mejor opción. ¿Tienes más clientes y mayor complejidad? Una llamada para definir el alcance del proyecto te dará una respuesta más útil que cualquier estimación basada en el volumen.
Dos proveedores de servicios gestionados, dos migraciones, dos historias reales
Dos casos reales de migración a MSP PSA demuestran la viabilidad del proyecto mejor que cualquier promesa.
VestaTech se traslada a ConnectWise PSA
VestaTech, una empresa de servicios de TI y seguridad con sede en Ardooie, Bélgica, perteneciente al grupo de empresas Vestagroup, necesitaba migrar aproximadamente 2000 tickets, clientes y registros de actividad relacionados desde Freshservice a ConnectWise PSA. Antes de la migración, el equipo utilizaba un script de exportación propio y ya había descartado la importación manual por considerarla demasiado laboriosa para ese volumen de datos. La prueba inicial reveló algunos errores menores, que VestaTech y el equipo de soporte resolvieron antes de la migración completa. Tras revisar los resultados de la prueba, VestaTech afirmó que ninguna otra opción se acercaba a la calidad esperada. La migración de VestaTech a ConnectWise constituye un excelente ejemplo para las empresas de servicios que implementan una solución PSA completa. Demuestra un cambio directo de plataforma en lugar de una fusión, una distinción importante para el siguiente caso.
ROIcode, fusionando dos instancias de soporte en una
ROIcode, una empresa de tecnología de la información y servicios con sede en Denver, Colorado, necesitaba integrar dos sistemas de soporte técnico independientes, Kayako Classic y Zendesken la nube Kayako , en lugar de desactivarlos por completo. La fusión de cuentas de ROIcode en Kayakoconsolidó ambas fuentes de soporte técnico en una sola instancia, conservando el historial completo de soporte de la empresa desde el primer día. Si su equipo necesita fusionar cuentas tras una adquisición en lugar de cambiar de plataforma por completo, este caso práctico muestra cómo llevar a cabo este proceso sin problemas.
Rutas de migración documentadas frente a resultados para el cliente
Más allá de las historias de clientes mencionadas, Help Desk Migration ha documentado y mapeado rutas de migración para las plataformas PSA y RMM que los MSP utilizan con mayor frecuencia: SuperOps, Syncroy Atera, además de guías paso a paso para ConnectWise migraciones, Autotask PSA migraciones, la SuperOps lista de verificación de migración de datosy la Halo Service Solutions lista de verificación de migración de datos.
Conviene ser precisos sobre el significado de estos dos tipos de evidencia, ya que los MSP que evalúan a un proveedor se dan cuenta cuando la distinción se difumina. Un caso de éxito de un cliente, ya sea de VestaTech o ROIcode, es un resultado: una empresa, una migración, un resultado, reportado una sola vez y no extrapolado posteriormente. Una ruta de migración documentada es diferente. Indica que Help Desk Migration es compatible con esa plataforma y que ya existe una asignación para ella, no que se haya ejecutado un proyecto de un tamaño o complejidad específicos. Ambas son importantes. Ninguna sustituye a la otra, y cualquier página que las trate como intercambiables es una página en la que se debería confiar menos.
La escalabilidad es la otra cara de la moneda en cuanto a la confianza. Help Desk Migration ha completado más de 60 000 migraciones, es compatible con más de 100 plataformas y cumple con las normas SOC 2 Tipo II y SOC 3 Nada de esto reemplaza la trayectoria de VestaTech ni la de ROIcode. Simplemente confirma que la misma disciplina que ambas empresas demostraron está disponible a gran escala, no como un servicio puntual.
Antes de analizar esto, comience aquí
Para un proveedor de servicios gestionados (MSP), el alcance de la migración debe definirse cliente por cliente, no como un único conjunto de datos extenso.
Antes de comprometerte con la migración, realiza las mismas cinco comprobaciones para cada cliente:
No reutilice una misma configuración para todos los clientes sin comprobar las diferencias. Un cliente con un volumen de operaciones bajo, una estructura empresarial diferente o campos personalizados puede requerir una configuración distinta a la de un cliente mucho mayor.
Halo Service Solutions Las listas de SuperOps verificación de migración de datos de Help Desk Migrationde y siguen la misma estructura de conexión, configuración, selección, asignación y prueba. Utilice este formato como punto de partida para su propia lista de verificación de migración por cliente.
La regla es sencilla: un cliente, una revisión de mapeo, una validación antes de la puesta en marcha.
Preguntas frecuentes
Un servicio de asistencia técnica para MSP es la capa de gestión de incidencias y soporte dentro de una plataforma PSA, o en ocasiones una herramienta independiente, que los técnicos utilizan para registrar, enrutar y resolver solicitudes de diversas organizaciones clientes desde una única instancia. Generalmente se integra con la facturación, los contratos y los registros de activos, en lugar de funcionar como una herramienta de soporte independiente. Si está eligiendo o reconsiderando un software ITSM para MSP, compare las opciones disponibles
MSP es un modelo de negocio: una empresa que gestiona la TI de otras empresas mediante contrato. PSA es una categoría de software: una plataforma de automatización de servicios profesionales que gestiona dicho negocio, integrando tickets, registros de tiempo, contratos y facturación en un solo lugar. La mayoría de los MSP utilizan una plataforma PSA en lugar de un servicio de asistencia técnica genérico, ya que una plataforma PSA incorpora una capa financiera de la que carece un servicio de asistencia técnica. Consulte ConnectWise la migración para ver un ejemplo común de esta categoría.
Para un MSP, el PSA funciona como el sistema operativo para el trabajo con los clientes. Los tickets, los registros de tiempo, los contratos y la facturación se gestionan para un cliente, sitio o contacto específico, y a menudo también con los datos de RMM. Un servicio de asistencia técnica se detiene en "ticket resuelto". Un PSA continúa con "horas registradas" y "factura generada". Consulte Autotask PSA para ver un ejemplo práctico de esta estructura.
bien las distintas fuentes presentan esta información de forma diferente, la mayoría de los marcos de trabajo dividen la migración de datos en migración de almacenamiento, database , migración de aplicaciones y migración de procesos de negocio. Este modelo está diseñado para la infraestructura, no específicamente para registros de PSA o tickets. Si esto es lo que buscabas, Help Help Desk Migrationel proceso de abarca la versión a nivel de registro que se aplica a los datos de la mesa de servicio.
No existe una única herramienta ideal. Depende de las plataformas involucradas, de si la fuente cuenta con una API y de cuánto de la migración requiere mapeo personalizado o una simple coincidencia de campos. Para datos de PSA y mesa de ayuda en particular, compare Help Desk Migrationde los servicios de migración con la herramienta de importación nativa de su plataforma de origen antes de tomar una decisión.
La mejor opción depende del número de clientes, de si necesita facturación y seguimiento del tiempo integrados, y del nivel de integración requerido. Algunos proveedores de servicios gestionados (MSP) utilizan una plataforma PSA, ConnectWise o Autotask dedicada. Otros ofrecen una mesa de ayuda más sencilla junto con un sistema de facturación independiente. Compare las opciones de mesa de ayuda y gestión de servicios de TI (ITSM) diseñadas para MSP antes de asumir que una plataforma PSA completa es la única alternativa viable.
Más allá del propio PSA, su conjunto de herramientas suele incluir software RMM para la monitorización y gestión remota, una plataforma de documentación y, a veces, una capa de gestión de incidencias independiente. Algunos ejemplos de PSA y RMM para MSP son ConnectWise PSA, Autotask PSA, Halo Service Solutions, SuperOps, Syncro, Atera, NinjaOney SherpaDesk, además de herramientas ITSM diseñadas específicamente para el sector MSP, como ManageEngine ServiceeDesk Plus MSP. Consulte la lista SuperOps de competidores para ver una opción integral más reciente.
Un CRM realiza un seguimiento del embudo de ventas, los contactos y las negociaciones. Un PSA realiza un seguimiento de la prestación de servicios: tickets, tiempo, contratos y facturación a clientes actuales, no potenciales. Algunas plataformas combinan ambos, pero para un MSP, el PSA suele ser el sistema de registro principal para el trabajo de servicio, mientras que un CRM, si es que se utiliza, se centra en la captación de nuevos clientes. Vea cómo ConnectWise estructura esos datos.
El término "MSP en la nube" suele referirse a un proveedor de servicios gestionados que administra la infraestructura en la nube de un cliente, o a la migración de un cliente a servicios en la nube como Microsoft 365. Este es un proyecto distinto al que se aborda en esta página: la migración de los datos de PSA y mesa de ayuda propios, en lugar del entorno en la nube de un cliente. Consulte la de por qué los MSP cambian de plataforma para obtener más información sobre esta cuestión.
Los marcos de trabajo comunes incluyen la migración de aplicaciones, la migración de plataformas, la recompra, la refactorización, la retirada, la retención y la reubicación; un modelo diseñado para la migración de infraestructura y aplicaciones, no para datos de PSA o tickets. Si la búsqueda sobre migración a la nube es lo que le trajo hasta aquí, consulte cómo funciona el proceso de migración para el equivalente a nivel de registro que se aplica a los datos de la mesa de ayuda y PSA.