Migraciones de Dynamics NAV a Business Central

Mejores Prácticas para la Migración de Dynamics NAV a Business Central

Este fue el título de la conferencia en la que tuve el placer de estar como Speaker, junto a grandes del mundo Navision de la talla de Miguel LLorca, Reyes Palma, Javier Armesto, Gerardo Rentería o  Jose Angel Lopez, en el Maratón Virtual de Soluciones de Negocio Microsoft.

La mayor parte de los temas de los que hablamos son dudas comunes que le surgen a todos los usuarios cuando se plantean pasar su Navision a la nube.

Lo primero que tenemos que pensar es que la alternativa no es muy buena:  Seguir manteniendo nuestros sistemas como están, hasta que se queden obsoletos como lamentablemente en muchos casos ha ocurrido, debido en gran parte a ese Navision Frankestein tan personalizado que es imposible de actualizar, bien por su coste o bien por su falta de documentación sobre los desarrollos realizados

Microsoft apuesta por la nube, la integración con la Power Platform y con otras herramientas Dynamics 365. Y eso no lo vamos a poder mantener mucho tiempo operativo, con un Business Central On-premise.

Algunas de las excusas que clientes (y partners) ponen para evitar dar el salto a la nube son:

Excusa 1: Falta de control del departamento de informática.  

Evidentemente no vamos a tener acceso al SQL pero ... ¿Deberíamos manipular datos en el SQL directamente?  La respuesta es no.  Eso se salta toda la lógica de negocio.  Pero no es la primera vez que veo borrar datos directamente con comandos SQL y luego claro, los costes no salen bien.  Si lo que se quiere es usar datos de Business Central, tienes alternativas para llegar a ellos (ver como crear dataset personalizados sin código).

Excusa 2: No todo se puede hacer en extensiones.

Cierto, si lo que se quiere hacer es manipular la codeunit 80, no se puede, pero es que no se debe.  Desde la versión Business Central 14 hasta la última, se han incluido multitud de eventos en muchos objetos (tablas, codeunits, páginas,..).  Podemos hacer todo, sin afectar a las actualizaciones.  Y si el evento no está donde tú quieres, pídelo a Microsoft.  Si es razonable tu petición, lo pondrán en versiones posteriores y si no lo es, te podrían indicar como solventarlo.

Si a lo que te refieres es a las DLLs o Automations que ya no podemos usar, tenemos la solución de las Azure Functions.

En está excusa, hay que tener en cuenta que desde que yo conozco Navision, por la versión 1,30 de 1998, las codeunits y las tablas son muy similares por no decir iguales y el lenguaje C/AL se ha ido ampliando pero lo básico sigue siendo igual, por lo que no hemos cambiado mucho la forma de programar.  Pero ahora, la cosa cambia.  Hay que ponerse al día en extensiones, eventos, Azure, APIs, Odata, llamadas http, ficheros JSON ...  cosas que hasta hace poco las veíamos de lejos ya que en nuestra burbuja de Navision, no nos afectaban.

Esto que nos sonaba a chino ahora también es Business Central

Excusa 3: Rendimiento.

La velocidad no es la misma...  Obviamente.  No es lo mismo tener el servidor debajo de la mesa con una red ethernet de 1000 mbps que conectarse a Internet...  Pero a cambio no necesitamos infraestructura: ni servidor, ni instalar nada en el equipo, ni licencias de SQL, ...  Solamente un navegador (preferiblemente Edge 😉 ).

Además, como desarrolladores debemos de pensar en mejorar nuestros diseños para hacerlos más rápidos  (puedes ver algunas buenas prácticas aquí).  Microsoft cada día saca nuevas funcionalizades encaminadas a esta tarea.   En las últimas versiones permite por ejemplo consultar sólo registros parciales (SetLoadFields del que hablaremos en un próximo post).  Pero esto, debemos usarlo en nuestros desarrollos. De lo contrario no aportan nada.

Excusa 4: Espacio.

En estos momentos la capacidad de almacenamiento está "limitada" a 80 Gb de base de datos, cierto pero ¿no pensáis que de vez en cuanto hay que hacer limpieza?  Igual es el momento de hacerlo.  Los datos pueden estar pero no en Business Central.  Si necesitas sacar información tienes un fantástico Power BI para analizar información de varias bases de datos.

Conclusiones.

Debemos pensar en migrar.  Lo de que viene el lobo, Microsoft nos lo está diciendo hace mucho y llegará un momento que vendrá.  

Hay que refactorizar.  Sí, habrá que pensar en cambiar mucho código, pero llevamos ya bastante tiempo con extensiones y deberíamos tener bastante trabajo realizado.  También podemos apoyarnos en el marketplace.  No todo hay que desarrollarlo nuevo, ¿no sería mejor reutilizar lo que otros han programado ya?

Consultoría.  Replantearnos si realmente los procesos que se hacían hace diez años, siguen siendo usados.  Habrá que revisar que personalizaciones tenemos que convertir a extensiones, por ver si realmente son válidas todavía.

Aprovecha la mudanza y haz limpieza.  Si alguna vez has hecho mudanza, te das cuenta de las cosas que realmente te sobran y que no usas hace tiempo.  Pues lo mismo pasa con los datos.  Limpia y trabaja con unos datos más estructurados, borra los clientes que ya han desaparecido, elimina cuentas contables que ya no se usan...

Piensa que después del trabajo, ya no tendrás que preocuparte de las actualizaciones y te ahorrarás el coste de las migraciones.

Además, se abre un mundo de conexiones:

Cualquier duda o comentario, puedes ponerte en contacto conmigo.