web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Blogs / Business Central Services / Migrando NAV2009R2 a Busine...

Migrando NAV2009R2 a Business Central 18. Paso III

Views (15)
Robyn2018 Profile Picture Robyn2018 Most Valuable Professional

 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)





This was originally posted here.

Comments

*This post is locked for comments