Terminábamos la primera parte de este post sobre la reducción de costes a la hora de actualizar Microsoft Dynamics NAV hablando de los informes propietarios y los personalizados. Pues bien, en esta segunda y última parte vamos a centrarnos en los puertos de datos, los propios saltos de versión y los tamaños de base de datos, una de las dudas principales a la hora de dimensionar la infraestructura necesaria.
Factores a tener en cuenta al actualizar Microsoft Dynamics NAV
Puertos de datos - Dataports
Los puertos de datos se utilizaron en versiones anteriores a la de NAV 2009 R2 con la finalidad de importar o exportar datos. Pero ya en NAV 2013 los puertos de datos fueron reemplazados por los XMLport, un tipo de objeto diferente. Por lo tanto, el actualizar Microsoft Dynamics NAV a cualquier versión posterior a 2013 (incluida ésta) nos fuerza a reprogramar cualquier dataport que esté utilizando nuestra versión actual como XMLport.
Debido a que estos dataports a menudo se utilizan como medida temporal (por ejemplo en la adición de datos a un nuevo campo de una tabla, o la configuración de una nueva aplicación), lo más probable es que no los necesitemos todos. Por lo tanto, del mismo modo que hemos actuado con los informes, a la hora de realizar la actualización de versión NAV debemos contrastar con los usuarios y determinar con la mayor exactitud posible los que están siendo realmente utilizados. Y posteriormente debemos analizar, en las nuevas funcionalidades de NAV, si los puertos actuales pueden ser sustituidos por éstas.
Entre las funcionalidades que nos trae NAV podemos exportar un diario a Excel, modificar los datos e importarlo de nuevo en el diario. Y tan sólo este ejercicio puede eliminar la necesidad de un dataport/XMLPort.
Saltos de versión
Como es de esperar, la antigüedad y el tamaño de la propia base de datos tiene una repercusión muy significativa en el coste al actualizar Microsoft Dynamics NAV. Cuanto mayor sea la base de datos, mayor será el coste. Y la razón de esto es, simple y llanamente, que añade pasos al proceso de actualización. En algunas versiones incluso requiere de "saltos" para llegar a una nueva versión, ya que requiere un conjunto de herramientas de migración separada. Aquí están las versiones actuales de dichos “saltos”:
- Versiones anteriores a la 2.6
- Versión 2.6 a la versión 3.0
- Versión 3.6
- Versión 3.7 a la versión 4.3
- Versión 5.0 través de la versión 2009 R2
- Versión 2015
- Versión 2016
Pongamos que nuestra base de datos actual es la de la versión 5.0. Si vamos a actualizar esta base de datos a NAV 2016, tendríamos que, primeramente, transformarla a la versión NAV 2009 R2, a continuación, a la versión NAV 2015 y, finalmente, a la NAV 2016. Es decir, tres saltos de versión. Y para más inri cada uno de los saltos es diferente, en cuanto a complejidad se refiere, a los otros. ¿Cuáles son las principales diferencias a tener en cuenta? Principalmente diferencias de estructura de datos tales como la eliminación de los campos obsoletos o la adición de nuevos campos.
Por poner un ejemplo concreto, hace ya unos cuantos años, los campos bloqueados en las tarjetas de clientes y proveedores solían ser sólo una casilla de verificación tipo Boole (verdadero o falso). Pero posteriormente se decidió que éstos debían ser campos de opciones que pudieran definir aún más el estado de bloqueo. En el salto de versión deben ser convertidos a uno de los campos de opciones, por lo general la opción "ALL". A veces, una tabla se elimina de los objetos estándar NAV y los datos se combinan en una tabla existente. Todas las tablas de productos ISV también tienen que ser fusionadas en cada nivel de salto.
Ésta es una de las principales razones por las que urgimos/recomendamos/solicitamos a nuestros clientes mantenerse al día con las actualizaciones. Y no conviene olvidar que una señal clave para actualizar Microsoft Dynamics NAV es el hecho de que se deje de dar soporte a la versión instalada.
Dimensionamiento de la base de datos
Hay una gran diferencia en el tiempo que se necesita para actualizar una base de datos de 20 GB y una base de datos de 400 GB. Y el tiempo es un clave, ya que el proceso de entrada en funcionamiento se debe realizar en los días fuera de producción, sin el uso de la parte NAV de negocio. Es por ello que los implantadores tratamos de hacer el paso a “live” en un fin de semana, o en el momento más conveniente. Pero hay veces en las que se da el caso de que la base de datos es demasiado grande para migrar a la nueva versión, pasando por todos los saltos, en un solo fin de semana. Y cuando eso sucede, tenemos un par de ases en la manga, pero se necesita realizar pruebas y seguimiento de métricas para determinar la opción más adecuada, y se incurre en costes.
¿Qué se puede hacer para reducir el tamaño de la base de datos? En primer lugar, hablar con nuestro equipo de ventas. Si estamos evitando una personalización importante de la base de datos, se descartarán los datos relativos esa personalización. Es una consideración muy importante ya que una gran cantidad de datos del antiguo dimensionamiento serán dados de baja a medida que se vaya implementando la nueva funcionalidad introducida correspondiente a NAV 2013. Y se pueden realizar tanto compresiones de datos o filtrados por fecha para reducir el tamaño.
Y no olvidemos que nuestra empresa podría ser una de esas que, simplemente, podría desembarazarse de un montón de datos antiguos y engorrosos que sólo sirven para incrementar los costes de espacio en nuestra infraestructura. Una reimplementación, donde actualicemos a la nueva versión del software con las mismas tablas maestras (clientes, artículos, proveedores, etc.) pero sin datos transaccionales puede ser lo más adecuado. Y la versión antigua puede permanecer simplemente como herramienta de consulta, que poco a poco irá dejando de serlo (mucho más rápido de lo que nos parece siempre).
¿En qué punto se encuentra su organización?
Contacte con nosotros sin compromiso y juntos avanzaremos al ritmo que precise su negocio.
