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: