Cualquier parecido con la realidad es pura coincidencia.
Migrar bases de datos antiguas a Business Central siempre ha sido un reto, pero pasar de un NAV2009R2 a un Business Central 18, ya es mi reto para este final del verano.
Migración de NAV2009R2 a Business Central 18
Seguro que todos os habéis encontrado en situaciones con una base de datos tan antigua y pensar si realmente merece la pena migrar o hacer una nueva instalación. Aquà existen multiples factores determinantes y no seré yo el que diga cual es la mejor decisión, ya que dependerá de cada empresa.
Como sabéis hay dos partes fundamentales: Migrar el código y migrar los datos.
La migración de código de C/AL a extensiones ya de por sà tiene su complejidad, pero en este caso, solamente voy a centrarme en la parte de datos, con un ejemplo real: Migrar los datos de una empresa de NAV2009R2 a Business Central.
Material suministrado: Copia de seguridad de los datos del cliente y número de versión de NAV que tiene instalado el cliente.
Primeros problemas...
El primer problema que me surge es montar un entorno adecuado. Estamos hablando de NAV2009R2, que ya tiene unos añitos. Hay que buscar el DVD (si eso redondo donde se guardaban los programas) pero recuerda, debe ser del mismo cumulative update del cliente o superior y con los mismos hotfix que tuviese instalado (recordad que en tiempos pasados, Microsoft suministraba hotfix a los partners para solventar errores que encontraba). Obviamente estos hotfix ya no están disponibles en las webs de Microsoft, o al menos yo no los he encontrado para descargar, por lo que hay que buscarlos por ahà tirando de contactos.
Aquà os dejo el enlace a la web de Waldo, donde podéis encontrar diversos hotfix:
También os dejo la web para la descarga de NAV2009R2:
1 - Abrir NAV2009R2
Prueba superada. He restaurado la copia de seguridad, he instalado el software y el correspondiente hotfix. El cliente usa autenticación Windows, pero mi entorno no está en su dominio, no tengo usuario en la base de datos. ¿como accedo entonces?
TIP: La solución pasa por SQL. Si, en este caso, necesitamos usar el SQL Management Studio para acceder a las tablas de user y windows login de la base de datos a migrar para borrar los registros existentes. Para ello usamos los siguientes comandos:
delete * from [MiBaseDatos].[dbo].[User]
delete * from [MiBaseDatos].[dbo].[Windows Login]
Estamos dentro. Recordad que una base de datos sin usuarios, permite acceder sin autenticación, por lo que ya tenemos otro escollo superado. Si necesitas mantener los usuarios, comenta a tu cliente que exporte tanto los usuarios y los perfiles para que luego podamos importarlos.
2 - Merging objetos
Una vez que hemos conseguido entrar tenemos que generarnos dos ficheros.
- Fichero con los objetos tabla de una base de datos CRONUS ESPAÑA en la versión NAV2013 en formato texto.
- Fichero con los objetos tabla de la base de datos personalizada (la de nuestro cliente) en su versión NAV2009R2 en formato texto.
¿Cual es el objetivo? Se trata de crear los campos y tablas personalizadas, en la versión actualizada. Solo los campos y las tablas nuevas. Recuerda que mi objetivo es pasar los datos, no pasar el código, por lo que simplemente con crear los campos serÃa suficiente. No me hace falta crear el código C/AL que tuviesen asociados en los triggers.
Una vez realizado el merging en formato texto, añadiendo todos los campos importo el fichero en mi base de datos demo de NAV2013. Con esto he conseguido tener todos los campos y tablas de mi base de datos personalizada en objetos de NAV2013.
Ahora exporto los objetos (TODOS, tablas que he modificado, pages, codeunits,...) en un fichero FOB (AllCustomObjectsNAV2013.FOB). Luego lo usaremos.
3 - Siguiendo la documentación oficial
La documentación oficial nos indica los pasos a seguir, pero... no tan fácil. Recuerda que han pasado unos años desde NAV2009R2 hasta Business Central. Esto no es ejecutar un toolkit y ya está. Hay que hacer varios pasos.
Para empezar, debemos llegar a Business Central 14 on-premise. Esta versión fue la última que tenÃa "Object designer", con lo que buscamos documentación para llegar allÃ:
Lamentablemente, podemos observar que no podemos llegar a Business Central 14, desde NAV 2009 R2. Según nos indica, debemos tener primero la base de datos en NAV2015 y entonces sà podremos actualizar.
Vale, entonces actualicemos a NAV2015. No tan rápido... La migración de datos de NAV2009R2 a NAV2015, no es directa. Antes hay que pasar por NAV2013 o NAV2013R2.
4 - Migrando NAV2009 R2 a NAV2013
Aquà tienes el enlace a la documentación de la actualización a NAV 2013:
Vamos entonces a migrar a NAV2013. Buscamos el DVD de la versión y buscamos la carpeta Toolkit, donde obtendremos los ficheros de migración de datos. Tenemos que usar los objetos de migración de la localización que vamos a actualizar. En este caso, se trata de la versión ES por lo que buscamos los objetos de migración correspondientes (Local Objects) y desde la versión de la que queremos partir (en nuestro caso NAV2009 R2 -> 601):
Importamos los objetos necesarios y procedemos a ejecutar el formulario 104001 Upgrade - Old Version y una vez allà el botón "Transfer Data". Este proceso tarda una media hora, en función, claro está, del tamaño de la base de datos, pero teniendo en cuenta que hablamos de una empresa que lleva usando Navision desde la versión NAV2009R2 (al menos), seguramente habrá datos.
NOTA: Recuerda que este proceso hay que hacerlo por cada una de las empresas a migrar.
Nuevos problemas: Invalid Object name
Después de unos minutos de ejecución del Upgrade Old Version, el siguiente error:
Lo primero que me sorprende es que pone "almacen" en castellano. Raro, muy raro. Todos los nombres de campos y tablas en NAV están en inglés.
Entonces recuerdo que estamos en NAV2009R2. Ese software en el que nos pensábamos que se podÃa hacer de todo en cualquier sitio y cuando migrásemos ya verÃamos a ver. Asà que, vamos a meter unos procedimientos almacenados (sin documentar claro) en SQL para hacer procesos por fuera de Navision.
Por tanto, hay que descubrir que tablas de NAV tienen procedimientos almacenados y desactivarlos o borrarlos desde SQL Management Studio. No hay nada que odie más que estar 10 minutos ejecutando un proceso y que muestre un error, asà que prefiero desactivarlos todos.
|
Donde se encuentran los procedimientos almacenados |
Conseguido el transfer data y siguiendo la documentación, lo que nos dice es que debemos pulsar el segundo paso, botón "Delete objects". Este proceso borrará todos los objetos de la nueva base de datos, excepto las tablas.
Ahora sÃ, ya podemos parar la instancia de NAV2009R2 y abrir la base de datos con NAV2013. Nos pedirá que actualicemos la base de datos. Cuidado este proceso no es reversible, asà que una vez iniciado, ya solamente se podrá abrir con NAV2013. Procedemos a actualizarla. Otro proceso largo. En mi caso, casà tres horas. Creo que es un buen momento para hacer una copia de seguridad, que ya llevamos mucho tiempo invertido.
Lo que actualmente tenemos es una base de datos de NAV2013 pero solo con tablas. Para tener el resto de objetos, vamos a importar el fichero generado en nuestro punto 2 (AllCustomObjectsNAV2013.FOB). El sistema lógicamente nos indica que hay conflictos y nos pedirá abrir la hoja de trabajo de importación. Pulsaremos Replace All para importar los datos.
Parece que todo va bien, pero... tenemos un error en la importación:
"metadata 200000079 was not found"
¿Que ocurre? Que nos hemos encontrado con los maravillosos "DataPerCompany=NO". Esa maravillosa propiedad de las tablas (se entiende modo ironÃa activo), que permitÃa compartir datos en todas las empresas.
Antes de continuar debemos exportar los registros de la tabla compartida, eliminarlos para después, poner la propiedad de nuevo a "DataPerCompany=YES" e importar de nuevo los registros previamente borrados en cada una de las empresas. Recordad que Business Central tiene uso limitado de esta propiedad.
Por fin. Nuestros datos han llegado a NAV2013.
Abriendo NAV2013
Ya hemos conseguido pasar nuestros datos a NAV2013. Vamos a configurar nuestra instancia para poder abrirlo y ver si tenemos allà los datos. Pero tenemos un último problemilla que salvar. El cliente tenÃa configurados unos FORMS iniciales para que en función del usuario, se abriese una pantalla u otra. Claro, ahora ya no son forms, son Role Centers (Pages). Tenemos que modificar la tabla donde se almacena esa información que no es otra que "Profiles", al menos el perfil por defecto, donde pondremos el Rol Center por defecto de Navision 9006 Order Processor Role Center.
Y por fin, abrimos NAV2013 (se han ocultado columnas por privacidad).
En la siguiente entrada, procederemos a continuar nuestro camino hacia Business Central 18.
No hay comentarios:
Publicar un comentario