This is a "nuts & bolts" whitepaper discussing the capabilities and challenges of migrating data to Microsoft Dynamics365 for Finance and Operations (D365).

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.