A CRM implementation should prove that the intended records, relationships and user access work together before the team adopts the new process. Begin with a small representative migration and a written acceptance sheet. Test corrections and restricted accounts as well as successful imports, then use the findings to define the remaining rollout work.
The most useful first migration is a carefully chosen slice of the business process. It might contain an organisation, its contact, a responsible salesperson and an enquiry. That combination exposes relationship and ownership questions which a list of isolated names can hide. Ask the business owner to explain what each record means before mapping it into the new system.
This guide uses Odoo 19 documentation to make the checks concrete. The original rehearsal below uses fictional organisations and contacts in a separate test database. For platform selection, see choosing a CRM; for the wider workflow, see business systems.
What must be agreed before the first import?
Name the source record, destination record and person who can confirm each mapping. Keep a distinction between the organisation and a person employed there. Decide how a salesperson assignment in the old file corresponds to a user or team in the proposed installation. Where a value has no agreed destination, retain it as a mapping question rather than forcing it into an unrelated field.
Odoo imports business-object data from Excel or CSV files. Its import and export documentation describes the formats and mapping process. Use the actual import template or a representative export to identify the intended columns. Check a small example through the application interface before deciding that a column label means what the business expects.
Odoo’s import-compatible export option limits the fields shown to importable fields. That can help when preparing a controlled update exercise. Record which fields are intentionally included and which are excluded. An export containing many available columns is not automatically a suitable migration specification; the chosen fields still need an agreed purpose and destination.
Odoo’s External ID can preserve identifiers from the previous application. Odoo uses consistent External IDs to identify records during updates. Keep that relationship explicit in the mapping sheet. A source identifier, an imported identifier and a display name serve different purposes, particularly when two contacts have similar names.
How should relationships and repeat imports be tested?
Odoo requires related records to be imported before records that reference them. In the fictional rehearsal, establish the organisation records before the contacts that link to them. Keep the sequence with the mapping so another person can repeat the exercise. Ask the business reviewer to inspect the resulting relationship in the interface, not just confirm that the file was accepted.
Odoo warns that duplicate External IDs create conflicts. Prepare a deliberate duplicate in a copy of the fictional input and inspect the validation result. Record which row needs correction and who owns that correction. Keep the accepted test file separate from the deliberately invalid one so the two cannot be confused during a later rehearsal.
Odoo distinguishes an omitted CSV field from a field supplied with an empty value. Its documented behaviour assigns defaults for undefined fields and uses the supplied empty value for an explicitly empty field. Include that distinction in the update exercise. A blank-looking cell can represent a meaningful change, so the reviewer should know whether the proposed file is intended to preserve or clear a value.
Odoo provides a Test step before Import to check data validity. Use the result as one piece of evidence, followed by inspection of the resulting records in the test database. Validation addresses the importer’s checks; the business owner still needs to confirm that the selected organisation, contact and ownership relationships mean the right thing.
| Rehearsal case | Expected business result | Evidence to compare |
|---|---|---|
| Initial organisation and contact | Contact belongs to the intended organisation | Input identifiers and linked destination record |
| Same identifier, corrected contact detail | Existing record is updated as intended | Before-and-after record identity and value |
| Duplicate identifier in test input | Conflict is identified and investigated | Validation result and correction decision |
| Omitted optional field | Agreed default treatment is understood | Mapping rule and actual destination value |
| Explicit empty value | Intended clearing behaviour is reviewed | Input cell, previous value and result |
| Restricted user review | User sees and changes only intended records | Account, attempted action and observed result |
The table defines a proposed acceptance exercise. Keep an observed-result column beside the expected result when the rehearsal is performed, so assumptions remain distinguishable from evidence.
Which accounts should be used for acceptance testing?
Odoo access rights can be set for individual users or groups. The access-rights documentation explains how permission choices relate to user roles and groups. Define each test account’s intended responsibility before checking the imported data. A salesperson, a reviewer and an administrator need not have the same working view.
Odoo’s Superuser mode bypasses record rules and access rights. Use ordinary representative accounts when checking the team’s access requirements. Record the account and role with each observation, including any expected denial. This gives the reviewer a way to assess whether the proposed access boundary was actually exercised.
Ask a salesperson to locate the fictional enquiry and identify its owner. Ask another test user to attempt an action outside their intended responsibility. Capture the actual response without changing permissions merely to make the demonstration progress. A missing permission and an incorrect business requirement are different findings and should have different owners.
For each allowed action, identify why the role needs it. For each denied action, check that the denial is consistent with the intended workflow. This turns permissions into part of the implementation decision rather than a late support problem. Keep any proposed production permission change for a separate authorised rollout step.
Original organisation-contact migration rehearsal
Prepare fictional organisations Sample North and Sample South, with one contact associated with each. Give every record a distinct source identifier. Add a fictional enquiry assigned to the intended salesperson and write the expected relationships on the acceptance sheet. Use invented contact information and keep all outbound messaging inactive for the rehearsal.
Run the initial mapping and validation in the test database. Record the input-file version, mapping choices and results. Inspect the linked organisation from each contact, then inspect the enquiry owner using the representative sales account. If the outcome differs from the sheet, investigate whether the problem lies in the source, mapping, import sequence or access configuration.
Next, make one controlled update with the same identifier and a changed fictional contact detail. Compare the original and resulting record identities, then inspect the changed value. Repeat with an omitted field and an explicit empty field using separate test copies of the file. Retain enough evidence to explain the difference without relying on memory.
Finally, review the invalid-identifier and restricted-account scenarios. Summarise each requirement as demonstrated, unresolved or outside the agreed scope. Attach the accepted file and mapping version to the decision record. The resulting evidence can inform a later migration plan, backup and recovery rehearsal, training scope and rollout approval.
For system connections beyond the CRM, see web development. To discuss the migration slice and remaining acceptance questions, get started with the fictional mapping sheet and rehearsal findings.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.