Ideas clave
- Inventaríe complementos, consultas personalizadas e integraciones antes de elegir una fecha.
- Ensaye la migración sobre una copia de producción, al menos dos veces.
- Planifique pruebas de rendimiento y capacitación, no solo la conversión de datos.
- Escriba un plan de reversa y acuerde quién puede activarlo.
Por qué esta migración merece su propio plan
Cuando una empresa opera SAP Business One sobre una base de datos tradicional y considera pasar a la edición HANA, la conversación suele comenzar como una cuestión de infraestructura. En la práctica, el cambio de base de datos afecta consultas, complementos, integraciones, reportes, respaldos y la experiencia de los usuarios. Los equipos que lo tratan como un simple traslado son los que descubren sorpresas durante el fin de semana de corte.
Esta lista está escrita desde la perspectiva del riesgo. No reemplaza la documentación del fabricante ni una evaluación formal, pero le ayuda a hacer las preguntas correctas desde temprano.
Riesgo 1: lo que no sabía que tenía
Con los años, las instalaciones de Business One acumulan consultas personalizadas, campos definidos por el usuario, búsquedas formateadas, reportes en Crystal, tareas programadas y pequeños scripts escritos por personas que quizá ya no están. Cualquiera de ellos puede comportarse distinto en una base de datos nueva, sobre todo si el SQL se escribió con supuestos de la anterior.
- Liste cada consulta personalizada, reporte, procedimiento almacenado y tarea programada, con un responsable para cada uno.
- Identifique los complementos y confirme con cada proveedor que existe una versión compatible con la plataforma de destino.
- Documente las integraciones, incluidas tiendas en línea, archivos bancarios, EDI y extracciones para BI, y cómo se conecta cada una.
Riesgo 2: brechas de versión y compatibilidad
La compatibilidad depende de su versión actual de Business One, de la versión de destino y de cada componente alrededor. Verifique las rutas de actualización admitidas y la secuencia requerida, ya que algunas rutas exigen un paso intermedio. Confirme temprano las versiones del cliente, el sistema operativo y los requisitos de infraestructura, porque los plazos de hardware y licenciamiento pueden dominar el cronograma.
Riesgo 3: sorpresas en la conversión de datos
Los datos antiguos tienen rarezas: códigos inconsistentes, registros huérfanos, caracteres inusuales y entradas de prueba olvidadas. Una conversión las deja al descubierto. Ejecute controles de calidad antes de migrar y decida qué limpiar, qué archivar y qué dejar. Concilie los totales después de cada ensayo, por ejemplo el balance de comprobación, las cuentas por cobrar y por pagar abiertas y el valor del inventario por almacén, para demostrar que nada cambió con el traslado.
Riesgo 4: el rendimiento no mejora automáticamente
Una nueva plataforma de base de datos puede acelerar algunas cargas, pero las consultas mal escritas y los reportes personalizados pesados no se arreglan solos. Pruebe las operaciones más importantes para su negocio, como el cierre de mes, los reportes grandes, las actualizaciones masivas de precios y el ingreso de pedidos en horas pico, con volúmenes de datos realistas. Compare con el sistema actual y registre los resultados.
Riesgo 5: personas y procesos
Aunque las pantallas se vean iguales, algunos comportamientos y reportes pueden diferir. Planifique sesiones breves de capacitación, publique una lista de diferencias conocidas y disponga de un canal de soporte durante las primeras semanas. Elija la fecha de corte lejos del cierre de mes, del cierre de año y de sus picos comerciales.
Ensaye y luego decida si se sigue o no
- Migre una copia de producción y ejecute los controles de conciliación.
- Pida a los usuarios clave que prueben su trabajo diario y sus reportes con un guion escrito.
- Corrija los problemas, repita el ensayo y cronometre cada paso para que la ventana de corte sea realista.
- Realice una revisión de aprobación con criterios definidos, no con una sensación general de preparación.
Por último, escriba el plan de reversa. Debe indicar exactamente cómo volver al sistema anterior, cuánto tarda, qué datos ingresados después del corte se perderían o tendrían que recapturarse y quién tiene la autoridad para activarlo. Los respaldos que nunca se han restaurado son solo una esperanza, así que pruebe una restauración.
