When implementing a new ERP system or expanding an existing ERP system into a new business area, there is bound to be some degree of data migration involved. A variety of data must be created, much of which may be based on existing systems, spreadsheets, etc. and this rarely happens without challenges, because as ERP systems expand their functionality, so do the data requirements. The structure and requirements for data are rarely the same from one ERP system to another, so it takes a lot of hard work to strategise, map and transfer the data so that it is accurate and adds value.
Read on as we talk to some of our experienced data migration consultants for advice and guidance on how to achieve a successful data migration.
The process for a good data migration process for new IFS implementations
Distribution of roles
One of the first things you need to decide is whether you as a business want to migrate in-house or externally. There is no one right answer, as this depends on the resources and competences you have in-house. A constellation we at Curit often experience is a hybrid where the customer provides extracts from existing systems and Curit takes care of migrating these extracts into IFS.
Once that decision has been made, a process for how the migration will be organised. The plan for this is introduced to consultants and project participants so there is no doubt about what is expected of them.
Mapping data from old to new systems is often the biggest part of the work, and a close dialogue between the consultant and the business is important to know how the business processes should be in the new system, as these can affect the data requirements and vice versa.
Types of data and mapping
The next step is for the groups to identify which data to create. Here we distinguish between basic data, master data and transactional data:
- Basic data includes setups and value lists that are used in subsequent master data. For example, product groups or VAT codes.
- Master data is data that typically comes from an existing system and where there are so many records that it is not worth entering it manually. For example, customers, suppliers and goods. There are many screens, tabs and fields involved, and the order in which they are loaded can be important. Often this will require you to try a manual creation to see if it is feasible or if basic data is missing. When you succeed manually, the litmus test is passed and the dataset is ready for automatic loading.
- Transactional data is living data that is often very time sensitive. It can be further divided into Historical data and Open records:
- Historical data: This could be old closed purchase orders, etc. This type of closed records will not be included in the new system.
- Open records: When switching to a new ERP system, this type of data is usually the last thing to be migrated just before the new system goes live. An example of open records is inventory.
The next step, after identifying which data should be migrated in which way and in which order, is for the migration consultant to create templates for the data that has been identified and hand these over to the consultants for the different groups. Now the actual mapping can begin, where the consultant and the business jointly map existing data to the data fields in the new system. This is where the hard work needs to be done, but it is also the foundation for the rest of the process to be correct and to keep the iterations of data migration to a minimum.
During the mapping process, you will encounter fields that cannot be transferred directly to the new system, but need further processing first, or conversely, fields that are mandatory in the new system, but for which you did not have any values before. These scenarios are where it can be extra challenging and where it's important to have a close dialogue with the business to make the right decision.
Out of the old, into the IFS
Once the mapping is complete, it is handed over to the customer's IT manager, who creates the extracts from the existing system. These can then be migrated into IFS, and then the project teams can start testing their business flows to see if the interaction between data and processes actually works as predicted on the drawing board.
Best practice is always to run the migration on a test environment at least once and test it thoroughly before migrating to the real environment. If the data quality is not good enough from the start, it can have major consequences for a company, which is why migration remains a critical part of implementing a new ERP system.
Other data migration tasks
Migration is of course an important part of a new implementation, but it's also important to remember that the tool can be used for many other smaller ad hoc tasks as well. For example, when the business needs all sales prices to increase with 10% or when you get a new supplier and want to create a larger quantity of their goods in your ERP system.
In IFS, in addition to the migration tool in the application itself, there is also a simpler version that you can use directly from Excel. This means that you can sit with your data that you want to update in IFS, correct and validate, before you finally perform the action that starts the actual migration. Quick and easy for the smaller tasks that arise in the business on an ongoing basis.
If you are facing a major or minor migration task and would like some sparring in this connection, you are very welcome to contact us.
Get in touch with us:
