Migrando NAV2009R2 a Business Central 18. Paso II

En la entrada anterior, habíamos conseguido, no si solventar algunos problemillas, llegar a la versión NAV2013.  

<<<< Aquí puedes ver el paso anterior De NAV2009R2 a BC18 paso I

De NAV2013 a Business Central

Tal y como os explicaba en el anterior post, no podemos pasar directamente de NAV2009R2 a Business Central.  Debemos ir haciendo unos pasos:

    NAV2009R2 -> NAV2013 -> NAV2015 -> Business Central 14 -> Business Central 18

La mayor parte de los problemas nos los encontramos ya anteriormente, por lo que el paso de NAV2013 a NAV2015 no debería darnos muchos quebraderos de cabeza.

En mi caso, voy a instalar la versión de NAV2015.  Simplemente por una cuestión de que prefiero ir viendo los distintos escenarios como van quedando y si me da alguna incidencia abrir el cliente.

Logicamente, para poder tener varias versiones de Navision/BC instaladas, debemos asignarles diferentes puertos.  Mi entorno de migraciones tiene este mapa de puertos:

Aquí el ejemplo de los puertos en mi equipo para tener todas las versiones operativas

1 - Merging campos personalizados en estandar

Una vez instalado, procedemos a obtener un fichero de texto con todos los objetos tabla del estandar NAV2015.

De nuestra base de datos migrada a NAV2013, obtenemos también las tablas en formato texto.

En el fichero NAV2015 de tablas haremos un merge con los campos personalizados de la NAV2013.  Lo importamos en la base de datos de demostración CRONUS y ya tenemos los objetos migrados a la versión NAV2015 (solo objetos tabla claro ya que recuerda que mi objetivo es la migración de datos).  

Lo exportamos y generamos un fichero AllCustomObjectNAV2015.fob

2 - Convirtiendo la base de datos NAV2013 a NAV2015

Procedemos a abrir nuestra base de datos NAV2013 en NAV2015 para convertirla.

Antes de hacer la sincronización, voy a proceder a importar los objetos generados en el punto 1 (AllCustomObjectNAV2015.fob).  Así, tendremos los objetos ya con los mismos campos personalizados y tablas nuevas.

Eso sería lo ideal, pero... nos surgen nuevas sombras.   Algunos clientes piensan que las tablas son para escribir libros.  Por tanto crean campos como si no se fuesen a acabar nunca.  Varios campos de texto de 250 caracteres, de 100,...  lo dicho, para escribir un poema en cada factura.  Eso nos lleva a que algunas tablas superen ahora el número de bytes permitido por registro.

Para solucionarlo, reviso mediante SQL si esos campos están rellenos, para evitar problemas.  Como me imaginaba, muchos de ellos no contienen datos, así que procedo a recortar campos.

Ahora sí, ya tenemos la bbdd actualizada y con los objetos importados, podemos sincronizar y ver si tenemos algún problema.

Como no nos surgen problemas ya podemos arrancar NAV2015. 

3 - Datos personalizados (ReportCustomizedToUPG)

Este es un buen momento para obtener los datos personalizados y separarlos de los estandard.  Realmente nos daría lo mismo hacerlo aquí que haberlo realizado en la NAV2009R2.

¿Que vamos a hacer?  Mediante un report (ReportCustomizedToUPG), vamos a recorrer todas las tablas y sus campos de la base de datos del cliente, con el objetivo de separar lo estandard de lo personalizado.   Pero ... ¿Como sabremos si es estandard o personalizado?

- Si la tabla es menor de 50000 y mayor de 7000000, es una tabla estandard

- Si es estandard, buscamos los campos que sean 50000 o mayores, pero menores que 7000000.

(Recuerda que los objetos y campos personalizados en Microsoft Dynamics NAV tienen que tener un rango de id de 50000 hasta 99999.  A partir de ahí, hay númeraciones de Add-ons de partners)

El report compondrá un fichero de texto con objetos tabla (las llamaremos de transición) teniendo en cuenta que dichas tablas, tendrán como campos:

- Los campos que componen la clave principal de la tabla estandard

- Los campos personalizados.

Supongamos que la tabla 14 Location, tiene un campo personalizado 50001 Muestra informe:

Así sobre cada una de las tablas estandard.

Lo mismo haremos con las tablas personalizadas, pero en este caso copiaremos todos los campos (son todos propios).

Recuerda que los campos calculados "FlowField" o los filtros "FlowFilter" no contienen valores, por lo que dichos campos no se generarán.

El mismo report también nos generará en el fichero dos codeunit:

- Codeunit 90000: copiará los datos de las tablas estandar y personalizadas, a las nuevas tablas que ha creado de transición

- Codeunit 90001: copiará los datos de las tablas de transición a las tablas estandard.

El proceso sería como sigue:

1) Generamos el fichero con las tablas y la codeunit 90000, mediante el report.

2) Importamos y compilamos el fichero del paso anterior, con lo que tendremos esto:

3) Ejecutamos la codeunit 90000 para traspasar los datos desde las tablas estandar a las de transición

La codeunit 90001 la utilizaremos más tarde.

Ya hemos conseguido disponer de todos los datos personalizados en unas tablas de transición.  

4 - Vamos a por Business Central 14

Descargamos la última actualización de Business Central Abril 2019 (v. 14):

https://docs.microsoft.com/en-us/dynamics365/business-central/dev-itpro/deployment/update-versions-14

En el momento de escribir este blog va por la CU26 de Agosto de 2021, así que será esa la que descargue e instale.

5 - Exportando los Objetos estandard de CRONUS BC14

Una vez que hemos instalado la base de datos de demostración de Business Central 14, podemos proceder a generar nuestros ya famosos ficheros:

 - Fichero con todos los objetos en formato FOB (AllObjectBC14.fob)

 

6 - Convirtiendo la base de datos

Desde object designer de BC14 (ejecutado como administrador), abriremos la base de datos de NAV2015, mostrando un aviso de la conversión.

Si nos pide el tipo de sincronización que queremos realizar, podemos usar "Later".

7 - Importar Objetos standard en base de datos personalizada

En este caso, lo que haremos será importar en nuestra base de datos personalizada, los objetos que hemos obtenido en el punto 5, seleccionando en la hoja de importación "Replace All".

Ahora ya podemos configurar nuestra instancia para poder asignarle la base de datos convertida.

8 - PowerShell.  Ese gran desconocido.

Pese a que ya teníamos PowerShell desde hace bastante, en Business Central 14 empieza a tener una especial relevancia, teniendo en cuenta que en las siguientes versiones desaparece el Object Designer.  Entonces, ¿como cargamos una licencia?  ¿como hacemos una sincronización de la base de datos?  Pues la respuesta es Power Shell y su colección de comandos.

Empezaremos sincronizando nuestro SQL y nuestra Aplicación.  Para ello usaremos dentro de la herramienta Administration Shell el siguiente comando (recuerda que debes sustituir <ServerInstance> por el nombre de tu instancia):

Sync-NAVTenant -ServerInstance <ServerInstance> -Mode Force

Ohhh.  La cosa no podía ser tan sencilla.  Enforced dependencies.  ¿y eso que es?

Según nos indica, la tabla Detailed Cust Ledger Entry tiene dependencias.  ¿A que se refiere?

Un poco de teoría.  Las tablas de NAV tienen Keys (claves) y esas claves, estan compuestas de campos.  Pero también tenemos los SUMINDEXFIELDS. Son esos campos que usamos para acelerar los cálculos. 

Bien, esos SumIndexFields, Navision los mantiene en SQL como Vistas indexadas:

  

https://docs.microsoft.com/en-us/dynamics-nav/sift-and-sql-server

Por tanto, ¿que ocurre si nuestro cliente ha añadido nuevos campos SumIndexFields en las claves de las tablas estandard?  Pues que tendremos Vistas que estén en SQL pero no están en las nuevas versiones de Business Central, por tanto error.

Para solventar el error, debemos de eliminar los SumIndexFields personalizados directamente en las vistas de SQL.

Una vez eliminados, el comando de sincronización funcionará sin problema.

NOTA: Cuando se complete la sincronización del tenant, debe de tener el estado OperationalDataUpgradePending. Esto lo verificamos ejecutando:

 

Get-NAVTenant -ServerInstance <ServerInstance> -tenant default

El siguiente comando a ejecutar será el upgrade de datos.  Para ello usamos:

Start-NavDataUpgrade -ServerInstance <ServerInstance>

Una ver finalizado sin incidentes, ya tendremos la base de datos en Business Central 14.

En este punto, deberíamos de hacer una actualización de los complementos Add-ins, pero como mi objetivo no es quedarme en Business Central 14, pues realmente me los voy a saltar.

TIP: Otro buen momento para hacer una copia de seguridad

9 - Eliminamos las tablas personalizadas

En este punto podemos eliminar desde Object Designer ya las tablas personalizadas que tuviesemos (las 50000, no las de transición).

Al eliminarlas le indicaremos que queremos hacerlo con sincronización "Force", ya que lo que queremos es eliminarlas y eliminar su contenido.

En esta travesía, he encontrado ciertos campos que ya no se utilizan en esta versión, por lo que tendremos que eliminarlos:

Intrastat Setup :: The field 'Use Advanced Checklist'

Intrastat Jnl. Line :: The field 'Counterparty'

VAT Posting Setup :: The field 'Sales Special Scheme Code'

VAT Posting Setup :: The field 'Purch. Special Scheme Code'

Journal Line Dimension :: The table 'Journal Line Dimension'

Document Dimension :: The table 'Document Dimension'

G/L Budget Dimension :: The table 'G/L Budget Dimension'

Customer/Vendor Warning 349 :: The field 'No Taxable Entry No.' 

10 - Publicando los símbolos

Publicamos los archivos de los símbolos que encontramos en la ruta donde hemos instalado nuestro entorno de desarrollo de Business Central, C:\Program Files (x86)\Microsoft Dynamics 365 Business Central\140\AL Development Environment.

Esto lo hacemos desde Business Central Administration Shell como administrador:

Publish-NAVApp -ServerInstance BC140 -Path 'C:\Program Files (x86)\Microsoft Dynamics 365 Business Central\140\AL Development Environment\System.app' -PackageType SymbolsOnly

Publish-NAVApp -ServerInstance BC140 -Path 'C:\Program Files (x86)\Microsoft Dynamics 365 Business Central\140\AL Development Environment\Test.app' -PackageType SymbolsOnly

Después de todo esto, ya tenemos Business Central 14 operativo.

Creo que se me está haciendo muy largo, así que haré un tercer capítulo para pasar de BC14 a BC18.

De momento me estoy encontrando con un problemilla de rendimiento.  Hemos pasado una base de datos de unos 20 Gb, pero en la cual, no se borraban los pedidos de venta o de compra.  ¿que quiere decir? Que tenemos miles de pedidos "Abiertos" por lo que las pilas de los Role Center, tendremos que trabajarlas para que no tarde mucho tiempo en arrancar.

Seguimos en la siguiente entrada Migrando de NAV2009R2 a Business Central 18 III.