Cloud migration changes with BC19 wave 2

With BC 19 wave 2 Microsoft improved the Cloud Migration functionality by re-designing the migration flow, cleaning up the errors reported by the partners over the summer, allowing migration of a larger set of GP tables with one additional extension installation, and removing the version 18 size limitations.

Improved migration flow

  • search “cloud migration management”
  • go through “Cloud Migration Setup”
    • before version 19, the replication and data upgrade were done in one step
    • now we have 2 separate steps triggered from the Migration Cloud Management page actions:
  1. “Run Migration Now” – for copy/replication; at the end the last “Cloud Migration Management” entry shows “Upgrade Pending”
  2. “Run Data Upgrade Now” – once data is copied it has to be validated/upgraded. Status will move through “Upgrade in Progress” and Completed.

The split of the unique process “Run Migration Now” into two steps was introduced to better manage cases when the data upgrade would fail.

If this is the case, then in the admin center you can restore the environment as of the time of end of the replication step and repeat the data upgrade.

Cloud migration resiliency

  • use of upgrade tags: to avoid multiple data upgrades processing use Upgrade Tags or to completely skip the upgrade. More here.
  • less locking when running cloud migration (more companies per run). There is still a limitation if schema for migrated tables is above a json object limit of 4 Mb. To avoid locking, migrate companies in smaller chunks. Especially if you get an error like this:
    • The size of the lookup activity result exceeds the limitation …
  • data repair after Cloud Migration: some data would be missing while migration would be reported as successful in the previous version

Dynamics GP migration changes

  • Enabled large GP tables (> 500 mb or > 100k records)
  • Support mapping of any custom table
  • add events for GP to BC migration:
    • new sample Microsoft extension to create BC counterpart tables for GP tables (source code here). This allows for a much larger set of tables to be migrated to SaaS.
    • mapping between GP to BC tables
    • there is also a powershell script that generates AL table based on a SQL table

Upload limits

80 GB limitation is lifted. Any size is supported.

Cleanup as much as possible before cloud migration

Some functionality may be disabled after cloud migration if tenant is too large. For ex. you might not be able to create a sandbox from Production if your capacity is 80 GB and you reached already 80 GB with your Production. Alternatively, you can upgrade capacity.

So I chose Business Central … But am I losing my Dynamics GP data?

In the last 6 months I’ve been involved with a number of GP to BC migration projects.

A recurring question that reaches our team is how do I see GP data in BC?

One avenue to move your business to BC is to import open transactions and master data, and tested setup tables with RapidStart packages. If the underlying table of the desired GP entity does not exist in BC, then a Business Central developer would need to create the table in BC and, with Edit In Excel functionality you can get GP data in BC.

There is also the Cloud Migration Tool in BC. More about it here.

Using this tool ensures the most important entities, master data and open transactions, will make it into BC. But what if a GP end-user wants additional GP data in BC?

Microsoft recommendation is to bring as little as possible into the cloud from an on-premise database.

Moreover, as your database capacity increases, your cost can increase. See more here.

Rather than bringing GP tables one by one in BC, use the cloud migration tool to move data from GP to Azure Data Lake.

If the decision is, though, to have some GP data in Business Central, there are tools to make that possible.

We can extend the cloud migration tool so that, when the migration starts, beside the core migrated data (master data and open transactions) the process will also bring into a new space (an extension table) the data from the GP table as mapped in the “Manage Custom Tables” page.

What’s needed to achieve this:

  • Create a Business Central extension. In it, create an AL table to store your data from a GP table
  • Add the custom table in Manage Custom Tables
  • Run migration tool
  • Check custom table content after migration

Let’s try bringing table GL00100 from GP in BC.

Note: this table was chosen only for demonstration. GL00100 is brought by default by the cloud migration tool into BC table “G/L Account”.

Create extension with GP table

I created an extension that includes a table for this GP entity:

Map migration for new table in “Cloud Migration Management”

In Business Central, search for “Cloud Migration Management”.

Under actions trigger “Manage Custom Tables” action:

Under “Migration Table Mapping” page, map new table in your extension to the GP table:

On “Migration Cloud Management” trigger the “Run Migration Now” action.

You can check the results in the cue on the Migration Information area:

To check the content migrated:

  • change the company to the migrated company
  • run the new table by adding “&Table= 50340” to the Business Central URL:

We can now see the result of migrating the GP data to the custom BC table:

Conclusion

To answer the question in the title, you don’t lose GP data. There are multiple ways of accessing your GP data post go-live to BC, involving:

  • retaining the access to your old system
  • migrate your Dynamics GP installation to Azure (SQL Server and application)
  • migrating your GP data warehouse to Azure Data Lake
  • or, as shown above, with minimal coding, keeping your GP data in Business Central

Engage with your partner and decide what GP data do you really need today so that long term your cloud ERP stays performant.