Migración AX 2009 a AX 2012 R3

Hilo iniciado por Alejandro Aguilera el 21 de julio de 2016

Viendo 2 entradas - de la 1 a la 2 (de un total de 2)
  • Autor
    Entradas
  • #9652
    RangoAlejandro AguileraAlejandro Aguilera
    Participante
    PARTICIPANTE
    1.099 Rincoins

    Muy buenos días, estimados me gustaría de su ayuda, hace ya 5 años que trabajamos con Microsoft AX 2009 el cual tiene 2 personalizaciones que son el corazón de nuestro negocio, un modulo de arriendo y un modulo de Importación. hace ya 1 mes que estamos pensando migrar a Microsft ax 2012 R3 y los plazos estimados son el primero de enero del 2017.

    para esta migración me gustaría de su ayuda, me gustaría saber las consideraciones(pro y contra) que hay que tener en este proceso de migración.

    #9653
    RangoHugo de JesúsHugo de Jesús
    Participante
    MASTER
    129.350 Rincoins

    Hola Alejandro,

    Interesante cuestión. Normalmente cuando un cliente nos pregunta como enfocar la migración surgen varias preguntas que quizás se apliquen a ti, realmente y simplificando mucho, todo tiene que ver con el coste de migrar y los riesgos asociados.

    Si queremos mantener el historial transaccional y migrar todo el sistema tal y como está, va a depender del numero de desarrollos y su complejidad, pero si tengo el 2009 muy “tocado” el proyecto de migración va a ser largo y complejo y conozco mas de un proyecto fallido o con problemas de fiabilidad y rendimiento.

    Otras empresas, aprovechan la migración para “limpiar” el AX, no solo de datos si no también de ciertos desarrollos en desuso, mal realizados (problemas de performance por ejemplo) o cubiertos por la nueva funcionalidad de 2012. En este caso se opta por implantar 2012 en limpio, migrar aquellos desarrollos clave uno a uno y migrar maestros, saldos y partidas abiertas. Evidentemente, en este modelo, si quiero ver una factura antigua tengo que ir al 2009 que lo tendré en un servidor solo para este tipo de consultas.

    Así que dicho esto te imaginarás que la primera opción, sobre todo externalizada, tendrá un coste mucho mas elevado si se realiza con personal externo que la segunda opción, y por supuesto tiene riesgos adicionales al tener que volver a testar todo el entorno migrado. Mientras que con la segunda opción pierdo el historial y esto en ocasiones no es viable.

    Existe una opción adicional a la segunda opción que es crear ciertos informes u olaps que lean de ambas versiones para sacar informes y estadísticas consolidadas si es algo critico.

    En cualquier caso no es una decisión sencilla y depende como te decía de lo que estéis dispuestos a asumir.

    Espero que esta información te sea útil.

    Saludos

Viendo 2 entradas - de la 1 a la 2 (de un total de 2)
  • Debes estar registrado para responder a este debate.
Carrito de compra