Moving From Spreadsheets to a New System: Data Migration Without Surprises
Moving your data into a new system is a project of its own, and it should start in the first week, not the last. List every source; decide what actually needs to move, usually active records and opening balances, with closed history archived; clean the data where it lives; map each old field to the new system; run trial loads into a test copy; and reconcile counts and totals with the people who know the records. Only then plan the final load at cut-over, and keep the old data readable for as long as the law requires.
Most of the work is not technical. Developers can move data; only your staff can say whether it is right.
The short answer
- Start early. Migration runs alongside the build and is often the last thing to finish.
- Migrate less. Active customers, open orders and invoices, current stock and opening balances. Archive the rest.
- Clean at the source, before extraction, so errors do not come back with the next export.
- Map and sign off every field, with the business owner of each kind of record.
- Rehearse. Trial loads into a test system, checked and reconciled, more than once.
- Keep the old data readable and secure for the retention period.
“Data migration is a business task wearing a technical costume. Developers move the data; only your people can tell you whether it’s right.” — Abdulqader Wahiba, founder and CEO of ZAWAT
Step 1: list every source
Write down everywhere the data lives today: the old system, spreadsheets on shared drives and personal laptops, paper files, email attachments, the phone contacts of a salesperson. For each source, note what it contains, roughly how many records, who maintains it and how reliable it is. Expect surprises: the most important customer list in the company is often a spreadsheet one person keeps up to date.
Step 2: decide what moves, and what is archived
Moving everything feels safe and is usually a mistake. Old, closed records carry old errors and old formats, and they make every trial load slower. A typical split:
| Data | Usually migrate? | How to check it |
|---|---|---|
| Active customers and suppliers | Yes, cleaned | Owners review samples; duplicates resolved |
| Open orders, invoices and payables | Yes | Totals match the old system |
| Opening balances | Yes, at a period end | Tie to the trial balance |
| Current stock | Yes, after a count | Quantities and values match the count |
| Price lists and products | Yes, cleaned | Sales and purchasing review |
| Closed history | Usually archived, readable | Archive opens and searches |
| Old staff and customer personal data no longer needed | No | Disposed of properly, subject to retention rules |
Replacing a legacy system without stopping the business makes the same case for migrating less than you think.
Step 3: clean the data where it lives
Fix problems in the source before you extract, so that a second extract does not bring them back:
- Duplicates: the same customer under different spellings, or with and without a branch name.
- Names in two scripts: Arabic and Latin versions of the same name, entered inconsistently.
- Formats: phone numbers with and without the country code, dates written different ways, mixed Arabic-Indic and Western digits.
- Missing values: customers without contact details, products without categories or units.
- Definitions: what counts as an “active” customer, agreed before you filter on it.
Is your data ready for AI? describes a sampling method that works just as well for migration: take a random sample, count the errors, and fix the causes, not just the examples.
Step 4: map old fields to new ones
For each kind of record, write down how every old field becomes a new one: which field it goes to, how it is transformed, what default applies when it is empty, and how old codes translate to new ones. Old customer categories, payment terms and units of measure rarely line up neatly.
Have the business owner of each record type sign off the mapping. That signature matters: it turns a technical document into an agreement about what the business considers correct.
Step 5: rehearse with trial loads
Load the data into a test copy of the new system, not the live one, and let the people who use the records check it. Plan for at least two rehearsals; the first always finds problems in the mapping and the cleaning. Each rehearsal should be timed, so you know how long the final load will take on cut-over day.
Step 6: reconcile, with numbers and people
Abdulqader Wahiba’s rule is that a migration is finished when it reconciles, not when the import script runs without errors:
- Counts: the number of customers, products, open invoices and so on, compared with the source.
- Totals: receivables, payables and stock value match the old system to the last baisa.
- Balances: opening balances tie to the trial balance at the cut-over date.
- Spot checks: for each record type, staff check a sample of records they know well, including some difficult ones.
Choose a period end, such as a month end, for the financial cut-over. It makes balances far easier to agree.
Step 7: plan the cut-over
Write a short plan with dates and owners: when the old system stops accepting changes, when the final extract is taken, when the load runs, who reconciles, and who makes the go or no-go decision. Include a fallback: what happens if reconciliation fails. Tell staff and, where relevant, customers in advance.
Step 8: keep the old data, safely
The old records do not stop mattering at cut-over. Under Article 70 of the VAT Law, tax invoices and accounting records must be kept for ten years after the end of the tax year of the return, and fifteen years for real estate. Keep an archive that stays readable and searchable for that period, with access limited to the people who need it.
Personal data needs the opposite care. Oman’s Personal Data Protection Law, as amended by Royal Decree 68/2026, requires personal data to be erased once the purpose of processing ends, except where there is an existing dispute or a legal obligation to keep it. A migration is a good moment to stop carrying personal data you no longer need, within the retention rules that do apply.
Frequently asked questions
Should we migrate all our historical data? Usually not. Migrate what the business needs to operate, and archive closed history in a readable form. Full history slows every trial load and carries old errors into the new system.
Who should check the migrated data? The people who own and use each kind of record: sales for customers, finance for balances, the warehouse for stock. IT and the supplier run the process; the business confirms the result.
How long does data migration take? It depends on the number of sources and how clean they are. Starting in the first week of the project and rehearsing at least twice is what keeps it off the critical path.
Can we migrate in phases? Yes, if the new system goes live in phases, for example one branch or one process at a time. Each phase still needs its own trial load and reconciliation.
What if the old system can’t export its data? Most systems can export something, through reports, database access or a vendor service. Check this in the first week. If the vendor controls the export, start that conversation early, and check your contract for data return terms.
Sources: Value Added Tax Law, Royal Decree 121/2020, Article 70 · Personal Data Protection Law, Royal Decree 6/2022, as amended by Royal Decree 68/2026, Article 15
This article states the position under the laws in force on 9 November 2026, the date of publication, and is not legal or tax advice.
Moving from spreadsheets or an old system? ZAWAT can plan your migration alongside the business system build, from the first week, with your staff reconciling the result. Book a call.