12 cloud ERP data migration best practices

Data migration is a key component to any successful cloud ERP implementation. As the project leader, you'll want to properly scope and staff a data migration early on.

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 to determine what data to migrate.

To ensure you identify all the in-scope data, identify all the current applications the ERP implementation affects. Then identify all the applications your new ERP system will replace. If you are replacing more than one application, then you may have to migrate data from multiple applications.

Review upload template early

In order to upload data into the new ERP application, you will have 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 evaluate the complexity of the required formatting.

Understand data mapping complexities

As part of the data mapping process, you will also have to consider the data types in each system. For example, you may have a customer ID in one application that accepts alphanumeric characters whereas the other application only accepts numeric characters. In this case, you will have to decide how you accommodate this difference during the mapping and migration process.

Decide on migration parameters

Most project leaders choose to migrate only some data to the new cloud ERP system. There are many reasons for this.

For example, the volume of data is significant and will be time-consuming to migrate, the data is old and not relevant going forward or migrating all data is cost-prohibitive. For these reasons, project leaders typically choose to migrate only data that falls after a specific date. For example, teams should migrate only data entered after January 1, 2020. You may also want to add other parameters, such as whether teams should migrate data for vendors that are no longer supplying your organization.

Plan for new data

The data migration process is also a good time to consider new data you plan to capture in your new ERP system and how it will affect the data load into the new ERP.

If this data did not exist in your old system and is required in your new ERP, you may have to create it during the migration process. This could be a status field, a new date field or something else that will be required in your new application.

Address what to do with data that's not migrated

If you decide to migrate only some data, you will have to determine what happens with the data left in your old ERP application. The following are a few options:

• If you will still have access to the old ERP, you may want to set everyone's permissions to read-only. This will block new entries but ensure that you can reference the old data when it's needed. Your legacy ERP vendor may offer a reduced fee for continued access to the application if it exists in read-only mode.
• If you don't anticipate needing the data going forward, you may want to simply archive the data to spreadsheets for future reference. Before choosing this option, consider the volume of data the old ERP contains and the complexity of the data. These factors help determine whether using a spreadsheet is a viable option.
• As a third option, you may want to set up a database to store the data. This can be useful if you believe you will need access to the data from time to time but not on a regular basis. This will become a small project of its own, since someone will have to set up a database and migrate all the data that wasn't migrated to the new ERP system. You may also have to develop a small application or reports to simplify extracting data from the database.

Plan for the cutover timeline and for dual entry

An important decision is to determine on what date and at what time you will start to migrate data from the old ERP to your new one. Employees may need to continue entering data in the old ERP application so they can run the business after you've extracted the data. You'll need to manually enter into the new ERP system anything entered in the old one after the data extraction takes place.

Extracting, formatting and importing data into the new ERP application can take days or weeks. The longer it takes, the more dual 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 setting the schedule for the cutover, consider the impact it may have on other applications or processes that are dependent on the data in the old ERP application. For example, the finance team may need access to data at the month's end. They cannot be locked out of your old ERP for long.

Plan for manual data entry

While you'll automate as much of the data migration as possible, you may find situations that don't warrant the investment in time and effort to automate the migration. For example, you may have five vendors that have an exception to the rule. Rather than building out the conversion scripts for five vendors, it may be easier to manually enter them or edit their data in your new application 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. If some cleanup is required, you'll want to schedule that in advance of the data extract. Allocating time for this process ensures that the data going into your new ERP application is accurate from day one.

Create detailed cutover plan

A detailed plan that outlines all the steps required for the data migration at cutover is an important component of a successful data migration.

A plan ensures all dependencies are considered and everyone on the team knows when they are responsible for their part. Data migration may 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 data validation.

Perform test migrations

The best way to ensure your data migration scripts are working correctly is to perform test data migrations. If you find errors during this migration, they can be corrected and retested. It is common to perform test migrations more than once to feel confident that the final migration to production is quick and successful.