Radiografía del sistema
Tablas, procedimientos, informes, tareas programadas, conexiones con otros programas y usuarios. Muchas dependencias no están documentadas y solo aparecen al preguntar a cada departamento.
Un almacén frigorífico de Murcia gestiona entradas, lotes y trazabilidad con un programa hecho a medida en 2006 sobre Access y SQL Server 2008. El servidor tiene un Windows que no recibe parches desde hace años, el programador original se jubiló y la aseguradora ha empezado a hacer preguntas sobre ciberseguridad. El programa funciona, pero nadie se atreve a tocarlo. Migrar este tipo de sistemas no consiste en copiar una base de datos: hay que saber qué informes, integraciones y tareas nocturnas dependen de ella, convertir datos con formatos de hace dos décadas, ensayar el cambio completo y tener lista una marcha atrás. Todo se hace en remoto, y el cambio definitivo se programa en la ventana en la que su negocio puede permitirse parar.
La mayor parte del trabajo ocurre antes del día del cambio. Si la preparación es buena, el cambio es aburrido, y eso es lo que buscamos.
Tablas, procedimientos, informes, tareas programadas, conexiones con otros programas y usuarios. Muchas dependencias no están documentadas y solo aparecen al preguntar a cada departamento.
Versión actual del mismo motor, cambio a PostgreSQL, servidor gestionado o nube en la región de AWS en Aragón, Azure Spain Central o Google Cloud en Madrid, según coste, requisitos y conocimientos de su equipo.
Fechas en formatos antiguos, importes guardados como texto y, muy a menudo, la eñe y las tildes estropeadas al pasar de codificaciones antiguas a UTF-8. Se detecta y corrige en los ensayos.
Migraciones completas sobre copias de la base en un entorno de pruebas. Cada ensayo mide tiempos y deja una lista de ajustes para el siguiente.
Pasos concretos para volver al sistema anterior si algo grave falla en las primeras horas, con el punto a partir del cual ya no tiene sentido volver.
Comparación de recuentos, sumas y muestras de datos críticos: saldos de clientes, cobros pendientes, lotes y existencias.
Los plazos de preparación dependen del volumen y de las dependencias. El número de horas de parada lo da el segundo ensayo, no una estimación previa.
Inventario técnico, entrevistas con usuarios clave y definición de la parada aceptable. Si el almacén trabaja los sábados, el plan es otro.
Al menos dos migraciones completas sobre copias, con tiempos medidos y scripts corregidos después de cada una.
Ejecución del guion ensayado en la ventana acordada, con una persona de contacto conectada todo el tiempo y comunicación con usted en cada punto de decisión.
Vigilancia reforzada, resolución rápida de incidencias y el sistema antiguo disponible en modo consulta para comparar.
El sistema antiguo no se apaga al día siguiente. Manténgalo en modo lectura durante unas semanas, porque casi siempre aparece algún dato que no se migró como se esperaba. Tenga en cuenta además que el Código de Comercio obliga a conservar libros y documentos contables durante seis años, y que si los datos personales cambian de proveedor o de país debe actualizar su registro de actividades de tratamiento.
Lo sabremos con precisión después del segundo ensayo, que mide los tiempos con sus volúmenes reales. Lo habitual es programar el cambio entre el viernes por la tarde y el domingo, y antes de fijar la fecha le enviamos el plan hora a hora.
En algunos sistemas sí, replicando los datos de forma continua y haciendo un cambio final de minutos. Es más cara y compleja, y tiene sentido cuando cada hora de parada supone pérdidas importantes, como en una plataforma de reservas. La mayoría de empresas no la necesita.
Para migrar los datos, casi siempre: trabajamos directamente con la base de datos y reconstruimos las reglas hablando con los usuarios. Si quería seguir ampliando el programa antiguo, es otra cuestión, y su abogado debería aclarar qué derechos tiene sobre él. A menudo resulta más sensato escribir los módulos nuevos desde cero.
Sí. Si su sistema trata información de un organismo público, el proveedor de nube y el servicio deben cumplir el Esquema Nacional de Seguridad en la categoría que corresponda. Lo incluimos como requisito al elegir el destino, junto con la ubicación de los datos en España o en la UE.
Con una nota breve de cambios visibles, una sesión por videollamada para cada equipo afectado y soporte reforzado los primeros días. El primer lunes siempre hay dudas; lo importante es que tengan a quién preguntar.
Cuéntenos qué sistema quiere migrar, qué tamaño tiene la base de datos y cuánta parada puede asumir. Empezaremos por un diagnóstico y un primer ensayo.
Hemos recibido su solicitud
Tendrá respuesta en un día laborable. Si nos avisa de una avería que tiene parado a su equipo, la tratamos con prioridad.
No encontramos esa ciudad. Revise cómo está escrita o elija la capital de provincia más cercana: como trabajamos en remoto, el servicio es el mismo en cualquier punto de España.