Migrar desde ManageEngine Service Desk Plus — una guía de campo

Toda migración de ITSM es un pequeño proyecto de arqueología. Diez años de historial de tickets, tres o cuatro generaciones de campos personalizados, una regla de SLA medio olvidada que solo se aplica durante el cierre del ejercicio fiscal: todo eso tiene que sobrevivir al traslado, o el equipo de operaciones pierde memoria institucional. Esta guía está escrita para el ingeniero o responsable de TI al que le han entregado una instancia de ManageEngine Service Desk Plus (SDP) y le han dicho que la traslade a LinaDesk antes del próximo ciclo de renovación.

Asumimos que su SDP está on-premise (Build 14xxx o 15xxx), con algo entre 5.000 y 200.000 tickets históricos, un almacén de usuarios respaldado por Active Directory, y un puñado de integraciones de correo/LDAP. Si su SDP es la edición MSP, o está ejecutando la edición Enterprise con el módulo de CMDB muy poblado, parte del mapeo siguiente tendrá que ampliarse; la forma del trabajo sigue siendo la misma.

Por qué las organizaciones migran fuera de SDP

Antes de entrar en la mecánica, las razones, porque condicionan las decisiones de mapeo más adelante. En la práctica, los equipos que inician una migración de SDP a LinaDesk aterrizan en una o varias de las siguientes:

• KVKK y residencia de los datos. La edición en la nube de SDP se aloja en infraestructura de Zoho fuera de Turquía. Su edición on-premise está bien en ese aspecto, pero el modelo de licencia empuja a los clientes hacia la nube en la renovación. Las organizaciones turcas sujetas al artículo 9 de la KVKK (transferencia transfronteriza) prefieren un proveedor on-premise controlado desde Turquía como seguro frente a una migración forzada a la nube.
• Trayectoria de coste por técnico. El precio por técnico de SDP ha subido de forma constante desde 2022, y el precio modular (complementos de cambios, proyectos, CMDB) se acumula. Una alternativa de licencia fija elimina las sorpresas en el momento de renovar.
• Ergonomía de interfaz y atajos de teclado. La interfaz de SDP es anterior a las normas de diseño de la era Linear. Los equipos cuyos técnicos L1 viven en la cola todo el día lo notan a diario.
• Despliegues air-gap o en redes clasificadas. Los clientes gubernamentales y de defensa no pueden ejecutar los complementos en la nube de SDP; toda capacidad que necesiten debe correr dentro de su perímetro.

La razón importa porque dicta qué se traslada. Una migración impulsada por la KVKK típicamente preserva todo, porque los auditores preguntarán. Una migración impulsada por costes dejará atrás con gusto funcionalidades que nadie usa.

Fase 1 — Descubrimiento (2 semanas)

La fase de descubrimiento existe para evitar los dos peores resultados de una migración de ITSM: datos que faltan y que resultan importantes y datos migrados que resultan ser basura. Dos semanas parece mucho tiempo; no lo es.

Inventariar la instancia de SDP

Haga un inventario honesto. Desde la consola de administración de SDP, capture lo siguiente en una hoja de cálculo compartida:

• Número total de solicitudes, desglosado por estado (Abierta, En espera, Resuelta, Cerrada) y por año de creación.
• Todas las plantillas de solicitud en uso, incluidas las que nadie recuerda quién creó.
• Todos los campos personalizados, por módulo. Anote el tipo de campo, si es obligatorio y qué plantillas lo referencian.
• Todas las políticas de SLA, con sus definiciones de horario laboral, niveles de escalado y criterios de coincidencia.
• Todas las reglas de automatización (Business Rules, Field & Form Rules, Custom Triggers, Time Triggers).
• Todas las plantillas de correo y reglas de notificación.
• Todos los flujos de aprobación.
• Todos los roles, con sus mapeos de permisos.
• Cada integración: LDAP/AD, servidores de correo, SCCM/sondas, API de terceros.

El resultado no es un documento, es una lista de decisiones. Cada elemento se etiqueta como llevar, reconstruir o descartar. Una regla general: si menos de tres tickets en los últimos doce meses han usado una plantilla o campo personalizado, es candidato a descartarse.

Entrevistar al equipo de operaciones

El descubrimiento no es solo un paseo por la consola de administración. Siéntese con tres técnicos L1, un responsable L2 y el gestor del servicio de asistencia. Pregunte qué informes abren cada semana, qué macros usan y qué campos dejan en blanco habitualmente. Los paneles que nadie abre son los campos que nadie necesita.

Mapear las dependencias de integración

SDP suele ser el centro de sistemas adyacentes: una herramienta de monitorización publica alertas como tickets, un escáner de activos escribe registros de CI, una integración de nóminas dispara solicitudes de incorporación de RR. HH. Cada una de ellas debe redirigirse a la API de LinaDesk o pausarse durante el corte. Si se le escapa una, el lunes por la mañana trae una pila de tickets huérfanos.

Fase 2 — Mapeo de datos

El modelo de datos de SDP y el de LinaDesk son primos, no gemelos. La tabla siguiente es el mapeo que usamos como punto de partida; la personalización siempre añade filas.

Las filas que más tiempo de ingeniería requieren, en nuestra experiencia, son los campos personalizados, las categorías y las políticas de SLA. Todo lo demás es mecánico.

Fase 3 — Exportación

SDP tiene tres formas de extraer datos: las exportaciones programadas integradas, la API REST v3 y el acceso directo a la base de datos. Las tres tienen su lugar.

La API REST v3 para datos estructurados

La API es la fuente correcta para usuarios, técnicos, grupos, categorías, políticas de SLA y cualquier entidad que necesite con su conjunto completo de campos. Los endpoints son estables, respetan la paginación y devuelven JSON que se mapea limpiamente sobre nuestro esquema de destino.

Un script mínimo de PowerShell para extraer todas las solicitudes, página a página, a un directorio de blobs JSON:

# requiere una SDP TECHNICIAN_KEY con acceso de lectura
$sdpUri  = "https://sdp.internal/api/v3/requests"
$authKey = $env:SDP_TECHNICIAN_KEY
$outDir  = "C:\migration\raw\requests"
New-Item -ItemType Directory -Force -Path $outDir | Out-Null

$rowsPerPage = 100
$rowIndex    = 1

do {
  $inputData = @{
    list_info = @{
      row_count   = $rowsPerPage
      start_index = $rowIndex
      get_total_count = $true
      fields_required = @(
        "id","subject","description","status","priority",
        "created_time","resolved_time","closed_time",
        "requester","technician","group","category","subcategory","item",
        "udf_fields")
    }
  } | ConvertTo-Json -Depth 6 -Compress

  $resp = Invoke-RestMethod `
    -Uri "$sdpUri?input_data=$([uri]::EscapeDataString($inputData))" `
    -Headers @{ "authtoken" = $authKey } `
    -Method GET

  $resp.requests | ForEach-Object {
    $_ | ConvertTo-Json -Depth 12 |
      Out-File -Encoding utf8 "$outDir\req_$($_.id).json"
  }

  $total     = $resp.list_info.total_count
  $rowIndex += $rowsPerPage
} while ($rowIndex -le $total)

Los scripts equivalentes para usuarios, grupos y activos son copias estructurales. Manténgalos bajo control de versiones: los ejecutará al menos tres veces —una durante el ensayo en seco, otra durante el ensayo general, otra durante el corte.

Lectura directa de base de datos para adjuntos archivados

SDP almacena los adjuntos fuera del cuerpo de la solicitud. La API devuelve metadatos, no los blobs. Para los bytes en sí, o bien use el endpoint de adjuntos por registro (lento, pero respeta los permisos), o bien lea directamente de la tabla FileAttachment de SDP más el directorio Attachments en disco. En instancias grandes (100k+ tickets con adjuntos), la segunda es la única opción realista: planifique un rsync nocturno.

Fase 4 — Preservación del historial de tickets

El campo más importante de toda la migración es CreatedAtUtc. Si se establece silenciosamente en ahora, diez años de historial se comprimen en un solo día y todos los informes de SLA pierden sentido.

LinaDesk admite la creación de tickets con fecha retroactiva a través de su endpoint de importación masiva. La regla:

Cada ticket, comentario, transición de estado y entrada de auditoría lleva su marca de tiempo UTC original. Nada en la ruta de importación puede sobrescribirla.

En concreto: el created_time.value de SDP es una cadena en milisegundos Unix. Conviértala a UTC ISO-8601 y páselo como CreatedAtUtc. Haga lo mismo con resolved_time, closed_time, y la marca de tiempo de creación de cada nota individual. Si una nota tiene un updated_time distinto de su created_time, preserve ambos: los equipos de auditoría a veces los comprueban.

Una trampa sutil: las marcas de tiempo de SDP se almacenan en la zona horaria de la cuenta, pero la API las reporta en UTC solo si el usuario asociado a la clave de técnico tiene UTC como su zona horaria de visualización. Verifique esto una vez contra tres registros conocidos antes de confiar en toda la exportación.

Fase 5 — Remapeo de AD / LDAP

Los usuarios son casi siempre el join más difícil de la migración. SDP identifica internamente a un usuario por su REQUESTERID. Active Directory identifica a la misma persona por su objectGUID. LinaDesk usa ExternalId (que recomendamos establecer como el objectGUID de AD).

La migración no puede depender de ninguna clave primaria por sí sola. El join que usamos, en orden de prioridad:

1. UPN (userPrincipalName). Sobrevive a los cambios de nombre en AD y a los traslados entre bosques. Úselo como join primario.
2. Dirección de correo. Se usa como respaldo si falta el UPN.
3. sAMAccountName. Último recurso, porque no está garantizado que sea único entre bosques.

Cualquier usuario que falle en los tres joins va a un archivo orphans.csv. En todas las migraciones reales que hemos ejecutado, este archivo tiene entre 20 y 400 filas: personas que dejaron la empresa, cuentas de servicio que nunca se vincularon a AD, y solicitantes que enviaron un único ticket por correo en 2018. Decida su destino manualmente. No se salte este paso: esos huérfanos todavía son propietarios de tickets históricos, y sus nombres deben aparecer correctamente en los informes.

Fase 6 — Remapeo de políticas de SLA

El modelo de SLA de SDP es un motor de reglas plano: coincide por criterios de la solicitud, aplica ventanas de respuesta/resolución contra un calendario de horario laboral. El modelo de LinaDesk es cercano pero no idéntico:

• El Operational Hours de SDP ↔ el WorkCalendar de LinaDesk.
• Los Holidays de SDP ↔ el WorkCalendarHoliday de LinaDesk.
• Los criterios de SLA de SDP ↔ las condiciones SlaPolicyMatch de LinaDesk.
• Los niveles de escalado de SDP ↔ la cadena SlaEscalation de LinaDesk.

La única brecha significativa está en torno a las pausas parciales. SDP permite pausar el SLA cuando el ticket está Waiting for Requester. LinaDesk requiere modelar el mismo comportamiento como un array explícito PauseOnStatus en la política de SLA. Haga el mapeo en el script de migración en lugar de confiar en que los valores por defecto coincidan: todas las instancias de SDP que hemos revisado tenían al menos un estado de pausa que no era el predeterminado.

Para una discusión más extensa sobre la parte de calendario en el diseño de SLA, vea el artículo sobre diseño de calendarios de SLA; las decisiones de modelado allí se aplican directamente a cómo reconstruirá el calendario en LinaDesk.

Fase 7 — Portal, marca, plantillas de notificación

Estos elementos no se migran. Se reconstruyen.

El portal de autoservicio de SDP es una capa fuertemente plantillada con estilo Zoho. El de LinaDesk es una interfaz moderna basada en componentes con la misma superficie de funcionalidades pero una estructura distinta. Copie los activos visuales (logo, favicon, colores de marca) y el texto (mensaje de bienvenida, anuncios de la página de inicio, descripciones de categorías), y deje que un diseñador pase dos días reconstruyendo el portal en la interfaz de administración de LinaDesk.

Las plantillas de notificación siguen la misma historia. Extraiga cada plantilla de correo de SDP como HTML más una lista de variables, y luego reconstrúyalas en el editor de plantillas de LinaDesk. La sintaxis de variables de LinaDesk es del estilo {{Ticket.Number}}; la de SDP es $Request.RequestID. Traduzca la sintaxis de forma automática; revise el texto a mano.

Fase 8 — La ejecución en paralelo de cuatro semanas

Hacer el corte en un solo fin de semana es como lanzar una moneda al aire. Ejecutar SDP y LinaDesk en paralelo durante cuatro semanas no lo es: convierte el lanzamiento de moneda en un ejercicio de ingeniería.

Nuestra secuencia recomendada:

1. Semana -4: LinaDesk desplegado. Datos históricos importados. Todos los técnicos L1 tienen credenciales y han completado una sesión de formación de 90 minutos. El enrutamiento de correo sigue apuntando a SDP.
2. Semana -3: Reimportaciones nocturnas contra la API delta de SDP, manteniendo LinaDesk dentro de las 24 horas de SDP. Se pide a los técnicos que revisen diez tickets nuevos al día en LinaDesk y reporten fallos. El portal permanece apagado.
3. Semana -2: El quince por ciento del correo entrante se enruta a LinaDesk. Los técnicos gestionan ambas colas. Los informes se generan por duplicado y se comparan.
4. Semana -1: El cincuenta por ciento del correo entrante se enruta a LinaDesk. El portal en fase beta se abre a un pequeño grupo de solicitantes piloto. Cualquier discrepancia P0/P1 bloquea el corte.
5. Fin de semana del corte: Reimportación final del delta. El enrutamiento de correo se cambia al 100% a LinaDesk. El portal se abre a todos los solicitantes. SDP pasa a solo lectura; se mantiene en línea durante 90 días a efectos de auditoría.

El periodo de 90 días en solo lectura importa. Los reguladores (y la auditoría interna) a veces hacen preguntas que exigen ver cómo se veía un ticket en el sistema origen en una fecha concreta. Eliminar SDP el día después del corte es un error que hemos visto dos veces, y en ambas ocasiones terminó en una incómoda conversación sobre retención legal.

Lista de validación posterior a la migración

Antes de dar el visto bueno:

• Los recuentos de tickets coinciden: SDP.count(status=Closed, year=2024) equivale a LinaDesk.count(status=Closed, CreatedAtUtc between 2024-01-01 and 2024-12-31) con un margen de ±0,1%.
• Los solicitantes huérfanos están contabilizados: cada usuario en orphans.csv tiene un marcador de posición en LinaDesk o ha sido excluido explícitamente, y sus tickets históricos muestran un nombre de solicitante preservado en el cuerpo del ticket.
• Paridad de informes de SLA: extraiga el informe de cumplimiento de SLA del trimestre anterior de SDP y de LinaDesk; las cifras deberían coincidir con un margen de ±1%. Diferencias mayores indican una mala configuración de calendario o de estado de pausa.
• Integridad de adjuntos: muestree 200 tickets aleatorios de los últimos cinco años y verifique que cada adjunto se abre.
• Búsqueda de KB: busque los cinco artículos de la base de conocimiento más vistos en LinaDesk y confirme que aparecen entre los cinco primeros resultados.
• Integraciones: cada webhook redirigido, sincronización LDAP y llamada de API saliente se ha observado disparándose con éxito al menos dos veces.

Errores comunes

Funcionalidades que existen en SDP pero no en LinaDesk v1

La lista honesta. LinaDesk v1 no incluye:

• Un módulo de gestión de proyectos. El submódulo Projects de SDP lo usa aproximadamente el 15% de los clientes de SDP; si usted es uno de ellos, esto es una decisión de alcance, no una solución alternativa.
• Una capa de multitenencia multi-cuenta para MSP. LinaDesk es de un solo tenant por diseño: cada cliente ejecuta su propia instancia.
• Una app móvil nativa. La interfaz web de LinaDesk es responsiva para móvil, pero un shell nativo está en la hoja de ruta v1.2, no en v1.

Si alguno de estos elementos es crítico para su operación, resuélvalo en el descubrimiento, no la semana antes del corte.

Infravalorar el alcance de la migración de campos personalizados

Toda migración que hemos revisado tenía al menos un campo personalizado que estaba poblado en el 60% de los tickets históricos pero solo en el 3% de los tickets del último año. Alguien dejó de usarlo hace años y nadie lo eliminó. Migre de todas formas: los datos huérfanos siguen siendo datos visibles en auditoría.

Confiar en la interfaz de exportación por "rango de fechas" de SDP

La interfaz de exportación de SDP limita silenciosamente las filas a 5.000 en algunas versiones y a 10.000 en otras, y no hay ningún error, solo un CSV truncado. Use siempre la API para cualquier cosa por encima de unos pocos cientos de filas.

Lecturas relacionadas

• Por qué el ITSM on-premise vive su momento en 2026
• Diseñar calendarios de SLA que sobreviven a los cambios de turno y los días festivos
• LinaDesk frente a ServiceNow, ManageEngine, Freshservice — tabla comparativa
• Seguridad y cumplimiento de LinaDesk