A new ERP or CRM is only as good as the data inside it. Yet migration is often treated as a task for the last fortnight, squeezed in after configuration and training. That is how opening balances end up wrong, customers appear three times and invoice history quietly vanishes. Done properly, migration is a project of its own, with a plan, rehearsals and proof.
Start by knowing what you have
List every source of data the new system will replace: the old accounting package, the stock spreadsheet, the CRM export, the shared mailbox where purchase orders live. For each one, note who owns it, how many records it holds, how far back it goes and how it is accessed. Old on-premise systems in particular can hide surprises, such as custom tables or fields that nobody documented.
Then decide what actually needs to move. Master data such as customers, suppliers, products and the chart of accounts almost always does. Open transactions, like unpaid invoices and open orders, must move too. Full transaction history is a choice: many businesses migrate two or three years and archive the rest in a read-only database they can still search.
Retention rules shape that choice. UAE VAT records generally need keeping for at least five years, and real-estate records for longer, so archived data must remain retrievable. Personal data falls under the UAE and Saudi data protection laws, so migration is also a good moment to delete records you no longer have a reason to hold.
Give the migration a named owner on the business side as well as a technical lead. The owner decides what is in scope, chases colleagues for cleansing work and signs off each trial. Without that person, questions such as whether to keep customers who haven’t ordered since 2019 bounce around for weeks while the timeline slips.
Map, clean and rehearse
Mapping means deciding, field by field, where each piece of old data lands in the new system and how it is transformed on the way. Old product codes might be split into a code and a variant; free-text city names become a fixed list; two payment-terms fields merge into one. Write the mapping down in a shared document that business owners sign off, not just the developers.
Clean data in the old system before you move it, not after. Merge duplicate customers, fix missing tax registration numbers, retire products you stopped selling years ago, and standardise phone numbers to international format. Cleansing is tedious, and it needs people who know the business, but every hour spent here saves several hours of confusion after go-live.
Use repeatable scripts or a proper ETL tool rather than manual copy and paste. Whether that means Python, the new platform’s own import tools or a service such as Azure Data Factory or AWS Glue, each run should produce exactly the same result. Repeatable loads make trial migrations cheap, so you can rerun them as often as you need while fixes go in.
Financial data needs special care. Rather than replaying years of journal entries, most projects migrate a trial balance at a cut-off date, plus open receivables and payables invoice by invoice so they can be collected and paid in the new system. Agree the cut-off date and approach with your accountant and auditor early, because they will need to follow the trail.
Never let go-live be the first full migration. Run at least two complete trial loads into a test environment and ask real users to work through their daily tasks on the migrated data. Each trial uncovers new problems, from character encoding that mangles Arabic names to dates that flip between day-month and month-day formats.
Planning the cutover
Pick a cutover date with the calendar in mind: a quiet weekend after a month-end close is ideal, while Ramadan evenings, White Friday or the run-up to Eid are poor choices for retailers. Freeze changes in the old system at an agreed time, take a final backup, run the scripts you rehearsed and record exactly how long each step takes.
Write a rollback plan too. If the reconciliation fails at three in the morning, everyone should know who makes the call to revert, and how the old system comes back online. You will probably never need it, but having one keeps decisions calm instead of rushed.
Tell customers, suppliers and staff what to expect. A short note that ordering or invoicing may pause for a day, a reminder to staff about new logins, and a chat channel for go-live questions prevent many small panics. Make sure the people answering those questions are rested and available, not the same engineers who ran the overnight load.
Proving nothing is lost
- Record counts — the number of customers, products and open invoices should match source and target, allowing for agreed exclusions.
- Financial totals — trial balance, receivables and payables must reconcile to the last fils or paisa.
- Stock values — quantity and value per warehouse should match the final count.
- Spot checks — users pick twenty real records each and compare them side by side.
A migration isn’t finished when the data has moved. It is finished when the numbers reconcile and users trust them.
Document every check and its result, including the exceptions you accepted and why. That record reassures management and auditors, and it becomes invaluable months later when someone asks why a particular customer balance differs from the old system. In our experience, teams that keep this evidence have far calmer first audits on their new platform.
The bottom line
Safe data migration comes down to preparation: know your sources, decide what moves and what is archived, map and clean carefully, rehearse with full trial loads, and prove the result with counts, totals and spot checks. Allow six to twelve weeks for a typical mid-sized business, start early in the wider project, and give migration an owner who will not let it slide.
