ERP Data Migration Checklist: Moving Off Spreadsheets Without Losing Data

Most UAE companies moving to an ERP are not starting from nothing. They are moving off a mix of Excel workbooks, an older accounting package, shared folders and the knowledge in people's heads. That data is what makes the new system useful on day one, and it is also where many ERP projects run into trouble.

This checklist walks through the steps we follow when moving a business off spreadsheets and legacy software into Zoho, Odoo, ERPNext, Dynamics 365 or a custom ERP. It applies whatever platform you choose.

1. Define the migration scope

Start by deciding what moves, and what does not. Trying to bring everything across is the most common mistake.

• Master data: customers, suppliers, items, chart of accounts, price lists, employees, warehouses and cost centers.
• Open transactions: unpaid customer invoices, unpaid supplier bills, open sales and purchase orders, outstanding advances.
• Balances: trial balance, stock on hand with values, bank and cash balances.
• History: decide how much closed history you really need in the new system. Often summary totals are enough, with older detail kept in an archive.

Write the scope down and get finance and operations to sign it off. It becomes your reference when someone asks for "just one more" data set in week six.

2. Choose your cut-over date early

Pick a go-live date that lines up with a clean accounting boundary, ideally the start of a month and, if possible, the start of a VAT return period. Migrating mid-period means splitting VAT between two systems, which adds work and risk at filing time.

3. Cleanse the data before you move it

Spreadsheets accumulate problems over the years. Fix them at the source, not after loading.

• Remove duplicate customers and suppliers (the same company entered three slightly different ways).
• Check Tax Registration Numbers (TRNs) for VAT-registered customers and suppliers.
• Standardize item codes, units of measure and descriptions.
• Archive inactive items, customers and suppliers instead of migrating them.
• Fill gaps in mandatory fields such as emirate, country, payment terms and currency.
• Agree on naming conventions in English and, where needed, Arabic.

Assign an owner to each data set. Finance owns accounts and balances, sales owns customers and price lists, and the warehouse team owns items and stock.

4. Map old fields to the new system

Create a mapping document that lists every source column, the target field in the ERP, any transformation rules and who approved it. Pay particular attention to:

• The chart of accounts, which is often redesigned during an ERP project.
• Tax codes, so each line carries the right UAE VAT treatment (standard-rated, zero-rated, exempt or out of scope).
• Units of measure and conversion factors.
• Customer and supplier groups, payment terms and credit limits.
• Multi-currency fields and the exchange rates used at cut-over.

5. Prepare opening balances properly

Opening balances are where accountants spend most of their migration time, and for good reason.

• Close the old books for the period before cut-over and produce a final trial balance.
• Load receivables and payables as individual open invoices, not a single total, so you can track and collect them.
• Load stock quantities by item and warehouse, with an agreed valuation method.
• Reconcile bank balances against statements on the cut-over date.
• Use a temporary opening balance account and make sure it clears to zero once everything is loaded.

6. Handle VAT data with care

UAE VAT adds a few specific checks. Make sure customer and supplier TRNs are captured, tax codes are mapped correctly, and open invoices carry the VAT that was originally charged. If you migrate mid-period, agree how the VAT return for that period will be prepared and keep the supporting reports from both systems. Keep your old records accessible: the Federal Tax Authority expects businesses to retain tax records for a number of years, so archiving the legacy system or exports is not optional.

7. Run test loads

Never load straight into the live system. Plan at least two trial migrations into a test environment.

• The first test load usually exposes mapping errors, missing fields and format problems.
• The second should be a near-final rehearsal, timed so you know how long cut-over will take.
• Log every issue, fix it at the source or in the transformation rules, and reload.

8. Validate the results

Validation is a business task, not just an IT task. Ask the people who own each data set to check it.

• Compare record counts between source and target for every data set.
• Match the trial balance in the new system to the old one, account by account.
• Agree customer and supplier aging totals.
• Spot-check stock quantities and values for high-value items.
• Raise a test invoice, purchase and payment using migrated data to confirm it works end to end.

Get written sign-off from finance and operations before you move to production.

9. Plan the cut-over

Cut-over is usually a short, intense window, often over a weekend or at month-end. Write it as a dated, timed runbook with a named owner for every step, and share it with everyone involved at least a week in advance. Agree in advance who can make a go or no-go decision if something unexpected turns up, and how suppliers, customers and banks will be told about any changes to invoices, statements or payment details.

1. Freeze changes to master data in the old system.
2. Post final transactions and close the period.
3. Extract final balances and open items.
4. Run the production load using the rehearsed scripts and templates.
5. Validate again with the same checks as the test loads.
6. Switch users over and lock the old system to read-only.

Keep a simple rollback plan in case something critical fails, and make sure key users know what to do on the first morning.

10. Consider a parallel run

A parallel run means operating the old and new systems side by side for a short period and comparing results. It doubles the workload, so it is not always worth it. It makes most sense when payroll or complex costing is involved, or when the business has little tolerance for errors in the first month. For many SMEs, a well-tested cut-over plus close support in the first few weeks is enough.

After go-live

Expect questions and small data corrections in the first month. Keep the migration team available, review the first month-end close carefully, and file the first VAT return from the new system with extra checks. Proper user training and post-go-live support make a bigger difference here than most people expect.

If you are still choosing a platform, our comparison of Zoho, Odoo, ERPNext and Dynamics 365 may help. And if you would rather hand the work to a team that has done it before, see our ERP data migration services.