How are you planning on migrating data from your ERP and legacy systems to Microsoft Dynamics 365 Enterprise? Data Management in the ERP system can help you accomplish part of this. But what if there were another solution you could use to manage the entire process?
When we work on data migration and integration projects, we keep everything as safe, simple, and repeatable as we can. In today’s post, I would like to share our dream and show you how we implemented it in To-Increase Connectivity Studio. A typical statement that sums up our preferences and those of many systems administrators is, “At go-live, I want to be able to push one single button, and everything is handled at no risk, without any challenges.”. That simple data migration is possible! There are four main aspects to accomplishing it.1: Connect as you expect
Many of our customers are not all that comfortable in working with services and using more technical ways to access data. To keep things simple and useful for the business, we recommend that you create the on-premise connections by using Open Database Connectivity (ODBC) or files.
As regards ODBC, we have developed a simple, effective way to connect to on-premise databases from the cloud. That makes it possible to get your data from Microsoft Dynamics AX 4.0, 2009, 2012 or any other application into the new Microsoft Dynamics 365 Enterprise ERP system. A small agent can be installed in your on-premise environment to connect with Dynamics 365 Enterprise using the Azure Service Bus. Reducing risk and simplifying projects, ODBC is a common best practice for many businesses and the technology partners working with them.
When you connect by means of files, things remain simple thanks to Azure File storage. Azure file storage supports the SMB 3.0 protocol, which results in several advantages. It's easy to create a connection as a Windows share and use it like that in Windows Explorer. You can actually assign a drive letter to it, if you like. You can then simply copy, paste, and organize files as you're used to do in Windows Explorer. In addition to that, existing interfaces from old legacy systems can connect from their on-premise location to the cloud.2: Map your way
The mappings in Connectivity Studio are highly flexible. You can use data entities but also any table and any field in Dynamics AX. Doing so addresses the annoying issue that you always need to develop data entities for new or existing tables. In Connectivity Studio, all business logic is supported out-of-the-box. When it comes to complex data structures, you can export and import, for instance, sales orders from customers in different formats including XML, fixed text, EDIFACT, JSON, and CSV.3: Create the flow
You can also set up data dependencies (I made a video about data dependencies earlier). That means that you can specify the sequence using dependencies and easily group messages with the same dependency together. For example, base data should go first. After that you can import customers and vendors, and transactions should be imported last. Connectivity Studio keeps the performance at a high level by processing in parallel all the data that can be handled this way. Parallel processing can increase the data migration speed by ten times or more.4: Start the flow
When everything is set up, you can look forward to pushing one single button to get the things done. Just press that one button in Connectivity Studio to execute the data migration and let it do its work. Wait until it is entirely finished.
The solution executes your data migration based on the defined dependencies, and imports all the data with full validation. In the end, you can review any errors in the history and re-run data migration steps from there.
We recommend testing any migration by running it multiple times to make sure it performs to your expectations, does not present any risk, and will not offer any challenges at go-live.
With this simple approach, we continue following the practice that already worked well for Microsoft Dynamics AX 2012 and earlier versions. Our kernel is still the same, proven in many different customer scenarios. Mapping and flexibility are unchanged as well. The only differences are that we now store in Azure File storage using the SMB protocol, not blob, and for ODBC we developed an agent to handle on-premise requests.