In this article
- Challenge: a technical load can still create a business failure
- What business ownership means in practice
- Approach: cleanse first, then load only approved data
- 1. Define the migration perimeter
- 2. Profile the data before cleansing it
- 3. Obtain signed business approval
- 4. Make reconciliation a go-live gate
- Results: business value measured beyond the import
- A principle worth remembering
- Frequently Asked Questions
- Who owns data migration in an Odoo ERP implementation?
- Should we migrate every legacy customer and product record?
- What must reconcile before go-live?
- How does tax localisation affect migration in Zimbabwe?
- Why business-owned migration pays off
A finance director sees a migration dashboard marked “complete”. Later that afternoon, the receivables team finds duplicate customer accounts, while opening balances do not agree with the general ledger. The records have moved, but the business is not ready to trust them.
That is where data migration responsibility becomes a business decision, not merely an IT milestone. For enterprises implementing Odoo ERP in Zimbabwe and across Africa, business teams must decide which records are valid, which history must be retained and whether the figures reconcile. The technical team manages extraction, transformation, loading, security and audit trails; it cannot decide which supplier is active or which customer record is authoritative.
Challenge: a technical load can still create a business failure
The most common mistake we see in ERP implementation planning is assigning migration to IT, then asking finance, sales, HR and operations to resolve data disputes during user acceptance testing. By then, the project has already carried old definitions and duplicate records into the new system.
Matching source and destination record counts does not prove data quality. Duplicate tax identities, incomplete customer details or fragmented accounts can survive a technically successful import. When that happens, credit control, reporting and collections inherit the same weaknesses in a new system.
What business ownership means in practice
Business ownership does not turn department heads into data engineers. It assigns a responsible person to each data domain with authority to settle the commercial questions that a technical import process cannot resolve.
| Data domain | Business owner decides | IT delivery team executes |
|---|---|---|
| Customers and suppliers | Duplicate survivor, active status, credit and tax attributes | Extracts, standardises, loads and logs changes |
| Products and stock codes | Valid code, unit of measure, replacement or archive decision | Maps codes and validates formats |
| Employees | Current employment record and required personal-data fields | Secures files, transforms data and controls access |
| Chart of accounts | Reporting structure, account mapping and opening balances | Loads mappings and produces reconciliation reports |
Decision rights should be documented before extraction starts.
Each domain needs an agreed source of truth. A sales spreadsheet, finance ledger and warehouse tool may describe the same customer or product differently. Without a named decision-maker, those conflicts simply move into go-live week.
Where personal data is involved, record who approved the data fields, cleansing rules, access rights, retention periods and any external-party involvement. Check current data-controller and data-protection-officer obligations before processing or transferring regulated information.
Zimbabwe’s data-protection framework places important accuracy, relevance and safeguarding obligations on organisations controlling personal data. Outsourcing migration tasks does not remove management’s responsibility to approve how employee, customer and supplier information is selected, corrected, secured and retained. Confirm applicable legal requirements and privacy controls with qualified advisers.
The same principle applies to tax records. ZIMRA expects taxpayers to maintain accurate registration details, including legal names, business contacts and tax-related classifications. The taxpayer-information update exercise in 2026 illustrated why consistent master data supports reliable compliance as well as day-to-day operations.
Approach: cleanse first, then load only approved data
SERPA approaches Odoo ERP migration as a controlled programme led by the business and executed with technical expertise. The sequence below makes data quality, accountability and readiness visible before cutover.
1. Define the migration perimeter
Agree which records will be migrated, retained in a controlled archive or securely disposed of before extraction. Review dormant customers, obsolete products, closed employee files and superseded supplier details.
Do not move every historical record simply because it can be exported. Retain what has an operational, reporting or legal purpose, apply appropriate retention rules and obtain compliance approval before deletion. A cleaner system should not come at the expense of statutory records or auditability.
2. Profile the data before cleansing it
Profile the source records for duplicates, missing identifiers, invalid contact details, inactive accounts, inconsistent product codes and conflicting ownership. Allocate each exception to a business steward with a decision date and escalation process.
Agree which record survives when sources disagree. If supplier records share a tax identifier but list different banking details, for example, the business must verify and approve the correct information. An analyst cleaning a spreadsheet should not make a supplier-payment control decision alone.
3. Obtain signed business approval
Business owners should formally approve the scope, data definitions, source of truth, survivorship rules and unresolved exceptions before loading. Signed approval makes clear who accepted the commercial meaning of the data being introduced into Odoo.
Migration-readiness reviews should test accuracy, master-data completeness, reconciliation, process coverage and user acceptance. Technical reports provide evidence, but finance, sales, procurement and operations must decide whether that evidence supports real business activity.
4. Make reconciliation a go-live gate
Reconcile during each test cycle and again before production cutover. A successful import report is not a substitute for signed financial and operational reconciliation.
Use the following control pack:
• Record counts by domain — identify missing records, duplicates introduced or records excluded without approval.
• Duplicate and identity checks — confirm that cleansing has resolved competing customer and supplier identities.
• Mandatory-field checks — confirm that tax identifiers, account owners and product units of measure are complete where required.
• Opening balances and ledger tie-outs — reconcile receivables, payables, inventory and other applicable sub-ledgers to the general ledger.
• Exception tracking — classify outstanding issues by severity, owner, age and business impact; set an escalation deadline before cutover.
• User acceptance and transaction tests — confirm that staff can complete real workflows and that rejected transactions are investigated.
If a domain has no accountable business owner, do not approve it for production loading. The implementation partner may move information, but it cannot accept the company’s tax, operational or privacy exposure on management’s behalf.
Results: business value measured beyond the import
The value of a disciplined migration is visible in day-to-day work: one reliable customer record, fewer disputed balances, cleaner stock information and management reports that teams can act on with confidence. These outcomes need evidence rather than a simple “migration completed” status.
A strong scorecard tracks data ownership, accuracy, reconciliation and users’ ability to complete real transactions. It also makes outstanding risks visible to executives early enough to resolve them before they affect customers, suppliers or reporting.
Consider a Zimbabwean distributor whose finance, warehouse and sales teams each use a different name for the same customer. IT can identify likely matches, but the credit manager and finance controller must approve the surviving customer record because the choice affects credit exposure, collections and tax documentation.
Once the business approves the customer master, the project team can load it into Odoo and reconcile opening receivables and payables to the general ledger. If significant exceptions remain unresolved, the steering committee should explicitly decide whether the affected data can safely go live or must be corrected first.
For the board, the migration dashboard should show who has approved each data domain; the state of duplicate and mandatory-field checks; unresolved reconciliation differences; the age of critical exceptions; user acceptance results; and transaction rejections after go-live. Together, these measures describe business readiness, not just technical progress.
A principle worth remembering
“A successful data load proves that records moved. A successful migration proves that the business can trust, reconcile and account for those records.”
Frequently Asked Questions
Who owns data migration in an Odoo ERP implementation?
The business owns data scope, definitions, quality decisions and reconciliation sign-off. IT and the implementation team execute extraction, cleansing processes, transformation, loading, security controls and audit trails. Both sides share delivery responsibility, but business approval cannot be outsourced.
Should we migrate every legacy customer and product record?
No. Migrate records needed for current operations, reporting or compliance. Archive or securely dispose of other records in line with approved retention and privacy requirements. Unnecessary legacy data can undermine the clarity and control the new ERP is meant to create.
What must reconcile before go-live?
Reconcile record counts, identifiers, mandatory fields, opening balances and applicable sub-ledgers to the general ledger. Review unresolved exceptions, user acceptance results and transaction tests before finance and operational owners sign off.
How does tax localisation affect migration in Zimbabwe?
Tax localisation depends on accurate legal identities, addresses, classifications and related taxpayer information. ZIMRA’s 2026 taxpayer-record update exercise is a reminder that master-data governance must continue after Odoo goes live.
Why business-owned migration pays off
• More reliable decisions. Reconciled opening balances and agreed master records give finance and operations a stronger basis for reporting and planning.
• Less operational friction. Consistent customer, supplier and stock data reduces duplicate work and helps teams complete transactions without avoidable corrections.
• Greater accountability. Named data stewards, documented approvals and a clear exception process make post-go-live support easier to manage.
• Better long-term control. Privacy, retention and tax-data checks become ongoing responsibilities rather than tasks abandoned after cutover.
Before fixing an Odoo ERP implementation date, book a SERPA ERP Readiness Audit. We can help your team assign data owners, review cleansing rules, design reconciliation checkpoints and identify the controls needed for a confident go-live. Request a tailored implementation consultation and quotation.