Considerations for Data Migration D365 Finance & Operations
- 1. Considerations for Data Migration D365 Finance & Operations Written By: Gina Pabalan Director, Data & Analytics
- 2. Harvesting enterprise data is central to how organizations compete, and even survive, as industries transform digitally. Yet, as companies merge and technologies shift, managing data has become an extremely complex and critical task, especially handled alongside of an enterprise ERP implementation. For companies moving from an on-premise legacy ERP system to Microsoft’s cloud-based Dynamics 365 for Finance and Operations (“D365”), there are some unique challenges and new tools to leverage when considering the data migration activity. Microsoft delivers the Data Management Framework (“DMF”) tool to assist customers with data migration for D365. Data migration itself consists of three distinct activities, as illustrated below: Data extraction (from legacy systems), data transformation and data import into D365. DMF assists with the import of data into the new D365 application. But what is the best way to extract and transform the data from a legacy environment to prepare it for input to the DMF tool? Data Migration for Companies Migrating from a Legacy ERP 2 fullscope.com This white paper addresses approaches for extraction and transformation of data from legacy systems, as well as strategies for addressing seamless reporting of transactional data (i.e., sales) combining the new D365 data with legacy data after system go-live.
- 3. For the purpose of this paper, we will classify data into these three categories: master data, transactional data or opening balances. Master data spans the dimensionality of an organization’s business functions and consists of information about a person, entity or object. For example, in the sales, marketing and customer service functions, master data can consist of customer numbers, contact info, service codes, warranty information and distribution details. In the finance function, master data might include GL accounts, cost centers, department codes and company hierarchies. Master data can be very detailed. For example, a master vendor record contains not only general information such as a vendor’s name and address, but also specific information, such as payment terms and delivery instructions. Master data remains somewhat constant over time and is really the core data about your company, which forms the basis of an enterprise-wide “system of record” for the business. Transactional data are all the unique business events that occur in the day-to-day operations of a business, such as a shipped order or a movement of inventory. Transactional data will consist of “facts” like quantities shipped, amounts invoiced and hours worked, and be associated with the master data dimensions. The volume of transactions grows exponentially each year and can easily add up to millions of records. Transactional data can be either closed historical transactions or open transactions. Opening balances are essentially a rollup of transactions to a point in time. For example, inventory starts at zero and all the inventory transactions (+/-) sum to an ending balance, which becomes the opening balance for a new period. If historical transactions are left behind, one will need to import an opening balance in the new ERP system for assets and liabilities (i.e., inventory). Master data, “open” transactional data and open balances need to find their way into D365, either programmatically, or manually, depending on the total number of records and the need for automation. Migrating historical transactional data into D365 is generally discouraged. Data Defined 3 fullscope.com
- 4. Data living in a legacy ERP system will be structured very differently than data required for D365. It is not a simple mapping from one system to another. Microsoft simplifies the import process by providing the Data Management Framework (“DMF”) tool. The migration of legacy data into D365 will primarily focus on the master data, such as customers, vendors, items, etc. The DMF tool helps to easily import data into D365 that will then proliferate to all the underlying D365 tables associated with that particular data set. That said, it does require a customer provide the export, cleansing and transformation of its own legacy data into a standard Excel-based format, provided by Microsoft, as defined by the D365 entity structure. Once in that format, DMF picks it up and properly loads it into D365. The process of legacy data extract and transform (the “ET” of “ETL”) typically falls to the customer, who is more familiar with their own legacy data. This process can be painstaking and tedious, and prone to error if not completed in a systematic and repeatable way. Customers will likely use Microsoft SSIS to accomplish this task, or consider a SQL-based automation tool like Fullscope’s Accelerator to streamline this legacy data extract and transform activity. Fullscope’s Accelerator provides SQL-based ETL automation fully leveraging the Microsoft stack. With Fullscope’s tool, this data extract and transformation process is 50-75% more efficient than writing SSIS the traditional way, and offers additional long-term benefits (see “addressing reporting goals” below). Data Migration for Your D365 Implementation 4 fullscope.com “Fullscope’s Accelerator provides ETL automation fully leveraging the Microsoft stack.”
- 5. So what about the transactional data? Migrating historical transactional data can present a major problem when considering a move from a legacy ERP system to a more modern ERP system with its new data structures, posting methodologies and workflows. The reality is that all those facts, events and transactions, living in their legacy format, requires harmonization and transformation before they can be plugged back into a new ERP system. In addition, many transactions will require further processing (i.e., posting), and the very process of posting transforms the data further, making it even more challenging to get the various data sets to synchronize into a functional whole. Next, consider that many companies have millions of historical transactions, so the chance for error is significant. It is unlikely all the errors would be identified and corrected during the ERP data validation phase, which means that companies will continue to “pay the price” for data anomalies long after their ERP go-live. For this reason, most experienced ERP implementation partners advise customers to not migrate transaction history from legacy applications to a modern ERP system. With the D365 cloud pricing model, Microsoft further discourages this migration by charging customers for the extra storage required, making this an even more expensive proposition. For customers who are upgrading from Dynamics AX 2009 to D365, it should be noted that the data schema is dramatically different. Table structures were re-architected and have ballooned in number—from 1,800 tables to over 10,000 tables. That, along with the many functional changes delivered by Microsoft in the Dynamics product, results in having to execute a “re-implementation” vs an “upgrade” from AX 2009 to D365. Migrating AX 2009 historical transactional data should be avoided. For customers who are upgrading from Dynamics AX 2012 R3, the data schema is closely aligned, and a data upgrade is certainly possible. A review on the overarching reporting and BI strategy would be warranted to determine if the increased cost and effort are worth it. Migrating historical transactional data will result in increased project complexity, cost and risk. Most commonly, the reason for migrating the data tends to be for reporting purposes and there are certainly better ways to address this critical business need. We will explore this further next. Historical Transactional Data Why You Shouldn’t Migrate It to D365 5 fullscope.com5 fullscope.com
- 6. Every business understandably wants to keep legacy data and preserve its integrity. After all, a company may have spent decades compiling it, as it’s the only way to show trends and reveal patterns to help guide the way forward. Legacy data is valuable. For businesses moving to D365, there are a couple options--besides migrating transactional data into D365--to achieve post implementation reporting that combines legacy and new D365 data. Each of these options is described and illustrated on the next page: Addressing Reporting Goals 6 fullscope.com Migrate balance and net change activity into D365. This approach is most commonly used to address financial reporting requirements. It involves moving general ledger account opening balances and periodic net changes into D365. This approach provides a valuable capability to drive year-over-year financial reporting. Since we are not migrating volumes of historical transactional data, it is limited in that drill down to the transactions themselves would not be possible. Simple mashup within Power BI. Microsoft delivers embedded Power BI with its D365 application. If the organization upgrades to Power BI Pro, it is possible to do some limited data mashup within Power BI itself. The challenge with this approach lies in the budget for additional Power BI Pro licenses, plus the challenge with transforming and harmonizing data across the aggregate D365 entities and detailed legacy data. Further, this method implies that Power BI would be the only option for reporting. So although possible, it is not always practical or desired. Report directly from BYOD. The BYOD is an export of the standard data entities into anAzure SQL data store. Think of the BYOD as an operational data store that provides full SQL access to D365 data. Although it is possible to pull legacy data into the BYOD for reporting, the BYOD behaves more like a staging database than a true modeled data warehouse that will allow for meaningful reporting and analytics. BYOD as a source for a data warehouse. In this case, the BYOD is used specifically for D365 data, in order to leverage the full power of SQL for data transformation and harmonization. SQL SSIS ETL is used to pull data from the external data source (i.e., legacy environment), and then transformed and harmonized into a governed data set specifically designed to support the organization’s reporting and analytics needs. If this approach is taken, Fullscope’s Accelerator can greatly help expedite this capability and provide a tool that can be leveraged for long-term enterprise reporting and analytics. If the tool is used for migration of master data, as described above, much of that work can be leveraged on the back side to ensure harmonization of data between old and new ERP systems. 1 2 3 4
- 8. Most D365 customers want to leverage the full Microsoft stack, which in the data world means, leveraging SSIS, or SQL Server Integration Services to move data around. Microsoft’s SSIS tool comes prepackaged with the customer’s Microsoft licenses and since it is a standard Microsoft tool, skills are easily found in the resource market should assistance be needed. But as anyone with SSIS proficiency understands, the ETL task of writing scripts and stored procedures can be a mind numbing task. Further, to successfully write export scripts, one requires some inherent knowledge of the business, and its business rules and definitions for its data. Sitting a business analyst alongside an SSIS programmer can be akin to putting two people in a room who speak two separate languages. And herein lies the opportunity. Fullscope’s Accelerator delivers a pre-configured D365 Data Migration Hub that integrates with the D365 Data Management Framework to steamline data migration for D365 implementations. The Accelerator includes an ETL automation capability that auto-generates all the SQL code in an open and non-proprietary environment. It also includes a drag-and-drop interface that documents and maintains all the important metadata and mappings. This results in: 1) faster delivery of the ETL code (50-70% more efficient), 2) systematic and repeatable development process, 3) accurate documentation and lineage of all data transformations, 4) streamlined error tracking and troubleshooting capability, 5) effortless “re-write” as migration requirements evolve (and they will), 6) decoupled data migration activities from the D365 application development cycle to facilitate more iterative testing. Businesses that use Fullscope’s Accelerator see a quick return on their investment, saving countless hours of time and frustration involved with cleaning up legacy data and structuring it to work with the Dynamics 365 Data Management Framework. If you have any questions or want to consider this solution as part of your D365 implementation, please contact us at Fullscope.com. The New World Order Edgewater Fullscope delivers innovative Microsoft ERP, CRM, BI and digital solutions and services on premise or in the cloud to companies in North America and Europe. The award-winning company is one of the largest resellers of Microsoft Dynamics 365 (formerly Dynamics AX and CRM). We also offer strategic consulting delivering a blend of classic and product-based consulting services that help clients reduce costs, improve processes and increase revenue through the judicious use of technology. We continually fine- tune our process and user-adoption programs to give you the maximum return on your investment. This commitment to stay with you throughout your Dynamics 365 journey has earned us the highest customer retention rate in the business. For more information, visit fullscope.com CONTACT US