Migrando NAV2009R2 a Business Central 18. Paso III - Business Central

Breaking

lunes, 18 de octubre de 2021

Migrando NAV2009R2 a Business Central 18. Paso III

 En los pasos anteriores, habĆ­amos conseguido llegar desde

- una versión NAV2009R2 a una NAV2013 (ver aquí)

- una versión NAV2013 a un Business Central 14 (ver aquí)

En la entrada de hoy, pasaremos de una versión BC14 a un Business Central 18.5


De Business Central 14 a Business Central 19

Lo primero que debemos tener en cuenta es la matriz de compatibilidades.  Es decir, de una versión BC14 a quĆ© versión podemos actualizar directamente:

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/upgrade/upgrade-v14-v15-compatibility


O lo que es lo mismo, según la versión en la que estamos de BC14, podemos actualizar a una versión u otra.

Si tu intención es hacer la migración al Cloud, podrĆ­as hacerlo directamente desde Business Central 14, pero con algunas limitaciones.  



NOTA: En versiones anteriores, hasta la primera minor release (xx.1) no salía la migración desde versiones anteriores, pero me ha sorprendido que en Business Central 19.0, ya estÔ disponible.

Ten en cuenta que si haces una nueva instalación hoy en la nube, se instalarĆ” en la Ćŗltima versión.  En mi caso, acabo de crear un tenant y directamente se ha creado con Business Central 19.0.

Pese a ello, deberemos hacer una serie de procesos previamente, puesto que de lo contrario habrÔ información que no se actualice a la nube.

Que pasa con mis datos personalizados

Si recordĆ”is, en el punto 3 del post anterior, pasamos todos nuestros datos personalizados de las tablas estandar y personalizadas a unas que llamamos de transición.  

Bien, ahora tenemos nuestros datos personalizados en unas tablas que no existen en la versión 19 en la nube, por lo que lógicamente no se migrarían.

Para solucionar todo esto necesitaremos:

- Una extensión de AL de mis tablas 90000 (las de transición)

- Una extensión de AL con las personalizaciones del cliente

- Una extensión para migrar los datos de mis tablas de transición a las tablas de personalizaciones.

Recordad, que desde C/AL no podemos acceder a las tablas de una extensión por lo que debemos crear la extensión en Business Central 14.

Creando mi extensión de tablas de transición

Lo primero que vamos a hacer es crearnos una extensión para que las tablas de transición estén disponibles.

Para ello, desde el Object designer de BC14, exportaremos todas las tablas 90xxx en formato texto.


Con lo que nos habrĆ” generado un fichero con todas nuestras tablas en formato texto, pero del lenguaje C/AL.  Ahora tenemos que convertirlas a AL.

Para convertir de CAL a AL tenemos el comando TXT2AL que podrĆ”s encontrar en el directorio de Business Central.  Normalmente "C:\Program Files (x86)\Microsoft Dynamics 365 Business Central\140\RoleTailored Client"

Al comando, le indicas de donde tiene que obtener el fichero de texto (--source) y donde tiene que guardar los generados en AL (--target):

Con este proceso, nos habrÔ creado una serie de ficheros en lenguaje AL que serÔn con los que construyamos una extensión un poco especial:


Esta extensión no tendrÔ Application.app en la carpeta .alpackages y su referencia en el App.json tampoco estarÔ.
El fichero system.app lo obtendremos de la carpeta:

C:\Program Files (x86)\Microsoft Dynamics 365 Business Central\140\AL Development Environment\System.app

Migrando a Business Central 18.5

Aunque como hemos dicho, el sistema nos permitirĆ­a pasar de Business Central 14 a Business Central 19 cloud, tendrĆ­amos un problema:  Como pasar los datos de nuestras tablas de transición a una extensión.  

Por otro lado, en caso de que hubiese errores en el upgrade, serƭa mƔs dificil de localizar.

Para solucionarlo, y ademÔs permitir tener nuestra versión también en On-Premise, en este post, vamos a migrar a una versión 18.5, antes de subir a la nube.

Usando PowerShell

A partir de aquĆ­, se acabo el Object Designer, por lo que solamente vamos a trabajar con PowerShell.

Lo ideal, al menos para mĆ­, es abrir PowerShell ISE para poder guardar un fichero con todos los pasos, por si hay que repetir.


En la línea 2, importamos el módulo con las herramientas administrativas que usaremos.

Las lƭneas 4 a 6, lo que hacemos es crear unas variables (Instancia, bd y server) que nos permitirƔn, solamente cambiando estos valores, repetir el proceso cuando tengamos que migrar otras bases de datos.

Ahora con la instancia de BC14 parada, comenzaremos con la migración a BC18.5 siguiendo los siguientes pasos:

1 - Convertimos la base de datos 

Invoke-NAVApplicationDatabaseConversion -DatabaseServer $Server -DatabaseName $bd

2 - Configuramos la nueva instancia

a) Configuramos la instancia con la nueva base de datos:

Set-NAVServerConfiguration -ServerInstance $Instancia -KeyName DatabaseName -KeyValue $bd

b) Deshabilita las tareas programadas

Set-NavServerConfiguration -ServerInstance $Instancia -KeyName "EnableTaskScheduler" -KeyValue false

c) Marcamos la instancia como que va a ser usada para migración

Set-NAVServerConfiguration -ServerInstance $Instancia -KeyName "DestinationAppsForMigration" -KeyValue '[{"appId":"63ca2fa4-4f03-4f2b-a480-172fef340d3f", "name":"System Application", "publisher": "Microsoft"},{"appId":"437dbf0e-84ff-417a-965d-ed2bb9650972", "name":"Base Application", "publisher": "Microsoft"}]'

d) Instalamos la nueva licencia

Import-NAVServerLicense -ServerInstance $Instancia -LicenseFile "C:\files\bc180.flf"

3 - Reseteamos la instancia

Restart-NAVServerInstance -ServerInstance $Instancia

4 - Publicamos las diferentes Apps del sistema, aplicación y propias

a) Publicamos la app System Application, que encontraremos en el DVD de Business Central

Publish-NAVApp -ServerInstance $Instancia -Path "F:\versiones\BC18.5\Applications\System Application\Source\Microsoft_System Application.app"

        (esta suele ser rĆ”pida: 1 o 2 minutos)

b) Publicamos la app Base Application, que encontraremos en el DVD de Business Central

Publish-NAVApp -ServerInstance $Instancia -Path "F:\versiones\BC18.5\Applications\BaseApp\Source\Microsoft_Base Application.app" 

        (Esta publicación consume mucha memoria.  Es posible que en función de tu equipo muestre un error por falta de memoria.  Tarda unos 15 minutos)

c) Publicamos la app Application, que encontraremos en el DVD de Business Central

Publish-NAVApp -ServerInstance $Instancia  -Path "F:\versiones\BC18.5\Applications\Application\Source\Microsoft_Application.app" 

        (Esta tambiĆ©n suele ser rĆ”pida, aproximadamente 2 minutos)

d) Publicamos la app diseñada anteriormente con las tablas de transición

Publish-NAVApp -ServerInstance $Instancia  -Path "C:\Users\rcorella\Documents\AL\CustomizedNIL\RCB_CustomizedNIL_14.0.0.0.app" -SkipVerification

        (RĆ”pida, 1 minuto)

f) Reiniciamos la instancia

Restart-NAVServerInstance -ServerInstance $Instancia

5 - Sincronizamos las Apps con la base de datos

Para que nuestra base de datos, este alineada con lo que dice la aplicación, hay que sincronizar las Apps.  La duración de estos procesos, depende del tamaƱo de la base de datos, pero empiezan a ser largos.

a) Sincronizar el tenant

Sync-NAVTenant -ServerInstance $Instancia -Mode Sync -Tenant Default 

            (30 minutos)

b) Sincronizar las aplicaciones empezando (y en orden) por System

Sync-NAVApp -ServerInstance $Instancia -Name "System Application" -Version 18.5.29545.0 -tenant Default
             (2 minutos)

Sync-NAVApp -ServerInstance $Instancia -Name "Base Application" -Version 18.5.29545.0 -tenant Default

            (30 minutos.  AquĆ­ nos pueden surgir errores con los datos existentes, por lo que hay que estar muy atento al visor de eventos)

Sync-NAVApp -ServerInstance $Instancia -Name "Application" -Version 18.5.29545.0 -tenant Default

            (2 minutos)

Sync-NAVApp -ServerInstance $Instancia -Name "CustomizedNIL" -Version 14.0.0.0

            (2 minutos)

6 - Hacemos el upgrade de datos 

Start-NAVDataUpgrade -ServerInstance $Instancia -Tenant Default -FunctionExecutionMode Serial -SkipAppVersionCheck 

            (Este proceso, parece que acaba rĆ”pido pero puede durar unos 30 minutos)

Si quieres ver el progreso, puedes usar el comando:

Get-NavDataUpgrade -ServerInstance $Instancia -Progress

7 - Instalamos nuestras Apps 

Install-NAVApp -ServerInstance $Instancia -Tenant Default -Name "CustomizedNIL"


Restart-NAVServerInstance -ServerInstance $Instancia

Ya tenemos la instancia lista para ejecutar Business Central 18.5

8 - ¿Y ahora quĆ©? 

Cuando empezamos, os dije que era una actualización de datos, no de código.  Por tanto, mi trabajo acabarĆ­a aquĆ­.

Tengo todos mis datos estandar en Business Central 18.5 y los personalizados en una extensión de "Transición", disponibles para que alguien haga la extensión de personalizaciones del cliente y traspasar los datos de una a otra.  Este proceso podrĆ­amos hacerlo en on-prem o en la nube, teniendo en cuenta que estaremos duplicando tablas (transición y personalizaciones), por lo que una vez pasados los datos, deberĆ­amos de despublicar la extensión de "Transición" con borrado de datos.


PodrĆ­amos subir nuestros datos a la nube, pero eso lo veremos en otra entrada.

Recuerda que hacer una migración de datos, requiere de paciencia y de tiempo.  Lamentablemente no es un proceso automĆ”tico y como hemos visto en las tres entradas, nos vamos encontrando "problemillas" que hay que solventar antes de seguir.  Por tanto unas recomendaciones muy importantes:

- Trabaja SIEMPRE con copia de la base de datos del cliente y guarda la original en lugar seguro.

- Durante el proceso de migración, haz copias de seguridad.  Seguro, seguro que debes volver atrĆ”s en algĆŗn momento y eso harĆ” que no tengas que empezar de cero.

- Las migraciones se deben realizar cuando los usuarios no estĆ”n introduciendo datos: un fin de semana, un puente,... vamos en esos dĆ­as en los que en general se descansa.  Por eso, procura hacer una migración de prueba antes con una copia de la base de datos.  EvitarĆ” el estrĆ©s de que te encuentres con errores y tengas un tiempo limitado para solventarlos.  AdemĆ”s te permite que el usuario testee la migración de prueba y detectar incidencias que no sean propiamente de datos.

Cualquier duda, que os pueda surgir, no dudƩis en comentarme por los medios habituales (twitter, linkedin o en los comentarios)




No hay comentarios: