Una migración de TI no comienza cuando se copian archivos o se cambia una configuración. Comienza cuando la empresa identifica qué procesos dependen del correo, los servidores, las aplicaciones, la nube, los equipos y las integraciones que planea mover. Sin esa revisión, un cambio técnicamente correcto puede dejar a ventas sin contactos, a administración sin reportes o a una sucursal sin acceso a su sistema.

Revisar el ambiente antes de migrar permite separar tres decisiones: qué debe trasladarse, qué conviene corregir antes del cambio y qué necesita permanecer disponible mientras se valida el destino. El objetivo no es documentar por documentar, sino reducir improvisación y establecer evidencia para autorizar, detener o revertir cada etapa.

Esta guía funciona como diagnóstico previo para migraciones de correo, nube, servidores o sistemas. Si el proyecto ya está enfocado en infraestructura, consulta también cómo planear una migración de servidores empresariales; aquí la prioridad es confirmar si la empresa está lista antes de fijar una fecha de cambio.

Respuesta directa: qué revisar antes de una migración de TI

Antes de migrar, la empresa debe validar objetivo, alcance, inventario, dependencias, calidad de datos, usuarios, permisos, compatibilidad, licencias, capacidad, conectividad, integraciones, respaldos, restauración, responsables, comunicación, piloto, reversión y criterios de aceptación. Cada punto necesita un propietario y una evidencia; una lista marcada sin prueba no confirma que la operación pueda continuar.

  • Objetivo empresarial, problema que se busca resolver y resultado aceptable.
  • Sistemas, datos, usuarios, equipos, sedes, proveedores e integraciones dentro del alcance.
  • Dependencias críticas y orden necesario para moverlas o habilitarlas.
  • Respaldo verificable, procedimiento de restauración y punto de reversión.
  • Compatibilidad, licenciamiento, capacidad, conectividad y seguridad del destino.
  • Responsables técnicos y de negocio, ventana, comunicación y soporte a usuarios.
  • Pruebas con procesos reales, evidencias y condiciones para aceptar o detener el cambio.

1. Define el problema y el alcance antes de elegir la solución

La migración debe responder a una necesidad concreta: renovar infraestructura, reducir una dependencia, cambiar de proveedor, habilitar trabajo remoto, consolidar información o corregir una plataforma que ya no acompaña el crecimiento. Cuando el objetivo es ambiguo, el proyecto tiende a medir éxito por archivos copiados en vez de por procesos recuperados.

El alcance debe indicar qué se incluye y qué queda fuera. No basta con escribir "migrar correo" o "mover el sistema". Conviene enumerar buzones, alias, calendarios, archivos, aplicaciones, bases de datos, reportes, equipos, sedes, históricos y servicios conectados. También se documentan restricciones: fechas contables, temporadas de venta, cierres, disponibilidad de proveedores y horarios en los que la operación no puede interrumpirse.

2. Construye un inventario conectado con procesos reales

Un inventario útil relaciona cada recurso técnico con un proceso y un responsable. Un servidor puede alojar archivos, pero también una aplicación, una tarea programada y una licencia ligada a su nombre. Un dominio puede sostener correo, sitio web, validaciones y accesos de terceros. Si se registra sólo el equipo principal, las dependencias menos visibles aparecen durante el corte.

  • Proceso de negocio, área responsable y usuarios que lo ejecutan.
  • Aplicaciones, bases, carpetas, cuentas, dispositivos y servicios que necesita.
  • Propietario del dominio, licencias, suscripciones y relación con proveedores.
  • Versiones, configuraciones, certificados, tareas programadas y rutas compartidas.
  • Orden de arranque, conexiones entre sistemas y alternativa temporal disponible.
  • Persona que validará el proceso con una operación real después del cambio.

Las cuentas, contratos o consolas administradas únicamente por un excolaborador o por un proveedor sin contacto vigente deben regularizarse antes. Migrar sin control de propiedad puede dejar a la empresa dependiente de credenciales, autorizaciones o renovaciones que no puede gestionar.

3. Clasifica los datos antes de moverlos

Mover todo sin revisar puede trasladar duplicados, carpetas personales, versiones contradictorias y archivos que ya no tienen responsable. Antes de copiar, clasifica información operativa, histórica, sensible y prescindible de acuerdo con las políticas de la empresa. La depuración no debe hacerse de forma masiva sin autorización; necesita criterios, responsables y un respaldo previo cuando corresponda.

También conviene medir volumen, crecimiento y frecuencia de cambio. Estos datos influyen en el tiempo de transferencia, la capacidad del destino, el costo, la ventana y la cantidad de información que podría cambiar entre la primera copia y el corte final. Para bases de datos y sistemas administrativos, la revisión debe incluir catálogos, adjuntos, reportes y consistencia funcional, no únicamente el tamaño del archivo.

4. Revisa usuarios, permisos y métodos de acceso

Una migración es una oportunidad para corregir cuentas inactivas, permisos acumulados y contraseñas compartidas, pero no conviene cambiar todo sin coordinación. Registra quién necesita acceso, desde qué dispositivo o ubicación, con qué nivel de permiso y quién lo autoriza. Incluye cuentas administrativas, técnicas, compartidas, externas y de recuperación.

Los accesos deben probarse con identidades reales y perfiles distintos. Para preparar esta parte, utiliza la guía para auditar accesos empresariales y documenta métodos de recuperación que no dependan de una sola persona.

5. Confirma compatibilidad, licencias, capacidad y conectividad

El destino debe responder a las condiciones reales de uso. Revisa versiones de sistemas operativos, navegadores, complementos, controladores, impresoras, dispositivos, formatos y requisitos del proveedor. Una aplicación antigua puede abrir en una prueba básica y fallar al imprimir, exportar o conectarse con otro componente.

Las licencias requieren atención separada: modalidad, usuarios, dispositivos, vigencia, posibilidad de transferencia y soporte. También deben validarse almacenamiento, memoria, procesamiento, crecimiento, ancho de banda, latencia y conexiones simultáneas. En sedes o trabajo remoto, una migración a nube puede depender más de la calidad del enlace y de los equipos que de la plataforma contratada.

6. Documenta integraciones y automatizaciones poco visibles

Las integraciones suelen concentrar riesgos porque operan sin intervención diaria. Un sistema puede enviar correo desde una cuenta específica, leer archivos de una carpeta, consultar una base, usar una dirección IP autorizada o generar reportes mediante una tarea programada. Si nadie registra esa conexión, puede descubrirse sólo cuando deja de funcionar.

  • Envío y recepción de correo desde aplicaciones, sitios web o dispositivos.
  • Carpetas compartidas, unidades de red, exportaciones e importaciones automáticas.
  • APIs, bancos, facturación, punto de venta, mensajería y sistemas de clientes.
  • Certificados, dominios, DNS, listas permitidas, VPN y reglas de firewall.
  • Tareas programadas, alertas, reportes, respaldos y cuentas de servicio.
  • Impresoras, escáneres, lectores y otros periféricos ligados al flujo.

Cuando una integración no pueda migrarse al mismo tiempo, debe existir una alternativa temporal, un responsable y una fecha para cerrar la excepción. Mantener dos ambientes sin reglas claras puede generar información dividida y confusión sobre cuál es la fuente vigente.

7. Prepara respaldo, restauración y reversión

Un respaldo previo sólo es útil si incluye el alcance necesario, puede restaurarse y permanece accesible aunque falle el entorno que se está migrando. Define el momento de la copia, las versiones que se conservarán, quién puede recuperarlas y cuánto tiempo permanecerá disponible el origen durante la validación.

La reversión no es igual al respaldo. El respaldo conserva información; el plan de reversión explica cómo volver a una condición operativa y qué ocurrirá con los cambios realizados durante la ventana. Antes de autorizar el corte, confirma una política de respaldo de servidores o el mecanismo equivalente para el servicio involucrado.

8. Asigna responsables, comunicación y soporte

Cada actividad necesita un responsable técnico y cada proceso crítico necesita una persona de negocio que valide. También debe quedar claro quién decide continuar, detener o revertir; quién comunica a los usuarios; y dónde se registrarán incidencias. Sin esta estructura, las decisiones se retrasan justo cuando el tiempo es más importante.

La comunicación debe explicar qué cambiará, qué no cambiará, cuándo ocurrirá, qué debe hacer cada usuario y cómo pedir ayuda. Si habrá nuevas contraseñas, accesos, aplicaciones o pasos de autenticación, conviene preparar instrucciones breves y soporte reforzado durante la estabilización.

9. Ejecuta un piloto y define criterios de aceptación

Un piloto representativo permite probar cuentas, volúmenes, permisos, dispositivos y procesos antes de extender el cambio. Debe incluir usuarios con necesidades distintas, no sólo al equipo técnico. La prueba puede revelar macros, formatos, buzones, rutas, impresoras o integraciones que no aparecieron en el inventario.

Los criterios de aceptación convierten la validación en evidencia. En vez de declarar que el sistema "ya funciona", se comprueba que un usuario autorizado puede iniciar sesión, consultar información, capturar un movimiento, generar un reporte, enviar una notificación y recuperar un archivo. El detalle depende de cada proyecto, pero debe acordarse antes del corte.

Caso práctico común: correo, archivos y sistema administrativo

Una empresa planea cambiar su correo y trasladar archivos compartidos durante el mismo fin de semana. El inventario inicial registra buzones y carpetas, pero la revisión descubre que el sistema administrativo envía estados de cuenta mediante una cuenta técnica, una sucursal utiliza una unidad mapeada y dos usuarios conservan archivos críticos sólo en sus equipos.

Antes de fijar el corte, el equipo agrega esas dependencias, regulariza la cuenta técnica, incorpora los archivos locales autorizados al respaldo y prueba el acceso desde la sucursal. Después ejecuta un piloto con ventas y administración, documenta qué debe validarse y define que el ambiente anterior se conservará sin cambios durante el periodo acordado.

La revisión no elimina todo riesgo ni promete una transición sin incidentes. Sí evita que dependencias conocidas queden fuera y permite responder con orden si una prueba crítica falla.

Señales de alerta antes de autorizar la migración

  • El alcance se describe con una frase y nadie puede enumerar procesos o dependencias.
  • No existe inventario actualizado de usuarios, datos, aplicaciones, licencias o proveedores.
  • La única copia de seguridad comparte ubicación, credenciales o falla con el origen.
  • Nadie ha probado una restauración ni puede explicar el plan de reversión.
  • La fecha se eligió sin considerar cierres, ventas, sucursales o disponibilidad de las áreas.
  • El destino no se probó con el volumen, la conectividad, los dispositivos o los permisos reales.
  • No hay responsables para validar procesos ni criterios escritos para aceptar el cambio.
  • Se pretende retirar el ambiente anterior inmediatamente después de copiar la información.

Qué debe quedar listo antes del cambio

  • Alcance aprobado, exclusiones y objetivo empresarial de la migración.
  • Inventario de procesos, recursos, datos, usuarios, propietarios e integraciones.
  • Matriz de dependencias, criticidad y orden de habilitación.
  • Respaldo verificable, restauración probada y plan de reversión.
  • Resultado del piloto, pendientes, riesgos aceptados y responsables.
  • Plan de corte, comunicación, soporte y estabilización posterior.
  • Casos de prueba y evidencia que se utilizará para aceptar la migración.

No todos los proyectos requieren un documento extenso. Sí requieren que esta información sea suficiente para que las personas involucradas sepan qué se moverá, cómo se validará y qué decisión tomar si una condición crítica no se cumple.

Cómo ayuda SOATI

SOATI puede apoyar a revisar el ambiente actual, relacionar tecnología con procesos, identificar dependencias, definir etapas y preparar una migración acorde con la operación de la empresa. El alcance puede abarcar diagnóstico, planeación, implementación, validación y soporte posterior, según las plataformas y responsabilidades acordadas.

  • Diagnóstico de infraestructura, servicios, usuarios, datos y dependencias.
  • Priorización por criticidad, impacto operativo y ventanas disponibles.
  • Revisión de respaldos, recuperación, reversión y continuidad.
  • Coordinación de proveedores, responsables internos y comunicación a usuarios.
  • Piloto, plan de corte, pruebas funcionales y seguimiento de estabilización.
  • Integración con consultoría, nube, soporte y servicios administrados cuando aplique.

La cobertura, tecnologías compatibles, licencias, tiempos, responsabilidades, soporte y condiciones de reversión deben confirmarse antes de comprometer una fecha o resultado específico. La consultoría tecnológica organiza decisiones y riesgos; no sustituye la validación de las áreas responsables de la información y de los procesos.

Si tu empresa planea cambiar correo, nube, servidores o un sistema crítico, reúne el inventario disponible y solicita un diagnóstico de consultoría TI para pymes. El primer resultado debe ser una decisión informada sobre alcance, prioridades y condiciones para migrar.