12 ERP Cloud Data Migration Best Practices
Data migration is a key part of any successful cloud ERP implementation. As a project manager, you’ll want to properly scope and staff a data migration from the start.
Here are 12 cloud ERP migration best practices that are critical to success.
Decide what data to migrate
One of the first and most important decisions to make is what data to migrate.
To ensure you identify all affected data, identify all current applications affected by the ERP implementation. Then identify all the applications that your new ERP system will replace. If you are replacing multiple apps, you may need to migrate data from multiple apps.
Review early download pattern
In order to upload data to the new ERP application, you will need to format the data you extract from the old ERP to match the upload template provided for the new ERP. Review the template early to assess the complexity of the formatting required.
Understand the complexities of data mapping
As part of the data mapping process, you will also need to consider the data types in each system. For example, you may have a customer ID in one application that accepts alphanumeric characters while the other application only accepts numeric characters. In this case, you will need to decide how you will account for this difference during the mapping and migration process.
Decide on migration settings
Most project managers choose to migrate only certain data to the new cloud ERP system. There are several reasons for this.
For example, the volume of data is large and will take time to migrate, the data is old and no longer relevant in the future, or migrating all the data is prohibitively expensive. For these reasons, project managers usually choose to migrate only data that falls after a specific date. For example, Teams should only migrate data entered after January 1, 2020. You can also add other settings, such as whether Teams should migrate data from vendors who no longer supply your organization.
Plan new data
The data migration process is also a good time to consider what new data you plan to capture in your new ERP system and how that will affect data loading into the new ERP.
If this data did not exist in your old system and is required in your new ERP, you may need to create it during the migration process. It could be a status field, a new date field, or something else that will be required in your new application.
Specify what to do with data that has not been migrated
If you decide to migrate only certain data, you will need to consider what happens to the data left behind in your old ERP application. Here are some options:
- If you still have access to the old ERP, you can set everyone’s permissions to read-only. This will block new input but ensure that you can reference old data when needed. Your old ERP vendor may offer reduced fees for continued access to the application if it exists in read-only mode.
- If you don’t anticipate needing the data in the future, you can simply archive the data into spreadsheets for future reference. Before choosing this option, consider the volume of data that the old ERP contains and the complexity of the data. These factors help determine if using a spreadsheet is a viable option.
- As a third option, you can configure a database to store the data. This can be useful if you think you need to access data once in a while, but not on a regular basis. This will become a small project in itself, as someone will have to set up a database and migrate all the data that has not been migrated to the new ERP system. You may also need to develop a small application or reports to simplify the extraction of data from the database.
Plan the failover schedule and double entry
An important decision is to determine on what date and time you will start migrating data from the old ERP to your new one. Employees may need to continue entering data into the old ERP application so that they can run the business once you extract the data. You will have to manually enter into the new ERP system everything that was entered in the old one after the data extraction.
Extracting, formatting and importing data into the new ERP application can take days or weeks. The longer it takes, the more double entry will be required to ensure that someone enters all post-migration changes into the new system.
Internal processes that rely on the ERP application
When defining the schedule for the failover, consider the impact it may have on other applications or processes that depend on data from the legacy ERP application. For example, the finance team may need to access data at the end of the month. They can’t be locked out of your old ERP for long.
Schedule manual data entry
Although you automate data migration as much as possible, you may encounter situations that do not justify the investment of time and effort to automate the migration. For example, you may have five vendors that have an exception to the rule. Rather than creating the conversion scripts for five vendors, it may be easier to enter them manually or edit their data in your new app as part of the migration process.
Review data cleanliness and accuracy
Before migrating your data to a new ERP application, you may want to include time in the schedule to validate that the data being migrated is accurate and complete. Yes a little cleaning is needed, you will want to plan this before the data is extracted. Allocating time to this process ensures that the data entering your new ERP application is accurate from day one.
Create a detailed transition plan
A detailed plan which describes all of the steps required for data migration during failover are an important part of a successful data migration.
A plan ensures that all dependencies are accounted for and that each team member knows when they are responsible for their part. Data migration can involve many people to perform all the tasks required of a migration, such as data extraction, data conversion, data upload into the new ERP application, manual entries and final validation Datas.
Perform test migrations
The best way to ensure that your data migration scripts work properly is to perform test data migrations. If you find any errors during this migration, they can be corrected and retested. It’s common to perform test migrations multiple times to ensure that the final migration to production is quick and successful.