Ad
More Related Content
What's hot (20)
Similar to What you need to know about Data Migration for D365 Finance & Operations (20)
Ad
Recently uploaded (20)
Ad
What you need to know about Data Migration for D365 Finance & Operations
- 1. Considerations for Data Migration D365 Finance & Operations Written By: Gina Pabalan Director, Data & Analytics https://www.linkedin.com/in/ginapabalan
- 2. Data Migration for companies migrating from a legacy ERP Harvesting enterprise data is central to how organizations have to compete, and even survive as industries transform digitally. Yet, as companies merge and technologies shift, managing data has become an extremely complex but 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 will assist in the import into the new D365 application, but what is the best way to Extract and Transform, to “ready” the data for the import? 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 both new D365 and old legacy data after system go-live. Data Defined We define “data” as either 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. Open 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
- 3. balance for a new period. If historical transactions are left behind, one may need to import an Opening Balance in the new ERP system for certain assets or liabilities (inventory). Examples of each data type are illustrated below and must be considered as part of your D365 implementation. Clearly, 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. Data Migration for your D365 implementation Understanding that data living in a legacy ERP system will be structured very differently than data that is required for D365 import. Microsoft simplifies the import process by providing the Data Management Framework (“DMF”) tool. The migration of legacy data will primary be focused 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 master data set. That said, it does require that the customer provide the export, cleansing and transformation of its own legacy data into a “staged” standard format into Excel, as defined by the D365 Entity structure. Once in that staged 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 should consider a tool like SSIS to accomplish this task, or an automation tool like Fullscope’s Accelerator to streamline this legacy data extract and transform activity. Fullscope’s Accelerator provides ETL automation fully leveraging the Microsoft stack. With Fullscope’s tool this data extract and transformation process is 50-75% quicker than writing SSIS the traditional way, and offers additional benefits to the customer long term (see “addressing reporting goals” below). However, even with all these tools, migrating historical transactional data into D365 is generally discouraged. We will explore this next. Historical Transactional Data – Why you shouldn’t migrate it to D365 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
- 4. 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 will 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 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 AX2009 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 6,500 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 AX2009 to D365. Migrating historical transactional data should be avoided. For customers who are upgrading from Dynamics AX2012 R3, the data schema is closely aligned and data upgrade is certainly possible. A review on the customers’ 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. Addressing Reporting Goals Every business understandably wants to keep legacy data and preserve its integrity. A company may have spent decades compiling it. It’s the only way to show trends, reveal patterns and guide the way forward. Legacy data is valuable – it might even represent the very lifeblood of the company itself. For customers 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 below: 1. 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. 2. Simple mashup within PowerBI. Microsoft delivers embedded PowerBI with its D365 application. If the organization upgrades to PowerBI Pro, it is possible to do some limited data mashup within PowerBI itself. The challenge with this approach lies in the customer’s budget for additional PowerBI Pro licenses, plus the challenge with transforming and harmonizing data across the aggregate D365 entities and detailed legacy data. Further, this method implies that PowerBI would be the only option for reporting. So although possible, it is not always practical or desired. 3. Report directly from BYOD. The BYOD is an export of the standard Data Entities into an Azure SQL data store. Think of the BYOD as an operational data store which provides full SQL access to D365
- 5. data. The BYOD does not provide data in a star schema, so although it is possible to pull in external source data (i.e., your legacy data), it behaves more like a staging database, than a true star schema data warehouse that will allow for meaningful reporting. 4. 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 (ie, 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 customer’s can leverage 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. The New World Order For D365 customers, most want to leverage the full Microsoft stack, which means in the data world, the customer will leverage 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 you need assistance. But for anyone proficient with SSIS, the ETL task of writing scripts and stored procedures can be a mind numbing task. Further, to successfully write export scripts, one needs 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 here in lies the opportunity. With Fullscope’s Accelerator, we are able to put a drag and drop interface in front of the client that maintains all the important metadata, as well as auto generating all that mind numbing SSIS code. This results in 1) 50-75% faster in delivering the ETL SSIS code 2) highly documented and systematic repeatable code/process 3) much better error tracking 4) effortless “re-write” as requirements evolve. The ROI on Fullscope’s Accelerator is high and should be considered as part of any ERP implementation.