Reimplantación NAV 2017
→ Business Central SaaS
Vitro operaba sobre Microsoft Dynamics NAV 2017 con un volumen elevado de desarrollos a medida acumulados a lo largo de los años. El sistema arrastraba personalizaciones obsoletas, funcionalidades mal definidas que necesitaban reformulación y código legacy que impedía evolucionar sobre la plataforma.
El objetivo no era una migración técnica al uso, sino una reimplantación completa: analizar qué desarrollos debían sobrevivir, limpiar la deuda técnica y rediseñarlos bajo los estándares de extensión de Business Central. Tras ese análisis — realizado por mi responsable — quedaron 244 desarrollos a documentar, redefinir y reimplementar.
Microsoft ofrece el Cloud Migration Tool para mover datos de NAV a Business Central Online. El proceso funciona bien en instalaciones estándar, pero tiene una limitación crítica: solo migra tablas y campos que existen en ambos sistemas con el mismo esquema.
En una instalación con 244 desarrollos, hay cientos de tablas y campos a medida. Cuando esos campos desaparecen, se renombran o cambian de tipo en BC, el proceso de migración estándar falla o simplemente omite esos datos. Además, la reimplantación implicaba no migrar información obsoleta, lo que requería un control preciso sobre qué datos pasaban y cuáles no.
Los configuration packages de BC son una herramienta de RapidStart Services que permite definir exactamente qué tablas y campos se migran, con filtros por empresa. La idea: configurar en BC qué quieres migrar, exportar ese paquete a NAV, poblar los datos, e importarlos de vuelta. El problema es que hacerlo manualmente para cientos de entidades es inviable y propenso a errores.
El equipo desarrolló una API en ASP.NET Core que automatiza completamente el proceso. La solución se construyó sobre el patrón repositorio que yo había diseñado para otro proyecto, y que un compañero tomó como base para arrancar este. Posteriormente me hice cargo del desarrollo y lo llevé hasta su finalización. El equipo configura en BC los paquetes que quiere migrar — qué tablas, qué campos, qué filtros — y lanza el proceso enviando el nombre del paquete. La API hace el resto.
Para entidades con esquemas especiales — como las dimensiones, que en BC tienen una estructura de árbol diferente a NAV — se implementó un patrón estrategia que permite ejecutar lógica de migración específica sin tocar el flujo general.
Los casos donde Microsoft tenía bugs con tipos de dato decimal se resolvieron con scripts SQL de extracción directa combinados con XMLPorts en BC, manteniendo la trazabilidad del proceso.
| Capa | Tecnología / patrón | Rol |
|---|---|---|
| API | ASP.NET Core 5 |
Orquestador del proceso de migración. Un único endpoint
POST /Synchronize lanza el flujo completo.
|
| Persistencia BC | OData v4 · OAuth2 (client credentials) | Lectura de paquetes configurados e importación de datos en Business Central Online. |
| Conexión NAV | SOAP / WCF (web service NAV) | Creación del paquete en NAV con tablas, campos y filtros. Exportación de datos. |
| Datos |
Patrón repositorio genérico
(IRepository<T>)
|
Abstracción de acceso a datos reutilizable en toda la solución. |
| Entidades especiales | Strategy pattern (IMigration) |
Desacopla la lógica específica por entidad (ej. dimensiones) del flujo general. |
| Multi-empresa | Configuración por empresa | Soporte nativo para múltiples empresas en el mismo proceso. |
| Fallback | SQL Server + XMLPorts | Extracción directa y carga vía XMLPort para campos con incompatibilidades de tipo conocidas en Microsoft. Proceso seguido y aplicado en coordinación con el equipo. |
Como BC Developer en el equipo, mi trabajo abarcó tanto los desarrollos AL como el proyecto de migración automática. Diseñé el patrón repositorio que sirvió de base para la API, me hice cargo del desarrollo cuando fue necesario y lo llevé hasta su finalización, resolviendo los problemas técnicos que fueron surgiendo en el camino.
Tras 9 meses de proyecto, la migración de datos se ejecutó en 1 semana de forma completamente automática. El equipo configuró los paquetes, lanzó el proceso y BC recibió los datos limpios y estructurados sin intervención manual.
El go-live fue sin incidencias críticas. Los únicos problemas reportados post-migración fueron de formación o de impacto bajo, sin errores de datos ni de integridad. La deuda técnica acumulada durante años quedó saldada: 244 desarrollos auditados, redefinidos y reimplementados bajo los estándares de extensión de Business Central.