Puesta en marcha y adopción
Migración y limpieza de datos
Qué historial se traslada a Gfacility, qué se descarta y qué se archiva, y cómo validas que todo llega correctamente. Si te saltas la limpieza, traes el desorden viejo a la casa nueva.
Actualizado el 18 may 2026
Go-live · 5.1
Por qué esto primero
Migración y limpieza son inseparables. “Migrar todo” suena seguro, hasta que arrancas Gfacility con 14.000 tickets de 2017 cuyo estado nadie entiende ya. Importar datos malos hace que cada informe pierda credibilidad y cada sugerencia de IA sea inservible. Primero limpia, después migra.
¿Qué entregas?
Matriz de migración
Por entidad origen: entidad destino, reglas de transformación, fecha de referencia, alcance.
Lista de acciones de limpieza
Duplicados, registros obsoletos, referencias rotas, ¿quién limpia qué antes de migrar?
Estrategia de archivo
Qué no se migra y cómo sigue recuperable bajo las obligaciones de retención.
Informe del dry run
Resultado de al menos dos ejecuciones de dry run: recuentos, discrepancias y tiempo.
Las cinco familias de entidades
La migración sigue siempre los mismos pasos, sea cual sea el sistema origen:
Datos maestros
Usuarios, organizaciones, ubicaciones, centros de coste. Primero, porque todas las demás entidades los referencian.
Configuración
Clasificaciones, campos personalizados, grupos de trabajo, flujos. Manual o vía export, normalmente poco volumen.
Datos transaccionales
Tickets abiertos, reservas actuales, tareas planificadas. Poco volumen, mucho valor, tráelo todo.
Histórico
Tickets cerrados, reservas antiguas. Decide qué periodo (12 o 24 meses) y cómo preservas tu línea de informes.
Base de conocimiento
Artículos, FAQ, plantillas. A menudo es la oportunidad de limpiar y reestructurar.
Adjuntos
Fotos, PDF, documentos enlazados a tickets y activos. Suele ser lo más pesado en volumen.
Preguntas clave
- 1¿Qué sistemas origen contienen datos que deben ir a Gfacility: TOPdesk, ServiceNow, listas Excel, herramientas internas, recursos de Outlook?
- 2Límites del alcance por entidad, ¿solo registros activos, solo últimos 24 meses, solo ciertos departamentos?
- 3Limpieza previa, ¿quién elimina duplicados, desactiva usuarios inactivos y cierra tickets "huérfanos" sin responsable?
- 4Reglas de transformación, ¿cómo mapeas las categorías antiguas a las nuevas? ¿Qué hace "desconocido"?
- 5Estrategia de adjuntos, ¿migrar con todo, almacenamiento separado o recuperar bajo demanda desde archivo?
- 6Fecha de referencia y freeze, ¿cuándo se "congela" el origen (sin más cambios) y qué haces con los registros nuevos que lleguen entre medias?
- 7Validación, ¿qué comprobaciones haces tras la migración (totales, muestras, registros estrella revisados a mano)?
- 8Solución de archivo, para los datos que no migran, ¿la herramienta antigua se queda en solo lectura? ¿Con qué retención, responsable y modelo de acceso?
- 9Repetibilidad, ¿puedes hacer dry run de la migración al menos dos veces antes del cutover? ¿Idempotente (reejecutar no cambia nada)?
- 10Impacto RGPD, ¿llevas datos personales con retención vencida? El DPO debe validarlo antes de la migración.
Plantilla — Matriz de migración por entidad
| Entidad | Origen | Volumen | Alcance | Acción de limpieza | Responsable | Validación |
|---|---|---|---|---|---|---|
| Usuarios | Entra ID | ~2.400 | Activos (login 90d) | Desactivar inactivos | IT-Identity | Total +/- 1% |
| Ubicaciones | Excel + M365 Rooms | ~180 | Todas reservables | Revalidación de aforo | FM | Control manual 100% |
| Tickets abiertos | TOPdesk | ~340 | Todos abiertos | Cerrar > 6m | Service Manager | Muestra de 50 |
| Tickets cerrados | TOPdesk | ~14.200 | Últimos 24m | Redacción PII > 12m | Service Manager + DPO | Totales mensuales |
| Histórico reservas | M365 | ~85.000 | Últimos 12m | Ninguna, solo lectura | Lead workplace | Agregados |
| Artículos KB | Wiki SharePoint | ~220 | Top-150 más leídos | Reescribir + etiquetar | Service Manager | Revisión de contenido |
| … | … | … | … | … | … | … |
Pasos
- 1Inventaría los sistemas origen y asigna un responsable por entidad.
- 2Ejecuta sprints de limpieza, duplicados, cuentas inactivas, datos más antiguos que la retención. Mejor en el origen que durante la migración.
- 3Escribe el mapeo de transformación: campo origen → campo Gfacility, con reglas explícitas para "desconocido" y "vacío".
- 4Primer dry run sobre el entorno de aceptación, con volumen esperado, solo para medir recuentos, tiempos y errores.
- 5Corrige errores, ajusta el mapeo y devuelve acciones de limpieza al origen.
- 6Segundo dry run con estado de limpieza representativo, los usuarios finales revisan una muestra.
- 7Acuerda la estrategia de archivo, el origen queda en solo lectura 12 meses y luego se exporta a almacenamiento frío.
- 8Entrega el informe go/no-go al comité de dirección: recuentos cuadran, errores < X, firma de los responsables de entidad.