Why should I setup a Data Migration from my Business Central Docker Container to a Microsoft Dynamics 365 Business Central SaaS tenant: “Because I can?”
Well, this might be one answer, but there are other good reasons. Let me explain.
When I start a SaaS migration project for a customer I want ensure that all needed business data will be migrated and transferred in the right way. Furthermore I want to identify and remove all technical obstacles like missing apps, tables and fields. I also want to estimate how long it takes to upload the customer database to a SaaS tenant. In other words, I prepare and test the technical migration.
As a result of my technical migration, the customer data in my Business Central SaaS tenant is available to key users and consultants. This complete the migration scenario, for example by testing business processes as well as manual probing of data.
In summary, there are enough good reasons to set up a data migration for a customer database from my preferred local environment – a docker container – to a Business Central SaaS tenant. Because, I want to test my technical data migration!
Setup & Prerequisites
Usually I use an Azure Virtual Machine as environment for such a setup. The creation is simple and well explained at Freddy’s Blog. Useful ARM templates for deployment are:
As result I get an Azure Virtual machine which host in my case a Business Central 15.2 docker container with my restored backup of my customer database.
After successful creation, I must configure the firewall of my Virtual Machine to open the SQL-Server port (in my case port: 1433). This is because the Business Central SaaS Migration Setup need to talk with my local SQL Server hosted by my Docker Container.
Additionally, I have added this port in my docker container setup as parameter “-PublishPorts” and disabled Treafik:
New-BCContainer navserver -PublishPorts @(1433) -useTreafik:$false ...
Finally, I create a new Business Central SaaS tenant by using the Customer Digital Experience from Microsoft. This take also a couple of minutes.
Cloud Migration Setup
Let’s start with setting up the Cloud Migration Setup. In other words, I configure my migration source and destination. In my case these are:
- My migration destination is my Business Central SaaS tenant.
- And my migration source is the Docker Container in my Azure Virtual Machine
Therefor, I start with the source setup in my Business Central SaaS tenant. I use the “Set up Cloud Migration” wizard from “Assisted setup” and follow the instructions.
My Business Central container version is 15.2.xxxxx. Therefor, I select the a previous version for my migration setup.
As next step I need to enter my SQL Server Connection String. This means, I need to address my SQL Server inside of my Docker Container.
The tooltip of “SQL Connection String” give me this notation hint:
: Server=myServerName\myInstanceName;Database=myDataBase;User Id=myUsername;Password=myPassword;
I use a virtual machine on Azure “bc-vm01” and the SQL Server is configured with password “Passw0rd!”. Therefor, my “SQL Connection String” is:
: Server=bc-vm01.westeurope.cloudapp.azure.com;Database=default;User Id=sa;Password=Passw0rd!;
- The SQL Server Port on your machine to your docker container must be accessible.
- Treafik setup of a Business Central might also cause problems
After the wizard established successful a connection to my specified SQL Server, I get a link to download the Self Hosted Integration Runtime (SHIR) for my migration source and an Authentication Key for the Data Migration setup from migration destination.
Therefore I switch to my Azure Virtual Machine, my migration source, where I install the Self Hosted Integration Runtime.
I use the copied Authentication Key during the setup of the Self Hosted Integration Runtime as follows and register my local data source:
Afterwards I switch back to the Data Migration Setup of my Business Central SaaS tenant – the migration destination. As result of the “Next” step in my wizard, Business Central connect to the migration source and provide a list of available companies for migration:
I select my companies for migration and continue.
In the next step, I need to specify my preferred the data migration scheduling. I did not activate the scheduler, because I want to trigger the transfer manually after completion of the setup manually.
Finally, I can finish the setup.
The Migration Setup Wizard have already triggered a migration of the previously selected companies. I see this result, when I open my “Cloud Migration Management” list of my Business Central SaaS tenant:
While the creation of my target companies is running in the background, I can check my tables for migration. As you can see in the screenshot, 384 of my tables have not yet been migrated.
Therefore, I start the data migration from my Business Central SaaS tenant with the “Run Migration Now” action:
This takes a while, depending on the amount of data. I can refresh the status frequently by executing “Refresh Status” action:
My factbox shows details of my migration as “Run Statistics”. The reasons for the displayed Warnings in my example is: I have Missing Source Tables, because some Apps are not present in my Business Central migration source in my docker container.
First of all, I must say that data migration from OnPrem to SaaS has been greatly improved and is much easier than in Business Central 14 or 15. I was able to set up this scenario in a short time and repeated the migration from the Docker Container to the SaaS tenant several times to remove some migration issues.
Additionally with this setup you can prepare, simulate and test a technical data migration for customers. In detail you don’t need anymore fixed installations, you can recreate the environment with PowerShell on demand.
Finally, if you encounter a problem, you solve it and recreate the docker container and the Business Central SaaS tenant for a new migration run. This helps a lot to identify and remove all obstacles for a SaaS migration.
… Happy Sharing and don’t forget #NeverStopLearning