The direct answer: do not begin an Odoo migration with file uploads alone. First define the authoritative source for each dataset, assign business owners, design access around real responsibilities, decide which external systems must exchange data, clean records under approved rules, and test a complete business process. A technically successful import is not proof of operational readiness.
Migration changes how customer, supplier, item, employee, balance, and transaction data will be used across the business. Duplicate records, unclear ownership, and inconsistent labels do not disappear when moved into Odoo. They become part of the new operating environment.
Why copying files is not enough
Data in Odoo participates in connected processes. A customer record may affect an order, invoice, and report. An item may be used by sales, purchasing, and inventory. Preparing columns is therefore only one part of the job; relationships, ownership, access, and expected outcomes also need review.
An import can pass its technical checks while the first live transaction exposes a gap: a user cannot see a required record, someone can edit approved data, an approval is bypassed, or a report depends on an incomplete field.
1. Which source is authoritative for each dataset?
List the data groups in scope, such as customers, suppliers, items, services, balances, invoices, employees, and internal entities. For each group, record the file or system the business accepts as authoritative.
When several files contain the same records
Do not select a source based on its filename or date alone. The team closest to the process should identify the usable source, and an authorised business owner should approve the decision. If several sources must be combined, document the matching key and transformation rule.
| Data group | Decision needed before migration | Typical business owner |
|---|---|---|
| Customers and suppliers | Approved record, duplicate handling, required fields | Process owner and authorised reviewer |
| Items and services | Stable code, naming, unit, and required classification | Sales, purchasing, or operations, depending on use |
| Balances and invoices | Approved scope and cut-off point | Authorised finance team |
| Employees and internal entities | Necessary fields and permitted access | HR and authorised management |
| Reports and indicators | Fields, definition, and approval responsibility | Report owner and consuming management team |
These assignments are examples. Each company should adapt ownership to its organisation and policies.
2. Who reviews, approves, and corrects the data?
File availability is not the same as data ownership. Assign responsibility for checking completeness, approving the migration-ready version, and correcting issues. One person may hold several roles in a smaller business, but the responsibility should still be explicit.
Keep a short decision log for exclusions, duplicate handling, mandatory fields, historical scope, and sample approval. Corrections should be reflected in the source preparation or repeatable transformation rule, not left as one-off edits in a test database.
3. What access does each team need?
Permissions should follow business responsibilities. Start with the real process and identify who creates, reviews, approves, edits after approval, and reads each type of record. Include company, branch, or team restrictions where they apply.
Test with representative user roles
An administrator account cannot demonstrate that everyday access is correct. Use test users that represent the actual roles and run the same process with them. Each user should be able to complete the assigned task without receiving unnecessarily broad access simply to make the test easier.
4. Should integration come before customisation?
When a core process begins in one system and finishes in another, first decide how the data will move. A disconnected source may be the real problem, while a proposed Odoo customisation only compensates for manual re-entry.
Examples include an online store separated from accounting, attendance separated from HR, or a sales system whose transactions do not reach invoicing or inventory as required.
Before approving an integration, define the owner of each data element, the direction and timing of transfer, and how failures or duplicates will be handled. Not every system must connect in phase one. Prioritise dependencies that support a core process or prevent conflicting records and repeated entry.
5. What should be cleaned before migration?
Review unused records, duplicate candidates, inconsistent labels, missing required values, and fields used by reports or approvals. Similar names are not sufficient grounds to merge records; the authorised data owner must confirm the decision.
Pre-migration cleaning checklist
- Inventory the source files and systems in scope.
- Define a stable identifier or approved matching rule.
- Review duplicate candidates before merging or excluding them.
- Standardise approved reference values and labels.
- Define mandatory fields for each data group.
- Record exclusions and the reason for each exclusion.
- Review fields used by reports and approvals.
- Obtain data-owner approval for the cleaned sample.
6. What must be tested before go-live?
Test an end-to-end business process, not just whether imported records open. Use a representative sample, complete the entry, review, approval, and reporting steps, and repeat the test after correcting the cause of any issue.
| Test area | Acceptance question |
|---|---|
| Data | Did the required fields and relationships arrive without unapproved duplication? |
| Permissions | Can each role perform only its intended responsibilities? |
| Approvals | Does the request follow the agreed approval path? |
| Integrations | Does required data move correctly, and are failures visible? |
| Reports | Does the transaction appear under the approved report definition? |
| Correction | Was the source or transformation rule fixed and retested? |
Go-live readiness gate
- Historical scope and exclusions are approved.
- Data owners approve the sources and cleaning rules.
- Access is tested with representative user accounts.
- At least one complete process is tested end to end.
- Report outcomes are reviewed by their owners.
- Pilot errors and corrections are documented.
- The process is retested after correction.
- Go-live and initial support responsibilities are assigned.
How does this affect AI readiness in ERP?
AI features may assist with summarisation, information retrieval, and selected supporting tasks. Their usefulness still depends on reliable data, clear permissions, and connected sources. AI should not be treated as a substitute for deciding which source is authoritative or who may access and change the information.
Frequently Asked Questions
Should every historical record be migrated?
Not necessarily. The appropriate scope may be full history, a defined period, or master data and opening balances. The decision depends on operational and accounting needs, review requirements, and source quality, and should be approved by the authorised owners.
Who decides which data source is correct?
The team closest to the process should identify the practical source, with explicit approval from the appropriate business owner. Conflicts should be resolved through a documented rule, not left to the migration operator.
Should permissions be defined before or after migration?
They should be designed and tested before go-live, preferably early enough to inform data review and process testing.
When is an integration needed from the start?
When a core process depends on multiple systems, or separation creates repeated entry, delays, or conflicting data. Other integrations can be sequenced according to the approved implementation scope.
How should migration readiness be tested?
Import a representative sample, complete a real process using representative roles, verify data, permissions, approvals, integrations, and reports, then correct the repeatable rule and test again before sign-off.
Call to Action
If your company is preparing to migrate data to Odoo, ask Neyar Solutions for an initial review of data sources, user permissions, and integration dependencies. The review can help your team identify unresolved decisions, define a practical pilot sample, and prepare a clearer route to go-live.
