Most migrations that go badly do not fail on the software. They fail on the data, and the failure was already in place before anyone touched the new system.
The good news is that data preparation is the part of the project you can start before your implementation partner arrives, and doing it well shortens everything that follows.
Decide what actually moves
The single biggest misconception is that a migration means bringing everything across.
It does not, and no major ERP vendor recommends it. NetSuite's own documentation advises against loading a complete transaction history. SAP's migration approach moves balances and open items rather than historical documents. Microsoft's reimplementation path is explicitly described as migrating only master data, opening balances and setup.
What moves is:
- Master data: customers, suppliers, products, chart of accounts, employees
- Opening balances: your trial balance at a chosen cutover date
- Open items: unpaid invoices, unpaid bills, open purchase and sales orders, stock on hand
What generally does not move is closed historical transactions. Those stay in the old system, or in an export, as your archive.
This matters in Saudi Arabia specifically, because your retention obligation does not disappear when your software changes. More on that below.
Clean the master data first, and let the business own it
Master data cleansing is where the real work sits, and it is worth being clear about who does it.
The people who should clean these records are not in IT. They are the departments that own them. Sales knows which customers are defunct. Procurement knows which suppliers are duplicates. Only the warehouse can say whether two product codes are genuinely the same item.
Duplicates are the most common problem. They come in two kinds. The obvious sort, where the same customer exists three times because of a spelling variation. And the subtler sort, where two product records describe the same physical item under different codes from different eras.
Obsolete records are the second. Customers who stopped buying years ago, suppliers you no longer use, products you no longer sell. Migrating them means paying to carry them forever and cluttering every search your team runs.
Missing and inconsistent fields are the third. Blank descriptions, no common naming convention, units of measure recorded three different ways.
Odoo includes a Data Cleaning app for deduplication and formatting, which helps. But it can only merge what you tell it to merge. The judgement stays with your team.
One practical tip that saves real pain: keep each record's identifier from the old system and load it into Odoo as the External ID. Re-imports then update records instead of duplicating them, and relationships between records rebuild correctly. It is worth knowing that Odoo imports are permanent and cannot be undone, which is another reason to get the identifiers right before loading anything.
Settle the chart of accounts before you touch balances
This is the step most likely to cause a schedule overrun, and the reason is organisational rather than technical.
A migration is the natural moment to standardise a chart of accounts that has grown organically. That means people who have used their own account codes for years have to agree on shared ones, and that agreement takes longer than anyone plans for.
Do it anyway, and do it before balances load. In Odoo, the account type drives fiscal year closing and the generation of opening entries, so the mapping has to be settled before any balance is imported. Revisiting it afterwards means redoing the load.
Get the opening balances right
The approach is consistent across every major ERP.
Pick a cutover date that aligns with a period end. Mid-period cutovers create reconciliation work that serves no purpose.
Take the trial balance from the old system in debit and credit format at that date. This is your source of truth for the load.
Journal the balance-sheet accounts against an opening balance equity account, which nets to zero once everything is in.
Load open items at document level, not as a net balance. Every unpaid customer invoice and unpaid supplier bill goes in individually, with its own reference and due date. If you load a single net receivable figure, you lose the ability to chase specific invoices or age your debt, which is most of the point.
Clear what you can before you move. Settle open items, clear outstanding cheques, and resolve open tax items in the old system. Every one you clear beforehand is one you do not migrate, reconcile and explain.
A detail that catches people out: inventory valuation has to be in place before stock quantities load, because the system values the stock posting using the cost data on the product record. And because valuation keeps moving until cutover, stock is normally one of the last things migrated, not one of the first.
What Saudi record-keeping actually requires
This is where a migration can create a compliance problem if nobody checks, and where a lot of published guidance is wrong.
Under Article 66 of the VAT Implementing Regulations, invoices, books, records and accounting documents must be kept for a minimum of six years from the end of the tax period they relate to.
Capital assets are different, and this is the part commonly misreported. The requirement is the adjustment period under Article 52 plus five years, running from the date the asset was acquired, not from the end of a tax period. Article 52 sets the adjustment period at six years for movable capital assets and ten years for immovable ones permanently attached to land or real estate.
So the actual retention periods are:
| Record type | Minimum retention |
|---|---|
| Invoices, books, records, accounting documents | 6 years from the end of the relevant tax period |
| Movable capital assets | 11 years from acquisition |
| Immovable and real-estate capital assets | 15 years from acquisition |
You will see "11 years for real-estate records" repeated across a number of accounting websites. On the primary text that is incorrect: eleven years is the movable figure, and immovable assets attract a ten-year adjustment period, giving fifteen.
Two further requirements shape how you archive:
Records must be kept in Arabic, and tax invoices must be issued in Arabic in addition to any other language.
Records must be kept in the Kingdom, either physically or electronically, accessible from a terminal or access point inside Saudi Arabia. ZATCA may review the systems and programs used.
The practical consequence for a migration is simple. If you are not bringing history into the new system, you still need that history retained, in Arabic, reachable from inside the Kingdom, for the periods above. Switching off the old system on go-live day without an archive plan is where this goes wrong.
A realistic sequence
- Decide the cutover date, aligned to a period end
- Extract master data and give each list to the department that owns it
- Deduplicate and retire obsolete records, in the business, not in IT
- Agree the chart of accounts and get it signed off
- Clear what you can in the old system: open items, outstanding cheques, open tax items
- Load master data with external IDs preserved
- Load opening balances from the trial balance at cutover
- Load open items individually, at document level
- Load inventory late, once valuation is final
- Reconcile before go-live: record counts, customer balances, stock, open orders, signed off by your team
- Plan the archive for everything you did not migrate, per Article 66
Steps 2 to 5 are yours, and they are the ones that determine how the rest goes. A partner can run the loads. Only your team can decide which of two customer records is the real one.