Phase 0

Decide & Plan

Lock scope, deployment shape, and edition before any data moves.

Decide and document the Odoo deployment target. Choose Odoo Online (SaaS, no custom modules), Odoo.sh (managed PostgreSQL + staging branches), or on-premise (full control). Each path has different access to filestore, database manager, and shell.
Risk if skipped: Picking Odoo Online and then discovering you need server-side scripts forces a re-platform mid-project.
Decide between Community and Enterprise edition. Community is free but excludes Studio, the Documents app, and several Enterprise-only mail features. Confirm which crm.* and mail.* features the target workflow depends on before purchase.
Risk if skipped: Restoring an Enterprise database into a Community container marks Enterprise modules as 'not installable, skipped' and breaks views that reference them.
Pin the exact Odoo major version for the cutover. Pin Odoo 17, 18, or 19 before mapping. View XML, model names, and Selection options shift between majors (e.g. <tree> → <list> in 18).
Risk if skipped: Mapping against the wrong major produces import files that reference fields renamed in the target version.
Define migration scope by Odoo model. List the in-scope models explicitly: res.partner (contacts and companies), crm.lead, crm.team, crm.stage, crm.tag, mail.activity, mail.message, ir.attachment, res.users. Mark each as in or out of scope.
Define the historical-data window. Decide how far back leads, opportunities, activities, and messages migrate. Decide whether closed/lost opportunities older than the window stay in the legacy system as a read-only archive.
Identify legal, residency, and retention constraints. Confirm the chosen Odoo hosting region (EU vs US vs APAC for Odoo Online) matches data-residency obligations. Document GDPR data-subject access and erasure procedures against res.partner and mail.message.
Risk if skipped: Discovering a residency conflict after go-live forces a database export, region re-provision, and re-import.
Assign a single Directly Responsible Individual for the migration. Name one accountable owner with authority to cut scope. Capture them in the project charter alongside the executive sponsor.
Set the cutover window and source-system freeze date. Pick the cutover datetime in the destination timezone and the source-side freeze instant. Communicate both to all source users at least two weeks in advance.
Document the migration success criteria. Write the falsifiable conditions: record counts match within an agreed tolerance, total open pipeline value matches, sampled records reconcile field-by-field, sign-off owners named.
Risk if skipped: Without explicit success criteria the project never formally closes and stretches indefinitely.
List explicit out-of-scope items. Capture items intentionally excluded (e.g. archived chat threads older than N years, legacy custom modules, deprecated picklists). Out-of-scope items become scope creep without this list.

Phase 1

Pre-Migration Prep

Everything that must be true before the first byte leaves the source.

1a. Source-system audit and cleansing

Export current record counts per source object as a baseline. Capture row counts for contacts, companies, leads, opportunities, activities, notes, and files. Date-stamp the snapshot.
Risk if skipped: Without a baseline count you cannot prove completeness after cutover.
Run deduplication on source contacts using email as the match key. Resolve flagged duplicates manually; keep a merge audit log mapping merged-from IDs to surviving IDs. Email is the most reliable cross-system contact match key.
Risk if skipped: Duplicates carried into res.partner inflate counts and split activity history across two records that never get re-merged.
Standardize email casing to lowercase across all source contacts. Odoo treats res.partner.email case-insensitively for lookups but stores what you provide; mixed casing breaks downstream upserts keyed on email.
Normalize phone numbers to E.164 format. Odoo's phone widget formats on display but stores the raw value. Pre-normalize to '+<country><number>' so search and bulk send work consistently.
Standardize country and state values to ISO-3166 codes. res.country expects an ISO code (e.g. 'US', 'DE') for import. Convert source 'United States', 'USA', 'us' to a single 'US' value before transform.
Risk if skipped: Mismatched country strings either fail the import row or silently leave country blank.
Identify and resolve records missing required fields. crm.lead requires name. res.partner requires name. mail.activity requires res_id and res_model. Surface and fix any source records that would fail these constraints.
Archive obsolete and orphaned source records. Records you do not intend to migrate (test leads, cancelled deals older than retention) should be archived on the source so they cannot accidentally export.
Inventory source custom fields with type and picklist options. List every non-standard field on the source with its type, allowed values, required flag, and which records use it. This becomes the input to Phase 1b destination field creation.
Risk if skipped: Skipping the inventory means custom fields are discovered piecemeal during transform and re-mapping costs days.

1b. Destination Odoo tenant setup

Provision the production Odoo database. On Odoo Online create the production database via the customer portal. On Odoo.sh create the production branch. On-premise install the matching Odoo version and create the production database via the database manager.
Provision a separate sandbox database as a duplicate of production config. On Odoo.sh use a staging branch. On Odoo Online use the 'Duplicate Database' option in the database manager. On-premise restore a fresh blank database with the same module set.
Risk if skipped: Skipping the sandbox forces every test against production and contaminates real data with test rows.
Install the CRM app and its dependencies. Settings → Apps → install 'CRM'. This pulls in crm.lead, crm.team, crm.stage, crm.tag, and the mail thread mixins required for mail.activity and mail.message.
Configure org-level settings before any import. Set company timezone, default currency, language, fiscal year, and country on res.company. These affect how dates, numbers, and selection labels are interpreted by base_import.import.
Risk if skipped: Changing the company timezone after import shifts every imported datetime by the offset delta and corrupts activity due-dates.
Create res.users for every salesperson and admin who needs access. Create each user with the correct access rights (Sales / User: All Documents vs Own Documents, Settings → Administration). Capture each user's login email — this becomes the salesperson lookup key during import.
Configure crm.team records for every sales team in scope. Set team leader, members, alias_name (if email-to-lead is used), and default stage. Teams must exist before crm.lead rows can reference them.
Risk if skipped: Importing leads with a missing team_id reference sets every lead to the default team and breaks pipeline-by-team reporting.
Configure crm.stage records to match the migrated pipeline shape. Create one crm.stage per stage that will exist post-migration. Set sequence, is_won, fold, and team_ids per stage. Decide whether stages are global or per-team before creating them.
Risk if skipped: Mapping source stages to a stage that does not yet exist drops every affected lead to the default 'New' stage and erases pipeline position.
Create custom fields on crm.lead and res.partner before import. Use Studio (Enterprise) or developer-mode → Settings → Technical → Fields (Community) to create each custom field with the correct ttype, selection options, and required flag. Importing into a field that does not yet exist silently drops the column.
Risk if skipped: Discovering a missing custom field after a 50k-row load forces a transform, file re-build, and re-import.
Create crm.tag records used by source leads. Tags must be pre-created or the importer will create new tags with the exact source casing on every import run, fracturing what should be a single tag.
Configure mail aliases and incoming mail servers paused. Set up the mail.alias used for email-to-lead but leave the incoming server fetcher disabled until cutover, so test imports do not race against live inbound mail.
Set ir.attachment storage location and confirm the per-file cap. Odoo's default per-attachment cap is 128 MiB. For larger files, configure the attachment store on the filesystem (on-prem/Odoo.sh) and update the limit via ir.config_parameter before bulk file load.
Risk if skipped: Files over the cap fail silently in batch imports and leave records with broken references.
Configure the dedicated migration user account. Create a dedicated user (e.g. 'migration_bot') with admin rights. All bulk writes during load use this account so the audit trail attributes writes correctly.

1c. People prep

Communicate the source-system freeze window to all users. Send the freeze datetime, the cutover datetime, and the read-only date for the source. State explicitly what they can and cannot do during the freeze.
Schedule end-user training on Odoo CRM basics. Run a session covering pipeline (kanban), lead vs opportunity, the chatter (mail.thread), and activities (mail.activity). Record it so post-cutover hires have access.
Designate first-responder support for the first 72 hours post-cutover. Name two to three people on call. Publish the escalation contact and the channel (chat, ticketing system) where users report issues.
Risk if skipped: Without a named responder, the inevitable cutover-day questions land in random inboxes and frustrate users.

Phase 2

Source Export

Pull a complete, timestamped snapshot of source data and configuration.

Export all source contacts to CSV with every standard and custom field. Include the source's primary key (record ID) as a column — this becomes the basis for the Odoo external ID used in upserts.
Risk if skipped: Forgetting the source ID column makes idempotent re-runs impossible and forces full re-imports.
Export all source companies/accounts to CSV. Companies map to res.partner with is_company=True. Capture parent-child structure and any company-level custom fields.
Export all leads/opportunities to CSV. Include current stage, owner, expected revenue, close date, probability, and the source contact/company IDs to preserve relationships.
Export pipeline / stage definitions from source. Capture every stage name, order, and is-closed/is-won attribute. This is the input to the crm.stage mapping table built in Phase 3.
Export activities, calls, and tasks as a separate file. These map to mail.activity. Include activity type, due date, assignee, related record id and type, summary, and completion status.
Export notes and message history as a separate file. Notes and emails map to mail.message. Capture author, date, body (HTML), related record id and type, message subtype, and any attachment references.
Risk if skipped: Mixing activities and messages into one file makes the post-import audit trail impossible to reconstruct.
Export file attachments as binaries plus a metadata manifest. Download every file. Produce a manifest CSV with: source attachment ID, original filename, MIME type, file size, related record type, related record ID, uploader email.
Risk if skipped: Files without a manifest cannot be re-linked to their parent records and become orphaned uploads.
Export the source user list with roles and reporting structure. User → email mapping drives the salesperson lookup and the ownership assignment in Phase 3.
Export contact-to-company associations as a separate junction file. If the source allows multi-company contacts or many-to-many tags, export the junction table directly so the relationship survives transform.
Capture screenshots and config exports of source automations and reports. Source workflows, dashboards, and reports do not transfer. Document them so they can be rebuilt manually in Odoo post-cutover.
Record the exact timestamp of every export. The delta between export-time and cutover-time becomes the source of changes you must re-pull at cutover. Date-stamp every file in its filename.
Risk if skipped: Without an export timestamp you cannot compute the delta and risk losing every change made between export and cutover.
Hash each exported file and store the hash with the export. SHA-256 of each CSV and binary. The hash proves you imported the exact bytes you exported during validation.

Phase 3

Transform & Map

Reshape source exports into Odoo-shaped CSVs.

3a. Mapping spreadsheet

Build a master field-mapping spreadsheet keyed on Odoo model. One sheet per Odoo model (res.partner, crm.lead, crm.team, crm.stage, crm.tag, mail.activity, mail.message, ir.attachment). For each row capture: source field, destination field (use Odoo's technical name, not the label), transform rule, required flag, default-when-null.
Risk if skipped: A mapping kept in heads or chat threads cannot be audited and produces inconsistent transforms across re-runs.
Pick the upsert/external-ID key for each model. External ID convention: '__export__.<source_system>_<record_id>' (e.g. '__export__.salesforce_0035i00000abc'). Add an 'id' column to every CSV containing this external ID — base_import.import uses it to upsert.
Risk if skipped: Without external IDs, re-running the importer creates duplicate records instead of updating the existing ones.
Decide handling for source fields with no Odoo equivalent. Per field decide: drop, concatenate into the chatter as an initial mail.message, or create a custom field via Studio (Enterprise) or developer mode (Community).
Decide handling for users present on the source but not in Odoo. Map orphaned ownership to a single 'migration_bot' res.users, or to the user's manager, or set user_id blank. Document the rule and apply it consistently.

3b. Data transformation

Convert dates and datetimes to ISO-8601 in the company timezone. Odoo's import wizard parses ISO-8601 reliably; ambiguous DD/MM vs MM/DD formats are guessed and frequently wrong. Force every date to YYYY-MM-DD and every datetime to YYYY-MM-DD HH:MM:SS.
Risk if skipped: Day-month inversion on dates produces silently-wrong close_date values that misreport entire quarters.
Normalize currency amounts to plain decimals with a period separator. Strip thousand separators and currency symbols. Odoo's Float field accepts '1234.56' not '1,234.56 €'. Capture currency code in a separate currency_id column.
Re-encode every text field as UTF-8 without BOM. base_import.import expects UTF-8. Latin-1 or Windows-1252 inputs corrupt accented characters and emoji.
Risk if skipped: Encoding mismatches surface as mojibake on contact names that have to be reimported per row.
Escape commas, quotes, and newlines in CSV text fields. Wrap any field containing a comma, quote, or newline in double quotes and escape embedded quotes by doubling them. Verify by opening the CSV in a strict parser, not Excel.
Risk if skipped: Unescaped newlines in note bodies split one row into two and shift every subsequent column.
Truncate source fields that exceed Odoo's column length. res.partner.name is sized but lead.name is unbounded text — others (street, city) do have limits. Truncate to fit and append a flag column if truncation lost content.
Convert booleans to True/False strings. Odoo's CSV importer accepts True/False, 1/0, and the explicit values listed in selection fields. Pick one form and stick with it across every file.
Replace empty strings with explicit blanks for nullable fields. Some Odoo field types (especially Many2one) treat empty string differently from null. Use the literal empty cell for nullable Many2one relations, not a quoted empty string.

3c. Relationship and audit-trail decisions

Resolve Many2one references using external IDs, not IDs. For every Many2one column (partner_id, user_id, team_id, stage_id, etc.) populate the '<field>/id' column with the target's external ID. This survives database recreation; raw IDs do not.
Risk if skipped: Loading raw integer IDs into Many2one columns ties imports to a specific database instance and breaks if you ever rebuild or migrate again.
Resolve Many2many references using comma-separated external IDs. For tag_ids and similar Many2many fields, populate '<field>/id' with comma-separated external IDs. Pre-create every referenced tag in Phase 1b.
Decide the historical-timestamp strategy for created_date. Odoo only lets you set the 'create_date' field on import with elevated programmatic writes. Decide: (a) preserve original via direct write, or (b) write to a custom field 'x_legacy_created_date' and let Odoo stamp the migration date as create_date.
Risk if skipped: Failing to preserve historical timestamps makes age-based pipeline reporting (e.g. 'leads older than 30 days') wrong for the first month post-cutover.
Decide the record-ownership strategy. Map source owner email → Odoo user_id. For unknown owners pick a single fallback: the migration_bot user, the team leader, or blank. Document and apply uniformly.
Decide the file-attachment strategy. Choose: re-upload binaries into ir.attachment (preserves offline access, hits the 128 MiB cap and storage cost), or keep files in external storage and create ir.attachment rows with type='url' pointing to them.
Decide load order to satisfy Odoo's foreign-key constraints. Required order: res.users → crm.team → crm.stage → crm.tag → res.partner (parent companies first, then child contacts) → crm.lead → mail.activity → mail.message → ir.attachment. Violating this order produces ondelete=restrict failures.
Risk if skipped: Loading crm.lead before res.partner causes every partner_id reference to fail and every lead to import with a null contact.

3d. CRM-specific transforms

Build the crm.stage mapping table. For each source pipeline stage map to a target crm.stage external ID. If multiple source stages collapse into one Odoo stage, document the collapse rule. Capture is_won and fold per target stage.
Risk if skipped: An unmapped source stage drops every lead in that stage to Odoo's default 'New' stage, erasing forecast position.
Resolve Selection field internal keys versus display labels. Odoo Selection fields store the internal key (e.g. 'won', 'lost') but display the label (e.g. 'Won', 'Lost'). The importer accepts either, but mixing the two within one column fails non-deterministically. Always export and import the internal key.
Risk if skipped: Importing the human-readable label when the field's internal key differs causes the row to fail silently for that column and leave a null value.
Re-derive or null out lead-scoring fields. Odoo's predictive lead scoring (Enterprise) computes scores from the historical conversion data inside Odoo. Source scores are not portable. Either null out the score column or migrate it to a custom field 'x_legacy_score' for reference.
Map mail.activity types to existing mail.activity.type records. Pre-create or reuse Odoo's mail.activity.type records (Call, Email, Meeting, To-Do). Map every source activity type to one of these via external ID. Custom activity types must be created in Phase 1b.
Reassemble mail.message threading using parent_id. mail.message has parent_id for reply chains and message_id / in_reply_to header values for email threading. Preserve the source reply chain by populating parent_id with the parent message's external ID.
Risk if skipped: Without parent_id, the chatter shows a flat list of unrelated messages instead of conversation threads.
Re-stamp mail.message author_id to a valid res.partner. mail.message requires either author_id (res.partner) or email_from. Map every source author to a res.partner external ID; for unknown authors use the migration_bot partner.
Convert note bodies to sanitized HTML. mail.message.body is HTML. Strip script tags, normalize <br>, and confirm UTF-8 encoding. Plain-text notes must be wrapped in <p>…</p>.
Map lost reasons to crm.lost.reason records. Pre-create the lost reasons in Phase 1b and map source 'lost reason' values to the corresponding crm.lost.reason external ID. Unmapped reasons cannot be imported on lost opportunities.
Resolve multi-company partitioning. If multiple res.company records exist, set company_id explicitly on every model that has it (crm.lead, res.partner, mail.activity). Leaving it blank assigns to the importing user's default company.
Risk if skipped: Misallocated company_id values make records invisible to users in the correct company and trigger record-rule access errors.
Build the contact-to-company link via parent_id. Individual contacts (is_company=False) reference their company via parent_id pointing to the company's res.partner external ID. Load companies first, then contacts.
Decide handling for source merged-lead records. Source systems often have 'merged' or 'converted' records that no longer represent live data. Decide: skip them, import as archived (active=False), or capture as mail.message on the surviving record.

Phase 4

Sandbox Test Migration

Run the full migration against a duplicate database before touching production.

Refresh the sandbox database from the latest production config. Use the Odoo database manager 'Duplicate Database' or, on Odoo.sh, rebuild the staging branch from production. Confirm modules, users, and crm.stage records match.
Load a representative 1–5% sample of each model into the sandbox. Use Settings → Apps → 'Import' or the model's list view → Favorites → Import records. Upload the sample CSV and verify the matching screen recognizes every column.
Risk if skipped: Loading the full file first burns hours debugging issues a 1% sample would have caught in minutes.
Validate field-by-field on 10 random sandbox records per model. Open each in the form view and compare every field value to the source. Pay extra attention to Selection fields, dates, and Many2one references.
Risk if skipped: Bulk count matches can mask field-level corruption that only field-by-field comparison surfaces.
Test long-string, special-character, and emoji cases explicitly. Include in the sample at least one record per model with: a 4000-character body, embedded commas and quotes, an emoji in the name, and a CJK-character note.
Risk if skipped: These edge cases surface encoding and escaping bugs that only fail on the rows your data actually contains.
Test NULL handling for every nullable field. Include sample rows where every nullable field is blank. Confirm Odoo accepts the blank without substituting a default or zero.
Test parent-child relationship import (res.partner parent_id). Load companies first, then contacts. Open a contact and confirm the 'Company' field is populated and clicking through opens the company record.
Test Many2many tag assignment. Load a lead with two tags via comma-separated external IDs. Confirm both tags appear on the lead and clicking the tag filters the pipeline correctly.
Test the chatter import on a sample of leads. Open a lead with imported mail.activity and mail.message records. Confirm activities appear in the activity widget with the right due date, and messages appear in the chatter with author, body, and timestamp intact.
Risk if skipped: Chatter that imports without author or timestamp is functionally useless and forces a re-load of every message.
Test attachment download from imported ir.attachment records. Open a sample of records with attachments. Click each file and confirm it downloads with the correct content and filename.
Run a full-volume test if sandbox capacity permits. If the sandbox can hold the full volume, run the entire import end-to-end. Time each model's load step. Extrapolate to production cutover budget.
Risk if skipped: Skipping a full-volume rehearsal means cutover-day surprises around throughput ceilings and timeout behavior.
Measure write throughput against your hosting tier. On Odoo Online expect tenant-level throttling on bulk writes. Plan batch sizes (50–200 records per call) accordingly and add backoff on throttle responses.
Risk if skipped: Aggressive parallel writes against Odoo Online trip platform throttling and stall the load mid-batch.
Have a sales-ops domain expert spot-check 25 sandbox leads. Pick records they recognize. Ask them to flag anything that 'looks wrong'. Their tacit knowledge surfaces issues no checklist catches.
Re-run the import idempotently to confirm upsert behavior. Run the same file again. Row counts should remain identical, not double. If counts double, the external-ID column is missing or wrong.
Risk if skipped: Non-idempotent imports compound every retry into duplicate records and force a destructive cleanup.
Capture sandbox sign-off in writing before proceeding to Phase 5. Migration sponsor, sales-ops lead, and IT confirm the sandbox passes. Without this gate the production cutover cannot start.

Phase 5

Production Cutover

Sequenced execution window — one shot, fully scripted.

Confirm freeze on the source system. Verify with the source system audit log that no writes have occurred in the last 60 minutes. Lock down user permissions on the source if possible.
Risk if skipped: Late source writes that arrive after the final export become silent data loss.
Take the final delta export from the source. Re-export every in-scope object, capturing only records modified since the Phase 2 baseline timestamp. Hash the export files.
Disable Odoo automated actions and email outgoing during the load. Settings → Technical → Automation → Automated Actions: pause any rule that triggers on crm.lead or res.partner create/write. Disable the outgoing mail server temporarily to avoid email storms during mail.message load.
Risk if skipped: Active automations during bulk load fire thousands of redundant notifications and inflate the activity log.
Take a pre-load backup of the destination database. Database manager → backup, or on Odoo.sh use the auto-snapshot before deploy. Confirm the backup downloads and is restorable to a scratch database.
Load res.users first. Upsert users by login email. Confirm row counts match the user export.
Load crm.team, crm.stage, crm.tag, and crm.lost.reason. Configuration records before transactional records. These should already exist from Phase 1b; this step idempotently confirms.
Load res.partner companies (is_company=True). Use base_import.import with the company CSV. Use external IDs for upsert. Capture the import job ID and error log.
Load res.partner contacts (is_company=False) with parent_id set. Contacts after companies so parent_id Many2one resolves. Verify the post-load count.
Load crm.lead. Leads after contacts and stages so partner_id, user_id, team_id, and stage_id all resolve. Use the external-ID upsert mode.
Load mail.activity attached to crm.lead and res.partner. Activities reference res_model and res_id. The res_id is the destination integer ID — resolve it from the loaded external IDs at runtime, not from the source IDs.
Risk if skipped: Hard-coding source IDs into res_id leaves every activity pointing at a non-existent or unrelated record.
Load mail.message threaded by parent_id. Load in parent-before-child order so parent_id references resolve. Use a programmatic write rather than base_import for mail.message — it requires fields the CSV importer does not expose.
Load ir.attachment binaries last. Stream binaries via the create() ORM call with base64-encoded datas, res_model, and res_id. Throttle to your hosting tier's throughput ceiling. Confirm one sampled file downloads correctly mid-load.
Risk if skipped: Pushing attachments above 128 MiB or above the throughput ceiling causes silent failures that orphan the parent record.
Cross-check destination row counts against source at each step. After every model's load, run a search_count and compare to the export's row count. Investigate any delta before proceeding to the next model.
Risk if skipped: Cascading row-count drift across models compounds and becomes unprovable later.
On any partial-load failure, stop, diagnose, and re-run idempotently. Do not push through with partial data. The external-ID upsert key makes safe re-runs possible — use it.
Re-enable automated actions and outgoing mail after all loads complete. Restore the automation rules and outgoing mail server. Run one end-to-end create-lead test to confirm automations fire as expected.

Phase 6

Validate

Prove correctness before users get the keys.

6a. Reconciliation

Compare total record count per model between source and Odoo. Pull search_count from Odoo for res.partner (companies + contacts), crm.lead, mail.activity, mail.message, ir.attachment. Compare each to the export's row count. Investigate any delta.
Risk if skipped: Skipping count reconciliation lets multi-thousand-row drops go unnoticed until users complain.
Reconcile total open pipeline value source vs Odoo. Sum crm.lead.expected_revenue where stage is not won/lost. Compare to the source's equivalent. Tolerance for currency-conversion rounding only.
Risk if skipped: Pipeline value mismatch is the single most-noticed cutover defect by sales leadership.
Reconcile open-pipeline count by stage. Group crm.lead by stage_id and compare each bucket to the source pipeline. Catches stage-mapping errors that the global total hides.
Cross-check 30–50 randomly sampled records field-by-field. Random sample across res.partner, crm.lead, and mail.activity. Compare every field including custom fields between source and Odoo.
Verify every custom field value migrated on a 25-record sample. Custom fields are the most common silent-drop category. Confirm Selection internal keys map to the right labels in the UI.

6b. Relationship validation

Verify parent-child relationships on a 25-contact sample. Confirm each sampled contact's parent_id points to the right company, and clicking through opens that company.
Verify activity-to-lead linkage on a 25-activity sample. Confirm mail.activity.res_id and res_model resolve to the expected crm.lead and the activity appears in that lead's activity widget.
Verify mail.message threading reconstructs correctly. Open a lead with multi-message history. Confirm replies thread under their parent in the chatter rather than appearing as a flat list.
Risk if skipped: Broken threading forces a re-load of mail.message after go-live and pollutes the chatter with duplicate ungrouped messages.
Verify attachment-to-record linkage on a 25-file sample. Open a sampled record, click each attachment, confirm the file downloads with the right content and is the right size.

6c. Audit and compliance

Confirm the historical-timestamp strategy worked. If you preserved original create_date via direct write, confirm a sample of records shows the legacy timestamp. If you used a custom field, confirm that field is populated.
Run a GDPR / residency spot-check. Confirm the Odoo Online region (or Odoo.sh region, or on-prem host country) matches the documented residency requirement from Phase 0. Capture the region as evidence in the migration record.
Confirm record-rule access works for each role. Log in as a Salesperson with 'Own Documents Only' and a Salesperson with 'All Documents' and confirm each sees the expected subset of crm.lead.

6d. User-acceptance check

Have 3–5 power users run their daily workflow in Odoo against migrated data. They should be able to open today's pipeline, log a call as a mail.activity, send an email from the chatter, and convert a lead to an opportunity. Document any friction.
Risk if skipped: Without UAT, the first day post-cutover surfaces issues that should have been caught before users got the keys.
Document every UAT issue and triage to fix-before-go-live or fix-after. Decide which issues block go-live and which can ship after. Capture in a tracked list with named owners and target dates.
Re-validate the issues fixed before go-live. Don't take 'we fixed it' on trust. Have the original UAT user re-test each must-fix issue.

6e. Sign-off

Capture written sign-off from the migration sponsor and sales-ops lead. Sign-off names the date, the validated record counts, and the known-issue list ship-ready for Phase 7. File it with the migration record.
Risk if skipped: Verbal sign-off creates downstream disputes about what 'done' meant.

Phase 7

Post-Migration Cleanup

Decommission the source, retire migration scaffolding, capture lessons.

Send go-live communication to all end users. Include Odoo login URL, password-reset instructions, the first-responder contact for issues, and a one-page 'how the new pipeline maps to the old one' cheat sheet.
Run role-segmented training sessions. Sales users (pipeline, chatter, activities), sales managers (forecast reports, team views), admins (Settings, Studio if Enterprise, user provisioning). Record each session.
Set the source system to read-only. Strip write permissions for all users. Communicate the read-only date in writing. Keep read access during the post-migration safety window.
Rebuild reports and dashboards inside Odoo. Source reports do not transfer. Use Odoo's pivot, graph, and list views with saved Favorites. Enterprise users can also build dashboards via the Spreadsheet app.
Risk if skipped: Sales leadership without their reports stops trusting the migrated data even when it is correct.
Rebuild source automations as Odoo automated actions. Settings → Technical → Automation → Automated Actions for trigger-based rules. Settings → Technical → Server Actions for code-based logic. Test each rule before enabling.
Re-establish integrations to other systems. Calendar sync (Google/Outlook), email integration, marketing platform feeds, BI tools. Use a steady-state service account, not the migration_bot.
Disable the migration_bot user or rotate its credentials. The bulk-load credentials are no longer needed and represent an oversized access surface. Disable the user or rotate the credentials to lock it out of routine use.
Risk if skipped: Active migration-tier credentials become the path of least resistance for accidental or malicious bulk writes.
Schedule the 30-day post-migration retrospective. Capture what went well, what didn't, what would change. File the notes with the migration record so the next migration starts ahead.
Document the source-system decommission date. Typically 90 days after cutover, after the final retention/audit window. Capture in the migration record with the named approver.
Archive the source-system exports to long-term storage. Encrypted cold storage retains the Phase 2 and Phase 5 deltas for the documented retention window. Capture the storage location and access process.
Close the migration project formally. Final status report, lessons-learned document, project closure note. Reassign the DRI back to their regular role.

Watch list

Risks to track throughout

These risks live across multiple phases — keep an eye on them from kickoff through cutover.

Community vs Enterprise feature gap surfacing mid-migration

Studio, Documents, predictive lead scoring, and several mail features only exist on Enterprise. Sandbox testing against an Enterprise database and then deploying onto Community causes views to break with 'not installable, skipped' errors and silently drops fields. Verify edition at every phase boundary, not just at Phase 0.
Selection-field internal-key vs label drift

Odoo Selection fields store the internal key but display the label. Importers sometimes accept either, but rows mixing the two fail non-deterministically. Hold a single discipline across every CSV: export the internal key, import the internal key, validate against the internal key. This risk re-emerges every time a Selection field is added to the mapping.
Throughput ceilings and per-attachment caps compound across runs

Odoo Online throttles bulk writes at the tenant level, and per-attachment files cap at 128 MiB by default. Test runs, mapping fixes, and re-loads compound throughput consumption; oversize attachments fail silently in batches. Track cumulative bulk-write volume and pre-flight attachment sizes from Phase 4 onward.
External-ID hygiene degrading after the first import

The '__export__.<source>_<id>' convention is what makes safe re-runs possible. If any phase loads a model without external IDs (mail.message, ir.attachment via raw ORM calls, ad-hoc admin imports), the next re-run creates duplicates rather than updating. Audit external-ID coverage at the end of every phase that writes data.