ERP Data Migration: A Six-Week Cutover Plan

More than half of ERP projects are delayed by data quality. Moving junk data to a new system just speeds up the junk. Below is a six-week migration plan for a mid-sized company.

Week 1: Scope and inventory

Decide which data will move: open items, current balances, active item cards. Detailed movements for closed years are usually not migrated; they are kept as archive reports.

Week 2: Data cleansing

• Merge duplicate customer cards (same tax number, different spelling).
• Complete missing tax numbers, addresses and phone numbers.
• Deactivate unused item cards and standardise units and barcodes.

Week 3: Template mapping and first test migration

Old-system columns are mapped to Düzlem templates. The first migration to the test environment is made; trial balance and stock value are compared with the old system. A list of expected differences is kept.

Week 4: Reconciliation and fixes

Customer balances, open invoices, cheque/note portfolio and stock quantities are verified line by line. Sources of difference (rounding, exchange rate, period cut-off) are documented.

Week 5: User acceptance testing and training

Super users test their own scenarios: order, waybill, invoice, collection, month-end close. Training is completed.

Week 6: Cutover

A month-end or period-end cut-off date is chosen. Final balances are migrated and the old system is made read-only. Intensive support (hypercare) is planned for the first two weeks. A rollback plan is kept ready.

Success criteria

• Trial balance equals the old system to the last kuruş
• Stock value difference below 0.5%
• First month-end close shorter than five working days

You can download our migration templates from the documentation section and arrange a free migration analysis call with our implementation consultant.

Common mistakes

• Migrating without cleansing: the same customer stays on four different cards and reports mislead.
• Moving balances but forgetting open items; collection tracking becomes difficult from the start.
• Running the test migration only once; at least two rounds are needed.
• Scheduling go-live mid-month, which makes reconciliation harder.
• Going live without training users.

Assigning a data owner (usually the chief accountant) to the project team prevents half of the errors.