This Beyond the BC Bits blog series focuses on the non-technological factors that play a crucial role in determining the overall success of an organization’s Business Central implementation project. The goal is to highlight and provide guidance on many of the major factors that will most significantly impact your project’s success.
Part 1 of this series covered how to properly prepare for your implementation project, while Part 2 covered how to work with a Business Central partner, Part 3 covered the best practices for managing the implementation project, Part 4 provided strategies for how to approach training and testing of the application, and Part 5 offered some considerations for when and how to effectively build customizations to the software. The final article will cover the long-term management of Business Central.
In this article, the focus is on data migration and deployment. Topics will include strategies for defining what data should be migrated, how it should be migrated, how to test and approve the migrated data in Business Central, and guidance on scheduling and organizing the “go-live” data migration tasks. No matter how effectively you have planned for the new processes and workflows that will be deployed in Business Central, if equal attention and testing is not given to the data migration process, the go-live will not be successful. The data migration process must be well-planned, fully tested, approved, and scheduled during deployment.
Not all data should be migrated into Business Central
There are several factors that should determine exactly what existing data in your current systems should be migrated into Business Central.
The first factor is the quality of the existing data. If the data is not current, accurate, and trustworthy, it should not be migrated into Business Central as this ERP migration is the perfect opportunity to clean the data and start fresh. Often people say they will migrate what exists today and then clean it up in Business Central after go-live, but the cleanup typically never happens.
The second factor is whether or not the data will be adjusted or revised as it is migrated. These changes may be due to inherent differences in the data structures between the existing system and Business Central, or it may be due to decisions made by the project team to improve the data usability in Business Central. For example, if you are planning on revamping the Chart of Accounts in Business Central and deploy dimensions for use in segmented financial statements, then you likely are not going to be able to migrate your G/L history from the existing system.
A third factor is whether or not users will continue to have access ot the existing system once Business Central is deployed. If the existing system will continue to be available, then it is much less important for transactional history to be migrated to Business Central. Entries like A/R or A/P history, or posted purchase invoices can remain in the existing system and users can access this system when needed. The reality is that after a few months, users rarely revert back to the old system once Business Central is up and running, so it doesn’t make sense to invest a huge amount of financial and human resources in migrated history in this case.
Build a Data Migration plan by Data Type
There is quite a large list of potential types of data that can be migrated between systems. If you are using Manufacturing, there could be upward of 40-50 different data elements (tables) that may be considered for data migration. To efficiently manage this extensive list and plan effectively, a “Data Migration Planning” document should be created that lists the specific element of data, whether or not the data is to be migrated, how the data will be migrated, and who is responsible for the data migration process. This is typically a spreadsheet format that is shared with the project team so that everyone is clear on what data will be migrated and how it will be migrated. It is important that responsibility for the data migration of each data element is assigned to a user or user team since the data accuracy and completeness in Business Central will need to be confirmed at go-live.
There are three categories of data: Static/Setup data, historical transaction data, and open balance data. Static/setup data are things like Customers, Vendors, and Items and sometimes these are referred to as “master data”. Historical transaction data would include things like posted sales invoice, customer receivables entries, inventory entries, or G/L entries. Open balance data include entries such as outstanding A/P, outstanding A/R, On-hand inventory, open purchase orders, open sales orders, and open Projects or Production Orders. The category of each data type to be migrated should be identified on the Data Migration Plan worksheet so that planning can be completed regarding when each type of data will be migrated when the deployment arrives.
Approve the entire Data Migration plan before the go-live data is established
Confirming the data migration is equally important as confirming the workflow of all business processes to be deployed in Business Central. When planned correctly, the migration of data at the go-live date should be a simple exercise of executing the established plan with no guesswork or decision-making needed.
To properly approve each type of data, one or multiple users must approve that the data that has been migrated during the migration testing phase (1) is accurate and (2) that the migration method and timing is adequate to eliminate any scheduling or timing issues at go-live. For example, it is possible that all static data is fully migrated at least 1-2 weeks before the go-live data. Open balance data is planned to allow for the prior month-end to be successfully completed in the legacy system so that the data can be reconciled upon migration into Business Central. Finally, transactional data will not typically begin until after the prior period-end processing has been completed in the legacy system. Because this data is historical, it is possible to wait days or even weeks after the go-live data to migrate historical data. At first glance, this may all seem to be common sense, but in reality, this may require much more planning than anticipated, so it is important that everyone understands the timing of all data migration efforts between the legacy system and Business Central.
Conduct a go-live readiness and decision meeting where each user or user group can formally acknowledge that they understand and approve of the plan for all data migration activities. This will minimize mis-communications and bad assumptions during the critical go-live effort.
Certify the entire Data Migration plan after the data migration is completed
This is a relatively straight-forward task, which asks the user or user group who approved the data migration plan prior to the go-live to certify the data that has been migrated into Business Central. This should be done after the data is migrated into Business Central but before "live" transactions are allowed in Business Central. This step will serve as a final recognition that the migrated data is accurate, complete, and fully reconciled against the data in the legacy system. This is typically the very last opportunity available before users begin entering and posting transactions in Business Central, or "the point of no return"!
Planning and executing the data migration process should be given significant attention throughout the implementation process. These recommendations provided above are very high-level and much thought and planning much be put into this aspect of the implementation. But following these general guidelines will provide the strong foundation that is needed for ensuring a smooth deployment.
Comments