CRM migration

Migrate from Salesforce Field Service to Odoo CRM

Field-level mapping, validation, and rollback between Salesforce Field Service and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.

Salesforce Field Service logo

Salesforce Field Service

Source

Odoo CRM

Destination

Odoo CRM logo

Compatibility

100%

13 of 13

objects map 1:1 between Salesforce Field Service and Odoo CRM.

Complexity

BStandard

Timeline

72–120 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Salesforce Field Service stores dispatch schedules in WorkOrder and ServiceAppointment objects with specialized resource-availability logic, skill-matching, and geographic routing that sit on top of the Salesforce CRM core. Odoo CRM handles leads, opportunities, and project-based tasks in a unified crm.lead model and project.task structure without a native field-service optimization engine. We migrate the data layer: accounts, contacts, leads, opportunities, work orders, appointments, service resources, and activities — preserving original create dates, owner assignments, and scheduling timestamps. What does not migrate: Salesforce OmniStudio flows, Dynamic Forms, FSL optimization policies, Dispatcher Console configurations, and entitlement rules. Those require Odoo studio configuration or custom development post-migration. We export your Salesforce workflow definitions as JSON reference files for your Odoo implementation team to rebuild in Odoo Studio. The migration runs via Salesforce REST/Bulk API against Odoo's XML-RPC interface, with a 24–48 hour delta-pickup window capturing any records created or updated during cutover. Before migration begins, FlitStack AI validates field-level compatibility and generates a pre-migration audit report identifying any data quality issues that need resolution.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Salesforce Field Service logo

Salesforce Field Service

What's pushing teams away

  • Pricing model accumulates hidden costs—storage overages at $125/GB, API throttling during high-volume periods, and $2 per Agentforce conversation add up beyond the base seat license.
  • Complexity of inherited implementations makes configuration tangles difficult to unwind, and lack of clear documentation makes it hard for new teams to understand what the system is actually doing.
  • Scheduling limits create friction at scale—250 records per Enhanced Scheduling optimization batch is insufficient for large service operations without additional tooling.
  • Integration depth becomes a dependency trap—organizations deeply embedded in Salesforce Field Service find switching costs prohibitively high even when frustrated with cost or complexity.

Choosing

Odoo CRM logo

Odoo CRM

What's pulling them in

  • Teams choose Odoo CRM for its modular architecture — one base install with one-click app additions means they can adopt CRM alone and add accounting, inventory, or sales later as the business grows.
  • Small businesses pick Odoo because the Community edition is free and open-source, with no per-user or contact limits, allowing full evaluation before committing to a paid Enterprise tier.
  • The drag-and-drop Kanban pipeline and AI lead scoring are highlighted across G2 reviews as concrete features that make lead management faster and more visual than spreadsheet-based workflows.
  • Odoo's native integration with email, live chat, SMS, VoIP, and WhatsApp means inbound leads from multiple channels feed into a single pipeline without third-party middleware.
  • Companies in retail, supply chain, and construction value that Odoo's CRM module shares the same PostgreSQL database and UI as its ERP modules, eliminating data silos between sales and operations.

Object mapping

How Salesforce Field Service objects map to Odoo CRM

Each row shows how a Salesforce Field Service object lands in Odoo CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

Salesforce Field Service

Account

maps to

Odoo CRM

res.partner

1:1
Fully supported

Salesforce Account maps directly to Odoo res.partner in company mode. The primary address, phone, website, and industry fields transfer directly. Parent-account hierarchies map to Odoo's commercial_partner_id field for hierarchical reporting. Multi-site accounts (Salesforce child locations) become separate res.partner records linked via parent_id to preserve site-level detail.

Salesforce Field Service

Contact

maps to

Odoo CRM

res.partner (individual)

1:1
Fully supported

Salesforce Contact maps to res.partner in individual mode. First name, last name, email, phone, mobile, title, and mailing address fields transfer directly. The Salesforce contact-account relationship maps to Odoo's partner_id field on the individual res.partner record. If a Salesforce Contact has no associated Account, the individual partner record is created without a parent link.

Salesforce Field Service

Lead

maps to

Odoo CRM

crm.lead

1:1
Fully supported

Salesforce Lead maps to Odoo crm.lead with the Lead radio button selected. Standard fields — Name, Company, Email, Phone, Status, Rating, Source, Annual Revenue, Number of Employees — transfer directly. The Salesforce IsConverted flag determines whether the Odoo crm.lead lands as a new opportunity or merges with an existing partner record. Unconverted leads map as open crm.lead records.

Salesforce Field Service

Opportunity

maps to

Odoo CRM

crm.lead (opportunity mode)

1:1
Fully supported

Salesforce Opportunity maps to an Odoo crm.lead with the Opportunity radio button selected, using the Sales tab. Stage, Amount, Close Date, Probability, and Description transfer directly. The Opportunity's AccountId lookup resolves to the corresponding res.partner id already migrated from the Accounts step. Stage probability percentages are recalculated to Odoo's default scale during the mapping phase, with the original Salesforce probability preserved in a custom field for reporting continuity.

Salesforce Field Service

WorkOrder

maps to

Odoo CRM

project.task

1:1
Fully supported

Salesforce WorkOrder is the primary field-service record and maps to Odoo project.task linked to a dedicated project. Subject, Description, Status, Priority, and Scheduled Start/End dates transfer directly. AccountId resolves to the migrated res.partner record. The work order's address maps to the task's Planned Date range. Custom fields on WorkOrder (e.g., WorkOrderType__c, ResolutionCode__c) migrate as Odoo custom fields on project.task. The original WorkOrderNumber is preserved in a custom field for audit traceability.

Salesforce Field Service

ServiceAppointment

maps to

Odoo CRM

calendar.event

1:1
Fully supported

Salesforce ServiceAppointment maps to Odoo calendar.event linked to the project.task created from the parent WorkOrder. Subject, Status, EarliestStartTime, DueDate, and actual travel time fields transfer to the calendar event's start_datetime, stop_datetime, and duration. The assigned ServiceResource resolves to the Odoo user who owns the calendar event. Status mapping: Scheduled → Open, In Progress → Confirmed, Completed → Held, Cancelled → Cancelled.

Salesforce Field Service

ServiceResource

maps to

Odoo CRM

res.users

1:1
Fully supported

Salesforce ServiceResource maps to Odoo res.users by email matching — each service technician's Salesforce UserId email resolves to an Odoo user account created before migration. The resource type (technician vs. dispatcher) maps to Odoo's access rights group membership. Salesforce ResourceAbsence records (vacation/availability windows) transfer to Odoo's resource.calendar.leaves table so vacation schedules carry over.

Salesforce Field Service

OperatingHours

maps to

Odoo CRM

resource.calendar

1:1
Fully supported

Salesforce OperatingHours define availability windows and timezone settings for service territories. These map to Odoo resource.calendar records with time slots converted from Salesforce's weekly-hour structure to Odoo's hour-line model. The timezone field on OperatingHours sets the resource.calendar's timezone. If multiple operating hours exist per territory, each creates a separate calendar linked to the corresponding service resource group.

Salesforce Field Service

WorkOrderLineItem

maps to

Odoo CRM

sale.order.line (linked to project.task)

1:1
Fully supported

Salesforce WorkOrderLineItem records (line items for parts, labor, and services on a work order) map to Odoo sale.order.line records generated from the Odoo Sale Orders app linked to the project.task. Product lookup resolves by SKU matching to Odoo product.product. Quantity, unit price, and description transfer directly. If the source line item has no Odoo product match, a placeholder product is created with the original description and a zero price for post-migration review.

Salesforce Field Service

Task (Salesforce standard activity)

maps to

Odoo CRM

mail.activity

1:1
Fully supported

Salesforce Tasks attached to WorkOrders, Accounts, or Contacts map to Odoo mail.activity records linked to the corresponding migrated record (project.task, res.partner, or crm.lead). Subject, Status, Activity Date, Priority, and Description transfer directly. The task owner resolves by email match to the Odoo user. Completed tasks appear as closed activities in Odoo's chatter thread.

Salesforce Field Service

Event (Salesforce standard activity)

maps to

Odoo CRM

calendar.event

1:1
Fully supported

Salesforce Events linked to field records map to Odoo calendar.event. Subject, StartDateTime, EndDateTime, Location, and Description transfer directly. The WhoId (Contact/Lead) resolves to the migrated res.partner or crm.lead. The WhatId (WorkOrder or Account) resolves to the migrated project.task or res.partner. Recurring events are not migrated as recurring Odoo events — each occurrence becomes a separate calendar.event record.

Salesforce Field Service

Attachment / ContentDocument

maps to

Odoo CRM

ir.attachment

1:1
Fully supported

Salesforce ContentDocuments and Notes attached to WorkOrders, ServiceAppointments, or Accounts migrate as ir.attachment records in Odoo linked to the corresponding model (project.task, res.partner, crm.lead). Files are downloaded from Salesforce and re-uploaded to Odoo's filestore. File size limits: Odoo allows attachments up to the file system limit; Salesforce's 25MB per-file limit is preserved as a hard boundary during export. Rich-text note bodies migrate as ir.attachment records of type binary with a text_description field populated from the source body.

Salesforce Field Service

Custom Object (FSL extension)

maps to

Odoo CRM

Custom Model (ir.model + ir.model.fields)

1:1
Fully supported

Any Salesforce custom objects used to extend WorkOrder (e.g., InspectionResult__c, SafetyCheck__c) map to Odoo custom models created in developer mode. Each custom object becomes a new Odoo model inheriting from mail.thread, with fields defined using Odoo's field type system. Relationships to WorkOrder (now project.task) are preserved as many2one fields pointing to project.task. Your Odoo administrator creates these models in the Odoo Settings > Technical > Models panel before the migration run.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

Salesforce Field Service logo

Salesforce Field Service gotchas

High

250-record batch limit for Enhanced Scheduling optimization

High

Process Builder workflows do not migrate—must be rebuilt in Flow Builder

High

API rate limits vary by edition and are easy to exhaust during bulk migration

Medium

Storage overages at $125/GB inflate migration data costs

Medium

Custom fields and lookups require explicit field-level mapping

Odoo CRM logo

Odoo CRM gotchas

High

Odoo.sh version gating blocks assisted migrations from trial

High

Enterprise modules fail to install on Community after database restore

Medium

Custom module view inheritance breaks between Odoo major versions

Medium

Custom fields risk losing their application context on Community

Low

API access for Community is gated behind the Custom Plan

Pair-specific challenges

  • FSL skill-based routing has no Odoo equivalent and must be manually reconfigured

    Salesforce Field Service uses ServiceTerritory, ServiceResourceSkill, and SkillRequirement objects to match technicians to jobs by certifications, location, and availability. Odoo has no native skill-matching engine — service assignments are manual or require the Odoo Skills Matrix module (a community module from the OCA, not part of core Odoo). During migration, we preserve the skill names and resource assignments in custom fields on project.task and res.users so your Odoo admin can configure skill-based filtering manually. Teams that relied heavily on FSL's automatic routing will need to rebuild this logic using Odoo project.resource.allocation or a third-party field-service module post-migration.

  • WorkOrder scheduling data migrates as task records but Salesforce optimization policies do not transfer

    Salesforce Field Service's Optimizer and Dispatcher Console apply geographic routing, travel-time buffers, and priority weighting to ServiceAppointments based on FSL policies defined in the org. Odoo has no equivalent scheduling optimization engine. We migrate the appointment dates and assigned resources faithfully — the ScheduledStart, ScheduledEnd, actual start/stop, and travel duration fields land in Odoo calendar.event records with correct timestamps. What does not migrate: the FSL policy rules, routing constraints, and priority weighting that determined those schedules. After migration, your Odoo dispatch workflow operates on the data as-is without automatic re-optimization.

  • Multi-entity account structures require manual consolidation planning

    Salesforce accounts frequently model multi-site customers as parent Account records with child Account records for each location, with WorkOrders attached at either level. Odoo's res.partner model supports parent_id for hierarchical companies, but child locations used as separate WorkOrder parents require planning — each Salesforce child Account can become a separate Odoo res.partner with parent_id pointing to the top-level company, or you can choose to flatten the structure and attach all tasks to a single partner. We flag multi-location accounts during the pre-migration audit and present both options before migration runs. The choice affects reporting and invoice linkage in Odoo's Sale Orders app.

  • Salesforce API rate limits apply to the export phase and can extend the migration timeline

    Salesforce REST and Bulk API impose concurrent-request limits and daily allocation caps that vary by Salesforce edition (Enterprise vs. Unlimited vs. Performance). A Salesforce org with 200,000 WorkOrder records and heavy API usage from existing integrations may hit throttling during the migration export, causing the extraction phase to pause and resume. We mitigate this by using Salesforce Bulk API 2.0 for large data extracts, batching at 10,000 records per job, and monitoring API consumption against your org's daily limit. If your org is already running near its API ceiling, we coordinate a migration window outside business hours to avoid impacting active users.

  • Odoo does not natively store Salesforce record IDs — audit traceability requires a custom field plan

    Odoo has no equivalent to Salesforce's 18-character external ID field pattern. Every Salesforce object ID that needs to be preserved for delta-run de-duplication, rollback, or cross-system auditing must be stored in a dedicated custom field on the corresponding Odoo model. We create custom fields (e.g., sf_id__c on project.task) in Odoo before migration and populate them with the source Salesforce record IDs. This step requires Odoo developer mode to be enabled on the destination instance — if your Odoo administrator has not activated developer mode, this step must be completed as part of the Odoo schema setup phase before data lands.

Migration approach

Six steps for a successful Salesforce Field Service to Odoo CRM data migration

  1. Audit Salesforce Field Service data model and Odoo schema setup

    FlitStack AI begins by cataloging every Salesforce object in scope — WorkOrder, ServiceAppointment, ServiceResource, OperatingHours, WorkOrderLineItem, and all standard CRM objects (Account, Contact, Lead, Opportunity, Task, Event, ContentDocument). We export the field list for each object, identify custom fields with __c suffix, and assess pick-list value sets for value-mapping preparation. In parallel, your Odoo administrator (or our team) activates developer mode and creates the custom fields on project.task, calendar.event, res.partner, and crm.lead that the migration requires. We deliver a schema setup checklist with exact field names, types, and Odoo model targets so the Odoo instance is migration-ready before any data moves.

  2. Map FSL resource and territory data to Odoo user and calendar structures

    Salesforce ServiceResources are resolved to Odoo res.users by email matching against the Salesforce User records that drive FSL authentication. OperatingHours are mapped to Odoo resource.calendar records with time slots converted from Salesforce's hour structure. Service territories (if used for geographic dispatch grouping) become Odoo project.team records or tags on project.task. Any Salesforce ResourceAbsence records (vacation blocks) migrate to Odoo resource.calendar.leave records so technician availability carries over. This step runs before WorkOrder migration so that the assigned technician lookups resolve correctly when tasks land in Odoo.

  3. Extract and migrate CRM records first (Accounts, Contacts, Leads, Opportunities)

    The migration follows a dependency order: Accounts → Contacts → Leads → Opportunities → WorkOrders → ServiceAppointments → Activities → Attachments. This ordering ensures foreign-key lookups resolve correctly — project.task records linking to AccountId must land after res.partner records exist, and calendar.event records for ServiceAppointments must land after project.task records. We extract each object from Salesforce using Bulk API 2.0, transform records per the field-mapping specification, and load via Odoo's XML-RPC API. Each object batch is validated against the Odoo schema before commit — records that fail validation are written to a separate error queue for review and retry.

  4. Run a sample migration with field-level diff across WorkOrders and ServiceAppointments

    Before the full migration runs, FlitStack AI extracts a representative slice — typically 100–500 records spanning WorkOrders at different stages, ServiceAppointments assigned to different technicians, and a sample of CRM records. The sample is loaded into a staging Odoo environment (or a duplicate Odoo database alongside production) and a field-level diff is generated comparing source values against destination values. You can verify that priority mapping, date conversion, owner resolution, and custom field population all meet expectations. Stage names, pick-list values, and status codes are spot-checked against the mapping specification. No full run commits until you approve the diff output.

  5. Execute full migration with delta-pickup and post-load audit

    The full migration runs in a planned low-activity window. Salesforce records are extracted in parallel batches, transformed per the approved mapping, and loaded into Odoo. A delta-pickup window of 24–48 hours after the initial load captures any WorkOrders, appointments, or CRM records created or updated in Salesforce during the migration run. All operations are logged in the FlitStack AI audit trail: object counts, failed records, skipped records, and transformation decisions. After the delta window closes, we run a reconciliation report comparing Salesforce record counts by object against Odoo record counts, flagging any discrepancies for manual review. One-click rollback reverts the Odoo database to its pre-migration state if reconciliation uncovers critical issues.

  6. Deliver workflow reference export and post-migration handoff package

    FlitStack AI exports your Salesforce workflow definitions, assignment rules, and process builder logic as JSON reference files. These files are not usable inside Odoo — they document what your Salesforce automation did so your Odoo administrator or consultant can rebuild equivalent logic in Odoo Studio. The handoff package includes the reconciliation report, a mapping summary CSV for each object, a list of Odoo custom fields created during setup, and the delta-pickup change log. We schedule a 30-minute handoff call to walk through the package and answer questions before closing the migration engagement.

Platform deep dives

Context on both ends of the pair

Salesforce Field Service logo

Salesforce Field Service

Source

Strengths

  • Real-time technician location tracking and dispatch console with Gantt visualization for multi-technician schedule management.
  • Skill-based routing matches technician certifications to Work Order requirements automatically during scheduling optimization.
  • Deep integration with standard Salesforce CRM objects preserves context across field service, sales, and customer service teams.
  • Mobile app with offline capability lets field technicians update status, log parts, and capture signatures in low-connectivity environments.

Weaknesses

  • Per-seat licensing plus storage overages, API throttling charges, and Agentforce conversation fees create a total cost that significantly exceeds the base license price.
  • Inherited implementations with years of customizations, Process Builder flows, and AppExchange add-ons create tangled configurations that are difficult to migrate or audit.
  • API rate limits vary by edition and require careful monitoring—large data migrations can exhaust daily limits or concurrent call budgets mid-transfer.
  • Limited native export tooling means migrations typically require third-party tools, Data Loader configuration, or managed services partners to extract complete data.
Odoo CRM logo

Odoo CRM

Destination

Strengths

  • Modular open-source architecture lets teams start with CRM and add ERP apps as needs grow, all sharing one PostgreSQL database.
  • Free Community edition with no contact limits and full source code access means zero licensing cost for evaluation and small deployments.
  • Drag-and-drop Kanban pipeline with AI lead scoring gives a visual, prioritized view of the sales funnel without requiring custom configuration.
  • Native integrations with email, live chat, SMS, VoIP, WhatsApp, and social media feed all inbound leads into a single unified inbox.
  • Active Odoo Community Association (OCA) maintains dozens of community-maintained modules on GitHub for extended functionality.

Weaknesses

  • Gmail and email integration reliability is a recurring complaint — threads drop and conversations scatter across inboxes, disrupting sales team workflows.
  • Enterprise edition pricing stacks quickly: multiple apps at per-user rates ($25–$50/user/month) plus Odoo.sh hosting costs more than many SMBs anticipate.
  • Setup and configuration complexity increases significantly once custom fields, automation rules, and multiple installed modules are in play.
  • Odoo.sh trial databases run on a version (e.g., 18.3) that is not directly migratable to Odoo.sh, blocking the assisted migration path Odoo advertises.
  • Version upgrades between major Odoo releases (e.g., 17→18) frequently break custom module view definitions and XPath expressions, requiring manual remediation.

Complexity grading

How hard is this migration?

Standard CRM migration. All 8 core objects map 1:1 between Salesforce Field Service and Odoo CRM.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Salesforce Field Service and Odoo CRM.

  • Object compatibility

    A

    All 8 core objects map 1:1 between Salesforce Field Service and Odoo CRM.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Salesforce Field Service: Per-org daily API limit starts at 100,000 requests / 24 hours for Enterprise Edition and scales with licenses purchased. Additional API calls can be purchased in 200-10,000 increments. Bulk API and Bulk API 2.0 share an allocation of 15,000 batch submissions per 24 hours. HTTP 429 returned when rate-limited..

  • Data volume sensitivity

    A

    Salesforce Field Service exposes a bulk API — large-volume migrations stream efficiently.

Estimator

Estimate your Salesforce Field Service to Odoo CRM migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Salesforce Field Service to Odoo CRM data migrations

Answers to the questions buyers ask most during Salesforce Field Service to Odoo CRM migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your Salesforce Field Service to Odoo CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

A Salesforce Field Service to Odoo CRM migration typically completes in 72–120 hours of processing time for source orgs with under 50,000 records including WorkOrders, ServiceAppointments, and standard CRM objects. Orgs exceeding 200,000 records, or those with more than 25 custom fields on WorkOrder, extend to 7–14 calendar days because Salesforce Bulk API batching and Odoo schema validation both scale with data volume. The Odoo schema setup phase (custom fields, project structure, calendar configuration) runs in parallel with planning and typically takes 3–5 business days before any data moves. The migration itself runs in a single low-activity window with a 24–48 hour delta-pickup phase afterward.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Salesforce Field Service.
Land in Odoo CRM, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day