Migrate from Salesforce to Odoo CRM

Migrate from Salesforce to Odoo CRM when sales must sit next to quoting and inventory

The migration is a data and process rebuild, and the effort depends on how much of your Salesforce org is custom. Accounts, contacts, opportunities and products move across with a well-prepared export and a field mapping. The harder work is rebuilding the custom objects, page layouts, approval logic and automation that sit around them, because Odoo models those processes differently rather than copying Salesforce's configuration. Teams that use Salesforce mainly for standard objects will find this manageable, while orgs with heavy Apex, custom objects and many flows need a longer discovery phase before any data moves. In most cases an internal admin owns the project, with an implementation partner handling the data mapping, Odoo configuration, custom modules and cutover. Your internal team should own the business rules, such as pricing, discount approvals and stock reservation, because those decisions are yours to make and document. Ask any partner for a written scope that lists each Salesforce object, flow and integration, and what happens to it in Odoo. The scope is also where you agree on the duration, which should come from that inventory rather than from a generic estimate.

Plan for the points where the Odoo data model differs from Salesforce. Odoo links opportunities to quotations, sales orders, invoices and stock moves, so each Salesforce product, price book entry and quote line needs a clear home before you import anything. Confirm which Odoo edition covers the features you depend on, because the editions page and pricing page list different capabilities for on-premise hosting, multi-company use, external API access and custom modules. Run a test migration on a copy of the database, reconcile record counts and open pipeline value against Salesforce, and keep Salesforce read-only for a defined period after cutover so you can answer questions about historical data.

Which Salesforce capabilities map cleanly to Odoo CRM and which need rework

This table compares common Salesforce Sales Cloud capabilities with Odoo CRM, Sales, Invoicing and Inventory, and marks each as clean, needs rework or gap. Read the rows against your own Salesforce org and your Odoo edition, because several answers depend on whether you run Community or Enterprise and which plan you buy. Treat every mark as a starting hypothesis to confirm in a proof of concept.

Capability	Odoo fit	Notes for the migration
Accounts and contacts	Clean	Odoo models companies and contacts as partner records. Confirm how your account hierarchy and parent-child links translate before loading.
Leads and conversion	Clean	Odoo CRM supports leads and conversion to opportunities. Map lead statuses and source fields to Odoo stages and tags before import.
Opportunities and pipelines	Needs rework	Rebuild each Salesforce sales process as Odoo pipeline stages. Stage-specific required fields and forecast categories usually need custom fields or configuration.
Products and price books	Needs rework	Odoo uses products and pricelists in Sales and Inventory. Multiple price books per region or segment need pricelist design and confirmation in your edition.
Quotes and approvals	Needs rework	Quotes map to Odoo Sales orders. Discount approval chains and multi-step CPQ rules typically need custom work or a review of what your plan permits.
Invoicing and inventory	Clean	Odoo Invoicing and Inventory share records with Sales, which removes the usual export step. Confirm stock locations and tax rules with your finance team.
Activities, tasks and email sync	Needs rework	Activities and mailbox sync are available in Odoo, but Salesforce activity history and Einstein-style activity capture need a field-by-field check.
Reports and dashboards	Needs rework	Rebuild Salesforce reports as Odoo dashboards and pivot views. Check whether your edition gives the reporting depth your managers use today.
Automation, Apex and external API access	Gap	Salesforce flows and Apex have no direct Odoo equivalent. Confirm whether external API access and custom modules are included in your plan, since these are reserved for the Custom plan.

Odoo Community or Enterprise: how to choose before you migrate

The first decision in this migration is the edition, because it determines who can host the system, which features you can use and whether you can upgrade on your own schedule. Odoo Community is published under LGPLv3 and its source is on GitHub. Odoo Enterprise is built on Community, adds features and support, and its source code is not publicly available, so you access it through a subscription or partner arrangement. Before you choose, list the features your Salesforce replacement needs, then check each one against the editions page and the Odoo pricing page, which lists three plans: One App Free, Standard and Custom.

The pricing page ties the hosting and feature set to the Custom plan. According to that page, only Custom can be hosted on Odoo.sh or on-premise, and only Custom includes multi-company, Odoo Studio, external API access and custom modules. If your plan depends on any of these, such as a parent company with several legal entities, a middleware integration that calls the API, or custom quote logic, the Custom plan is the one to price. Ask Odoo to confirm in writing which plan covers each item, and whether these terms change by version or by hosting model. Terms like these change, so treat the pricing page as a starting point, not a contract.

The upgrade path is the cost most teams miss. On-premise upgrades use the upgrade service, which requires an Enterprise subscription, while Community has no access to it. Plan to build your own upgrade and test process if you stay on Community. Odoo's standard support covers the first three years after a major release, including security updates, and paid extended support afterward is limited to Odoo.sh for select versions and on-premise. Check the current support window for the version you plan to install, since Odoo 17.0 standard support has already ended, and confirm with Odoo whether security patches are still provided after that window.

What data to extract from Salesforce and which integrations to rebuild

Salesforce gives you two documented extraction routes, and the one you choose sets how current your data is at cutover. Each card below covers one object group or integration type that needs a decision before the Odoo build starts.

Data Export Service cadence

The Data Export Service produces CSV files in a compressed archive. It runs weekly in Enterprise, Performance and Unlimited editions and every 29 days in Professional and Developer editions, so a full export may be up to a month old by the time your team uses it. Check your edition first, then plan a final delta extract in the cutover window. Confirm with Salesforce which objects and attachments the export includes in your org, since the archive is a snapshot rather than a sync.

Data Loader for scripted extracts

Data Loader is a separately installed client that runs from a graphical interface or the command line, which makes it suitable for repeatable extracts. Use it when you need the same field selection each run, when you want to rerun a delta before cutover, or when the Data Export Service cadence is too slow. Keep the configuration files under version control, and confirm that the integration user has read access to every object in scope.

Accounts, contacts and relationships

Map Salesforce Accounts and Contacts to Odoo partners, including parent-child company links and contact roles on opportunities. Decide early whether duplicate accounts are merged before import, because Odoo matches partners on fields such as name, email and VAT. Export the lookup relationships as IDs so you can rebuild links during import instead of matching on names. Include record owners so sales territories and access rules carry over correctly.

Opportunities and stage history

Opportunities in Odoo are leads moved through pipeline stages, so the stage model must match what your team actually uses. Export the current stage, close date, amount and probability, and pull the field history if you need trend reporting from the old system. Stage history is often not in the standard export, so confirm whether you need it and whether it must be archived separately for audit or forecasting purposes.

Products, price books and quote data

Salesforce products, price book entries and quote line items must map to Odoo products, pricelists and sales order lines. Price book overrides for specific customers need a rule set in Odoo, which is where the Custom plan and its custom modules may matter for complex pricing. Export every price book, not only the standard one, and check that currency and tax settings match the Odoo company configuration before loading any transaction history.

Attachments, files and connected apps

Attachments and files are not always included in a standard metadata export, so request them explicitly and check their storage size and retention. Connected apps and AppExchange integrations, such as email sync or e-signature, stop working at cutover and must be replaced or retired. Odoo's external API access is part of the Custom plan, and LDAP authentication is documented for Odoo, so confirm both before designing the integration layer and sign-in model.

The migration sequence from inventory to decommission

This sequence moves Salesforce accounts, opportunities, products and automations into Odoo CRM in controlled stages, so each stage has a documented output and a reconciled check before the next one begins. Salesforce stays read-only and available until the cutover checklist is signed off.

Inventory objects, automations and integrations
Your admin team lists every standard and custom object in use, every flow, approval, validation rule and report that sales depends on, and every connected app or middleware job that reads or writes CRM data. A DeployOpen consultant can run this review with them as part of a fixed-scope engagement. The output is an inventory register that marks each item as keep, rebuild in Odoo, replace or retire. The step is done when sales leadership has signed off the register.
Extract data from Salesforce
Export accounts, contacts, opportunities, products, price books and attachments using the Data Export Service or Data Loader, depending on which cadence and scripting your edition supports. Record the export date, file list and record counts for each object. Keep the raw extract unchanged in a restricted location. The output is a versioned extract set with a manifest that lists every file, its row count and its checksum.
Map Salesforce fields to Odoo models
Build a field mapping sheet that pairs each Salesforce object and field with its Odoo CRM or Sales counterpart, including opportunity stages, lost reasons, product categories and owner fields. Mark gaps where Odoo has no direct field and decide whether to add a custom field, use a tag or drop the data. Confirm these choices with the sales operations lead. The output is an approved mapping sheet with a named owner for each unmapped field.
Cleanse and deduplicate the data
Standardize country codes, phone formats and currency fields, merge duplicate accounts and contacts, and close or archive stale opportunities according to the rules in the mapping sheet. Keep a log of every change so that the reviewers can trace a record back to its original value. The output is a cleansed dataset and a change log that the data owner has reviewed.
Run a pilot import into a test database
Load the cleansed data into a test copy of the Odoo database. Odoo documents database duplication with neutralization, which lets you create a test copy that does not send mail or trigger live integrations, so the pilot can run safely against production-like data. Compare record counts, totals and pipeline values against the source extract. The output is a reconciled pilot report that lists every difference and its disposition, and it is complete when each difference is either fixed or accepted in writing.
Rebuild automations and integrations
Recreate the approved automations in Odoo, such as stage actions, scheduled activities, approval steps and quote workflows, and reconnect integrations through Odoo's external API, which is part of the Custom plan and on-premise options. Test each rebuilt automation against the scenarios documented in the inventory. The output is a test log per automation and a list of items that were retired or deferred.
Run parallel and cut over
For a defined period, sales works in Odoo while Salesforce stays read-only for reference, and any differences found in daily reconciliation are logged and fixed in Odoo. Then the final delta load is performed, users are switched over, and the cutover checklist is signed off by the business owner and the IT lead. The output is a signed cutover checklist that records the final delta counts, the access changes and the rollback contact.
Decommission Salesforce
After cutover, keep a verified archive of the final Salesforce extracts and retention records under your own control, revoke integration users and connected apps, and cancel or reduce subscriptions only once contract terms and retention obligations are confirmed with Salesforce and your legal team. The output is a decommission record that lists archive locations, access revocations and the contract end date confirmed in writing.

How the migration differs for lean sales teams and multi-entity operations

A team that uses Salesforce mainly for accounts, contacts, opportunities and one pipeline has the smallest migration scope. The data model is close to Odoo's standard CRM objects, so most of the work is mapping fields, cleaning duplicates and rebuilding the stage pipeline and a few views. Because the rebuild is limited, the team can often test the move with a sample extract before committing to a full cutover.

Standard objects: Map Accounts, Contacts, Opportunities and Products to Odoo's partners, leads, opportunities and products, and confirm which Salesforce fields have no Odoo field.
One pipeline: Recreate stages, probabilities and win or loss reasons in Odoo CRM, then check that reporting still answers the questions leadership asks.
Simple automation: List every Salesforce alert, assignment rule and email template in use, and decide which ones Odoo's built-in features replace.
Edition fit: Community may cover the core CRM, but confirm which apps and features the team needs before choosing between Community and Enterprise.
Data export: Plan the extract with the Data Export Service or Data Loader, and check how attachments and history are handled.

Confirm first whether anyone outside sales relies on Salesforce reports, because that is the most common scope change for small teams.

What Salesforce automation needs rebuilding in Odoo

Flows, approval processes, validation rules, assignment rules and scheduled actions do not move into Odoo as exported data. Each one has to be re-expressed in Odoo's own automation, server actions, approval settings or custom modules, and the logic should be rewritten against the Odoo data model rather than copied from Salesforce. Start by inventorying every automation in the Salesforce org before cutover: the object it fires on, the trigger conditions, the fields it reads and writes, the users or queues it notifies, and who owns it. Many orgs carry automations nobody has touched for years, and the inventory is the point where you decide which ones still earn a place in the new system.

Odoo Studio and custom modules are features of the Odoo Custom plan, according to Odoo's pricing page, and only Custom includes multi-company, external API access and custom modules. Confirm with Odoo which plan covers the features you need before you design around them, because Studio-based field and view changes and bespoke approval or assignment logic depend on that choice. Integrations that call Salesforce APIs, such as middleware jobs, webhook receivers or scheduled syncs to ERP or marketing tools, must be redesigned against Odoo's external API. Map each integration's endpoints, field names and authentication to Odoo equivalents, and test the redesigned flow with a copy of the database before production, since the external API is only available on the plan that includes it.

Record the cutover decision for each automation: rebuild in Odoo, replace with a standard Odoo feature, move to an external workflow tool, or retire. Name an owner for each rebuilt item and test it against realistic sample records, including the edge cases the Salesforce version handled quietly, such as reassignment on territory changes or validation on closed-won stages. Ask your implementation partner and Odoo to confirm, in writing, which automation patterns they will support on your chosen edition before scoping the rebuild.

What drives migration cost and duration, and how to keep each down

This table lists the main drivers of a Salesforce to Odoo migration, why each one changes cost or effort, and the control that keeps it manageable. Read each row as a lever: the drivers with the largest effect are usually data quality, custom objects and automation, which you can scope before any build starts.

Driver	Why it changes cost or effort	How to keep it down
Data volume and quality	Duplicate accounts, stale opportunities and inconsistent picklist values multiply mapping and cleansing work before import. Odoo's CRM and Sales records depend on clean partner and product records, so errors surface during reconciliation.	Profile the Data Export Service or Data Loader extract before scoping. Agree deduplication rules, archive closed records you do not need, and fix picklist values in Salesforce first.
Number of custom objects and fields	Each Salesforce custom object needs a mapping decision: a standard Odoo model, a custom field, or a custom module. Custom modules are where the largest build effort sits.	Inventory every custom object and field with its owner and usage. Map as many as possible to standard Odoo fields and retire unused ones before the mapping workshop.
Automation count and complexity	Salesforce flows, validation rules and Apex triggers have no one-to-one Odoo equivalent. Each rebuilt automation needs design, build, testing and documentation, and complex logic usually needs custom code.	Rank automations by business value. Rebuild the few that matter using Odoo's native automation features, drop those that duplicate standard behavior, and document the rest as a backlog.
Integrations	Every connected system such as marketing tools, ERP, email or payment services needs its own connector, credentials and test cycle. Connectors built on Salesforce APIs must be re-pointed at Odoo's interfaces.	List each integration with its data flow, direction and owner. Confirm Odoo's external API access and any connector requirements against the edition you select, then prioritize integrations that feed quoting and invoicing.
Number of Odoo apps in scope	CRM alone is the smallest scope. Adding Sales, Invoicing and Inventory brings product catalogs, pricing, tax, invoice numbering and stock flows, each with its own configuration and sign-off.	Phase the rollout. Start with CRM and Sales for pipeline and quotes, then add Invoicing and Inventory once the product and tax master data are verified.
Edition and hosting choice	Odoo Community is free to use, but Enterprise features, support and the upgrade service require a subscription. The pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, which affects hosting and recurring cost.	Compare required features against the editions page before design. Ask the vendor which subscription covers your hosting model and support level, and get the recurring fees in writing.
Testing depth	Migrated data, pipeline stages, quote templates and invoices all need validation. Odoo's documentation recommends testing an upgraded or duplicated database before production, and skipping this shifts defects to live users.	Use database duplication with neutralization for test copies. Define acceptance tests for record counts, totals, open pipeline value and invoice numbering, and run at least one full dress rehearsal before cutover.
Training and change management	Sales and finance users must learn new screens and quoting flows. Gaps in training usually appear as shadow spreadsheets and data entry errors after go-live.	Train by role, using the team's own records. Budget time for admin handover, and confirm with the implementation partner which training materials and sessions are in the written scope.
Ongoing upgrade and support	Odoo SaaS releases ship every two to three months, and Odoo's documentation states that Odoo Online and Odoo.sh require major upgrades every two years. Self-hosted systems must plan and test each upgrade themselves.	Choose a supported version with a clear standard support end date, schedule upgrade windows in the operating model, and confirm who performs and tests each upgrade.

What usually goes wrong in a Salesforce to Odoo migration

Most Salesforce to Odoo projects fail on data and scope, not on the software itself. The risks below share a root cause: the source data, the automation and the export tools do not carry over on their own. Each card names a check to run before cutover so that gaps surface in a test database rather than in front of sales users.

Duplicate accounts after import

Salesforce orgs often hold the same customer as several Account records, and Odoo merges and matches partners differently. Importing without a deduplication pass creates parallel partner records, which split invoices, contacts and opportunity history. Before the first load, export accounts with their Salesforce IDs, match on tax ID, domain or company registration number, and agree which record wins. Keep the Salesforce ID in an external reference field so later corrections remain traceable.

Lost history on opportunities

Opportunity stage history, close date changes and owner reassignments are kept in Salesforce history objects that a standard CSV export of the opportunity record does not include. Teams that import only the current stage find their pipeline reports start on the migration date. Decide which history matters for forecasting, export it separately, and load it as chatter notes or a reference table so the audit trail stays readable.

Price and product mismatches

Salesforce price books, multiple currencies and product families rarely map one to one onto Odoo products, pricelists and taxes. A quote that reproduces a discount incorrectly can be issued from Odoo with a wrong price or tax line, and the error appears only when invoices are compared. Reconcile a sample of recent closed-won deals line by line against Odoo quotes in the test database, and confirm tax and currency settings with your finance team before go-live.

Unbuilt automation found after cutover

Flows, validation rules, approval processes and assignment rules that run silently in Salesforce do not move with the data. Odoo needs equivalent automated actions, server actions or custom modules, and any gap shows up only when a user notices a lead is not routed. Inventory every active automation in the org, mark each one as rebuilt, replaced or retired, and test each rule with a named owner before the cutover date.

Odoo upgrade cycles forcing a second project

Odoo major versions have fixed support windows, and on Odoo Online and Odoo.sh major upgrades are mandatory every two years. A project delivered on one version can need a second upgrade project within the planned life of the system, especially if custom modules are not maintained. Choose the edition and hosting model with the upgrade path in view, keep custom code in version-controlled modules, and budget upgrade testing as a recurring line item. Confirm the support dates for your chosen version on the Odoo support documentation before signing off the design.

Users reverting to spreadsheets

If the new Odoo pipeline lacks the views, mandatory fields or mobile access that sales users relied on, they keep their own spreadsheets and the CRM becomes a stale copy. This usually shows up in the first weeks after launch as pipeline numbers that managers cannot trust. Run user acceptance sessions with the actual sales lead and forecast reports, configure kanban and list views that match their daily routine, and set a short post-launch review to retire the shadow files.

Missed attachments in standard exports

The Data Export Service produces CSV files in a compressed archive and can include files and attachments when selected, while Data Loader handles scripted extracts. Neither method is a complete copy of the org, so attachments, notes and some related records can be left out unless you check for them. Compare record counts per object against the Salesforce org, verify a sample of attachments opens in Odoo, and document what each export excludes so that nothing is assumed to be migrated.

Questions buyers ask before moving from Salesforce to Odoo

How much does a move from Salesforce to Odoo cost?

The cost depends on the scope you agree, the volume and quality of data to move, how many custom objects and automations you rebuild, and which Odoo edition you choose. Costs fall into a few components: the Odoo licence or hosting, the infrastructure or Odoo.sh fees if you self-host or use managed hosting, implementation and data migration work, integration and testing, and internal admin time. Licence and hosting recur, while migration and rebuild work is largely one-time. Ask any implementation partner for a fixed-scope quote that lists each component separately, and compare it with your current Salesforce subscription and add-ons over the same period. Odoo's pricing page lists per-user monthly prices for its plans, so confirm the current figures there rather than relying on older numbers.

How long does a Salesforce to Odoo CRM migration take?

The timeline is set mostly by how much of your Salesforce configuration needs rebuilding, not by the record count alone. The main drivers are the number of custom objects and fields, the number of Flows and Apex triggers that must be replicated, the quality of your existing data, the number of integrations, and how many people must be trained and sign off on the new process. Odoo's quote and invoicing flows also add scope if you bring quoting, invoicing and inventory into the same system. No duration is supplied here, so ask for a written schedule with phases for discovery, data mapping, build, test, cutover and hypercare, and check that each phase has clear exit criteria.

What does the internal team need to provide during the migration?

Your team needs to own the business decisions: which pipeline stages, product catalog, price rules and approval steps are current, and which fields can be retired. You also need a named technical contact for access, export permissions, identity provider setup and test environments, plus a sales lead who can test opportunities and quotes during user acceptance. Expect the admin team to take over configuration after go-live, so budget their time for training and for reviewing the first months of support requests. Ask the implementation provider to document which tasks it performs and which your staff must complete.

Can a skilled Salesforce admin migrate to Odoo alone?

A skilled admin can usually handle the data export, the field mapping and the basic configuration of users, pipelines and products in Odoo, especially for a small, standard sales setup. Doing it alone becomes risky when you must rebuild Apex, Flow or integration logic, set up on-premises hosting, handle upgrades and backups, or migrate quotes and invoices that feed finance. Test the admin's Odoo knowledge with a pilot import before committing. If you use the Community edition, the admin will also own more of the operational tasks, including hardening and backups, so count that effort in the decision.

Is Odoo Community enough to replace Salesforce?

Community is enough for many teams that need CRM, quoting and inventory and can manage their own hosting and updates. It is licensed under LGPL-3.0, and the source is public. The Enterprise edition adds features and support, and its source code is not publicly available, requiring a subscription or partner access. Check whether you need features the Custom plan includes, such as multi-company, Odoo Studio, external API access and custom modules, because the pricing page indicates only the Custom plan can run on Odoo.sh or on-premises. Also confirm whether you need the upgrade service, which the Community edition cannot use, and whether standard support and security updates matter to your risk posture.

How does Odoo's upgrade cycle affect migration planning?

Odoo's upgrade cycle affects both the initial design and the long-term budget. Each major version receives standard support for about three years, including security updates and bug fixes, and paid extended support is limited to Odoo.sh for select versions and on-premises use, with security patches provided only during standard support. On Odoo Online and Odoo.sh, major upgrades are mandatory every two years, and SaaS versions ship every two to three months. Check the current support end dates in Odoo's standard and extended support documentation before you pick a version, and plan a recurring upgrade test cycle that uses a duplicated, neutralized database before production.

How should the parallel run between Salesforce and Odoo work?

Run both systems for a defined period, with one designated system of record for each object at each stage. Export Salesforce data on a schedule, using the Data Export Service or Data Loader, and import it into a test Odoo database first. Reconcile record counts, pipeline totals and open quotes between the two systems each cycle, and document every discrepancy. Set a cutover date only after sales leaders confirm that opportunities, quotes and invoices match. Keep Salesforce read-only after cutover and retain an archive export for audit and retention needs, and confirm with your compliance team how long that archive must be kept.

What security controls should we check in an Odoo deployment?

Check identity first: Odoo supports LDAP authentication, so confirm the setup against the Odoo LDAP documentation and your directory structure. Then review access rights for sales, finance and inventory, backup and restore procedures, encryption in transit and at rest, and how test copies are handled, since Odoo documents database duplication with neutralization for test environments. Ask your security team to map these controls to the frameworks your organization must meet. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue the audit reports and certifications.

What a fixed-scope migration engagement covers

DeployOpen plans, implements, customizes, integrates, backs up, upgrades and documents self-hosted Odoo inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. For a Salesforce exit, the scope usually spans the Odoo CRM app, quotes and invoicing, product and inventory setup, the data migration of accounts, contacts, opportunities and products, the integrations that replace Salesforce connections, and the runbooks your administrators need afterward. Most engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before any work starts. Ask for that document to name the Odoo edition, the modules in use, the hosting model and the list of Salesforce objects that are in and out of scope.

DeployOpen does not publish a price list. A quote follows from the written scope, so the inputs that move it are the number of Salesforce objects and custom fields to map, how much Apex or Flow logic must be rebuilt as Odoo automation or custom modules, the number of integrations, the number of environments and the handover and training expected. Ask whether the quote separates one-time work such as migration, configuration and testing from recurring work such as hosting, Odoo subscription fees, upgrades and support retainers. Upgrades matter here because Odoo's documented cycle requires regular major version moves, so confirm who runs test copies of each upgrade and who signs off before production. Ongoing support, upgrades and continuous testing are available as retainers, and those can be scoped separately from the migration itself.

How DeployOpen scopes, runs and supports your Odoo migration

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Salesforce to Odoo CRM, that means agreeing the written scope first, building and testing the migration in a non-production copy, and handing over documentation your administrators can run without us.

How we scope

Inventory which Salesforce accounts, opportunities, products and custom objects move into Odoo CRM and which stay behind.
Decide the Odoo edition, hosting target and sales, quoting and invoicing apps in the written scope before work starts.
Agree which Salesforce Flows, validation rules and reports need rebuilding in Odoo, and which are retired.

How we build

Map Salesforce fields to Odoo models, then load CSV extracts into a test database and reconcile record counts.
Rebuild pipeline stages, sales teams, pricing and approval steps in Odoo, and configure LDAP sign-in where your identity setup requires it.
Test migrated opportunities and quotes end to end in a duplicated, neutralized database before any production cutover.

How we hand over

Deliver field mapping, data load runbooks, configuration records and a list of retired Salesforce automation.
Document the upgrade path, including the upgrade test database step that should precede each major Odoo version change.
Train named administrators on daily record management, user onboarding and running test copies of the database.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after go-live, scoped separately from the migration.
Confirm with Odoo which support tier and edition your plan includes, since standard and extended support differ by hosting.
Keep backup and restore procedures tested so the migrated CRM data can be recovered after an incident.

Migrate from Salesforce to Odoo CRM