How is an ERP migration done? Data migration, parallel run and go-live steps

Friday evening. Which program will the person entering new orders on Monday morning open? Which system will the warehouse count be posted to? Are the open orders in the old program in the new system? These questions are usually asked right before the switch, in the last meeting, and nobody has the answers. The hard part of an ERP migration is not installing the software but answering these questions beforehand; go-live day is the most expensive time to look for answers. An ERP migration is the process by which a business moves its sales, purchasing, stock, production and finance processes from old tools (Excel, an old program, paper) to a new ERP system, carrying the data and the working habits along with it.

If the stages below are followed in order, the migration is not squeezed into a single risky weekend. Let us say up front that durations vary by project; this article promises no calendar, it explains how you will know what is finished at each stage.

ERP migration stages and the exit criterion for each stage

How do we move stock and account data from the old program to the new ERP?

Before moving data, also decide what you will leave behind in the old program. If inactive stock cards accumulated over the years, accounts that will never be worked with again and closed orders are moved to the new system, lists get crowded, search slows down and users pick the wrong card. Historical records can remain read-only in the old system; only data that will be useful from today on goes into the new system.

First decide what will be moved, then how. Each type of data carries a different risk; the table below summarizes the most commonly moved data and how to check each.

The rule is simple: wherever you move numbers, put the totals before and after the move side by side. If quantity, balance or record count does not match, do not count the transfer as finished.

Importing Excel data into an ERP: automation or by hand?

For a one-time import from Excel, a properly prepared template is often enough: fixed column headers, a unique code on each row, units and categories spelled one way. If the volume is small, the import can be done from the import screen; if the volume is large, the codes are inconsistent or data from several files will be merged, writing an import script may be necessary. The method is set per project; we do not promise a ready-made migration tool or a timeline. A file that flows into the ERP regularly (for example, importing a daily Excel output every morning) is a separate matter from a one-time move: it is an integration matter.

How are the parallel run and go-live managed?

A parallel run means carrying out the same transactions in the new system for a set period and comparing the results with the old method. It takes extra effort; in return it gives confidence in critical calculations such as month-end close and stock and account balances. It is not needed in every business, but it should be considered for processes where the cost of error is high. On go-live day the order is:

1. The final data cut is taken, and from that moment no new records are entered into the old system.
2. Opening balances, stock and open orders are loaded into the new system.
3. The control totals are compared with the old records; if there is a difference, the system does not go live.
4. The old system is made read-only; it stays in the archive for retrospective queries.
5. On the first day, a support person stands by for each role.
6. Rollback conditions are written down from the start: in which case, who decides, and how to go back.

How do you prepare users for the migration?

Even if the technical part of the migration is done right, the system stays empty if users go back to old habits. Plan these four things for preparation:

• Role-based trial: Let the warehouse worker, the buyer and the sales rep each do their own real work from start to finish in the test environment.
• Closing the old habit: After go-live, state clearly that the old Excel files will no longer be updated and that the new system is the place of record.
• A support point for the first period: Name a single person or channel where questions are collected; it keeps the same question from coming in from ten people.
• A feedback loop: List the gaps and adaptation requests that appear in the first period, and put them in priority order.

Go-live is not an end but the first measuring point. Verifying once more at the end of the first period that the stock count, open orders and account balances match the system is the cheapest way to catch the remaining errors while they are small.

Managing the migration with Excel: where does it work, where is it not enough?

Keeping the migration plan, the field-mapping table and the difference list in Excel works perfectly well; everyone knows the tool and it needs no extra setup. The places where it struggles are clear:

• Versions of the mapping table multiply, and which one is current gets confused.
• Data owners clean their own files separately, and merging them becomes a job of its own.
• As the difference list grows, it cannot be tracked who closed what.
• If the trial transfer is done by hand every time it is repeated, human error gets into the transfer itself.

How do YazSis ERP and the integration side handle migration?

One of the principles on the YazSis ERP page is keeping the existing system: missing processes are completed without ripping out a working ERP, and data is joined through API and database integrations. So not every migration has to take the form “close the old completely, open the new”; for some businesses a gradual path carries less risk. The scope is set by needs analysis in each project.

The Integration page describes joining ERP and accounting, payroll and time-and-attendance (PDKS), CRM and e-commerce, bank, production and warehouse, and SMS and e-mail systems in a controlled data flow. Four principles also fit a migration plan: identifying a single reliable source for each data field, designing the direction, frequency and error scenarios of the flow, setting up logs, permissions, retries and data validation, and making the health of the integration visible. If both systems keep records for the same field during the migration period, the question “which one is right?” comes up; that is why the single-source principle is also the first item of the migration plan.

If you want to assess your ERP migration scope and data-migration need together, you can request a meeting from the ERP and Integration pages.