Tras la presentación de la última y completamente renovada versión del nuevo Microsoft Dynamics AX, y con la que AXAZURE lleva trabajando algo más de 2 años, llega el momento de replantear a nuestros clientes con sus actuales versiones si es viable dar el salto en el medio/largo plazo a la nueva versión.

Para ello, nos adentramos en los tres escenarios posibles desde los que podemos partir para realizar la migración a la última versión de Microsoft Dynamics AX:

1.  El cliente ya está en AX 2012 R3

Como el cliente ya funciona con la versión AX 2012 R3, el paso a la nueva versión será más sencilla, ya que la actualización a la nueva versión se simplifica. Sin embargo, podrá generarse una duda: ¿debería realizar una actualización a la nube pública, la nube privada o quedarse en On-Premise?

Cuando se compara la nueva versión con AX 2012 o anteriores, la integración con las aplicaciones externas debería ser más fácil con la nueva versión. Sin embargo, las actualizaciones de datos no estarán disponibles hasta el próximo otoño 2016 y las nuevas implantaciones de Microsoft Dynamics AX aún no cuentan con ningún script de actualización de datos, solo los que se crean con la propia actualización.

2.  El cliente se encuentra en AX 2009

Lo recomendable en esta ocasión es invitar al cliente a que actualice la versión a AX 2012 para facilitar, más tarde, la transición al nuevo AX. De esta forma se le ofrece un equilibrio más seguro, pues Dynamics 2012 R3 CU8 (ya van por el CU11) es muy similar a la nueva versión en términos de lógica de negocio y modelos de datos.

La actualización a la versión 2012 como paso intermedio ofrece las siguientes ventajas:

  • Repartir los costes y riesgos de actualización en el tiempo.
  • Disminuir la actualización de los riesgos del proyecto para evitar posibles retrasos.
  • Evitar el estrés del cliente además de una confusión innecesaria en lo que una migración supone.

3.  El cliente cuenta con otra estrategia de upgrading

Existe la posibilidad de que sea más recomendable realizar una reimplantación o… una combinación entre actualización y reimplantación. Pero, ¿en qué casos?

Si el cliente cuenta con muchas personalizaciones es posible que el paso a la nueva versión le podría suponer una acción bastante compleja y costosa, por lo que sería recomendable realizar una reimplantación. Esta misma posibilidad sería la mejor opción en caso de que el cliente utilice las soluciones ISV o la integración con aplicaciones de terceros que no son compatibles con la versión actualizada de AX. Realizar una estrategia de actualización mixta es lo adecuado en algunos casos como por ejemplo si el cliente tiene que volver a aplicar algunos módulos de Dynamics AX particulares o si desea deshacerse de las personalizaciones.

Desde AXAZURE cada vez con menos frecuencia tratamos de desarrollar muchas nuevas funcionalidades al ERP, puesto que somos conocedores de la complejidad que esto implica con los cambios de versión. Nuestra estrategia es y seguirá siendo el pensar “out of the box” o lo que es lo mismo, utilizar al máximo la funcionalidad estándar que trae el ERP.

Sabemos que el nuevo AX tardará todavía cierto tiempo en llegar a tener un impacto alto en el mercado de clientes AX, pero internamente ya estamos preparando una metodología específica para la migración o Upgrading de otras versiones antiguas al nuevo Microsoft Dynamics AX, o el comúnmente llamado AX7.