Data migration is usually the most complex and underestimated area of any ERP implementation. This chapter makes you understand data migration requirements, managing the data migration scope, identifying the tools and techniques for data migration, and data validation.
The following topics are covered in this chapter:
Rightsizing the scope is the first step towards successful data migration. Often, customers have either not considered data migration at all or have unreasonable expectations regarding the requirements. Even if the original sales proposal has explicit data migration requirements that have been identified, many of the project team members and stakeholders may not be aware of what was specified or may not agree to the mentioned scope. Hence, it is important to facilitate a scoping exercise with the project team and document the mutually agreed results.
The following section covers a few tips for the scoping of data migration and educating the business stakeholders.
The following set of questions can be asked during the scoping exercise:
Do your homework on the proposed data migration and validate your assumptions with the business rather than asking the open ended question "What data do you want to migrate?" The following table is an example that you can use as a starting point to help validate the decisions to be agreed upon in a data migration requirements session:
Additionally, you can leverage the Dynamics AX data migration requirements spreadsheet within Microsoft Sure Step to identify and plan to migrate your data. This spreadsheet is intended for the consulting team to use internally. However, it can also be used as a tool to facilitate the data migration requirements gathering and can subsequently be used throughout the project lifecycle to confirm whether each migration data element has been identified, and that the process has been defined, developed, and tested. The following table image shows an example of the columns and data that are important for the scoping session. Additional columns help you manage the development, testing, and final move to the production system:
As I stated at the beginning of this chapter, business stakeholders often expect their shiny, new Dynamics AX system to have their historical data from their legacy system. Anything less would mean that they have less information now rather than more, right? Part of the data migration planning process is educating the business stakeholders on the cost of that mentality and focusing the business on the information, which is driving business decisions, servicing customers, and providing analysis.
In principle, you should avoid migrating historical transactions, such as posted sales invoices, posted purchase orders, individual general ledger transactions, inventory transactions history, and so on. The effort to cleanse and transform the data for Dynamics AX is an expensive proposition and takes the resources away from the goal of designing and developing improved processes within Dynamics AX. More importantly, most of this data doesn't really drive the business decisions or even worse, it provides inaccurate views of the business due to bad data and/or processes from the legacy system.
Certainly, the historical transactional data is needed for either regulatory, business analysis, or customer satisfaction reasons. However, there are other solutions available rather than agreeing to migrate the legacy data into Dynamics AX tables. Some cheaper solutions that I have used in the past to satisfy customer needs around history are given as follows, and can be used depending on the size of the dataset and the requirements around how the data will be used: