How long does a Connect Field Service to Odoo CRM migration take?

Most Connect Field Service to Odoo CRM migrations complete in 48–72 hours for under 50,000 records spanning accounts, contacts, work orders, and products. Larger setups with 500,000+ records or complex multi-territory configurations extend to 5–7 days. The longest phase is mapping Connect operational fields (sub-status, IoT alerts, booking data) to Odoo custom fields and validating pick-list value translations. Work order history volume is the primary timeline driver; scheduling and IoT data require staged batch imports that add 1–2 days for large datasets.

Will my Connect Field Service scheduling rules and dispatch automations migrate to Odoo?

No. Connect Field Service scheduling rules, Universal Resource Scheduling configurations, auto-reassignment logic, and real-time dispatch optimizations do not migrate to Odoo CRM. Odoo has no native dispatch console, schedule board, or resource scheduling engine. FlitStack exports the Connect scheduling configuration as a JSON reference document so your Odoo admin or developer can use it as a blueprint when rebuilding scheduling workflows in Odoo Studio or as a custom module. The msdyn_bookings data (technician-to-work-order assignments) is preserved as a custom field on each migrated opportunity.

What does a Connect Field Service work order become in Odoo CRM?

Each msdyn_workorder becomes an Odoo crm.lead record with type='opportunity'. The work order name maps to the opportunity name, msdyn_workorderstatus maps to a custom pick-list field Work_Order_Status__c, and msdyn_priority, msdyn_workordertype, and msdyn_substatus each become dedicated custom selection fields on the opportunity. Service task line items are merged into a single crm.activity attached to the opportunity, with individual task details stored as a JSON custom field for audit traceability. Attachments and signature images re-upload as Odoo ir.attachment records linked to the opportunity.

Can I migrate Connect Field Service custom fields to Odoo CRM?

Yes. Any custom fields defined on msdyn_workorder, msdyn_account, msdyn_contact, or msdyn_product in your Connect Field Service instance migrate to Odoo as custom fields on crm.lead or res.partner. FlitStack creates the Odoo ir.model.fields entries before the data load so the fields exist at migration time. Pick-list values are mapped value-by-value. N:N relationships between custom objects in Connect Field Service are handled via Odoo custom junction fields — FlitStack surfaces these in the mapping plan so your admin can review the relationship structure before migration commits.

What happens to Connect Field Service IoT alert and remote monitoring data?

Connect Field Service IoT alerts — sensor telemetry, threshold breach notifications, and remote diagnostic readings attached to customer assets — have no native destination in Odoo CRM. FlitStack preserves the most recent alert timestamp and a text summary as a custom Char field on the related opportunity. Full alert history exports as a JSON file attached to the opportunity record. Your team will need to rebuild the IoT integration with an Odoo-compatible IoT platform or accept the alert history as a reference document. The rebuild scope is documented in the post-migration handoff package.

Does the migration affect my Connect Field Service account during cutover?

No. FlitStack uses scoped read access on Connect Field Service — your team continues working in Connect Field Service throughout the migration. A delta-pickup window of 24–48 hours after the initial load captures any records created or modified during cutover. All migration operations are logged in an audit file. One-click rollback to the pre-migration Odoo snapshot is available if reconciliation finds discrepancies exceeding the agreed tolerance threshold, so your team can continue operating in Connect Field Service until the delta pass confirms Odoo is in its final state.

What Connect Field Service data cannot migrate to Odoo CRM and must be rebuilt?

Four categories of data must be rebuilt in Odoo. First, scheduling and dispatch automations: Connect's real-time technician dispatch, schedule board configurations, and auto-reassignment rules have no Odoo equivalent. Second, IoT monitoring integrations: sensor configurations, alert routing rules, and Azure IoT Central connections require a new integration. Third, resource booking records (msdyn_bookings) can be preserved as structured JSON but cannot activate Odoo scheduling. Fourth, any custom integrations with Dynamics 365 Finance, Project Operations, or Azure services — Odoo does not have native connectors for these. FlitStack delivers a rebuild reference export for all four categories.

What Odoo edition do I need to receive the migrated data?

Odoo Community (the free tier) receives migrated accounts, contacts, work orders, products, and custom fields without limitation. However, Odoo Community does not include the Odoo Field Service module, advanced inventory management, or IoT connectivity — if your Connect Field Service instance uses Enterprise-only FSM features, those capabilities require Odoo Enterprise or a third-party FSM add-on. FlitStack audits your Connect tier and extension usage during discovery and flags whether Odoo Enterprise is needed to maintain equivalent functionality before mapping begins. Odoo Online (SaaS) and Odoo.sh both receive the migration via XML-RPC.

Connect Field Service to Odoo CRM Migration — Field-Level Mapping & Rollback

Object mapping

How Connect Field Service objects map to Odoo CRM

Each row shows how a Connect 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.

Connect Field Service

Account (msdyn_account)

maps to

Odoo CRM

res.partner

1:1

Fully supported

Connect Field Service Account maps directly to Odoo res.partner (company mode). FlitStack sets partner_id on every contact record, resolving the company link so Odoo's 'contacts' view shows account-linked records correctly. Connect's service territory and operational hierarchy fields migrate as custom fields on res.partner since Odoo has no native territory object.

Connect Field Service

Contact (msdyn_contact / Contact)

maps to

Odoo CRM

res.partner

1:1

Fully supported

Connect Field Service contacts map to Odoo res.partner (contact mode) with parent_id pointing to the mapped Account partner. Phone, email, jobtitle, and address fields transfer directly. FlitStack resolves the email-address match against existing Odoo users to populate the responsible_id field on each contact record.

Connect Field Service

Work Order (msdyn_workorder)

maps to

Odoo CRM

crm.lead (Opportunity)

1:1

Fully supported

Each Work Order becomes an Odoo crm.lead record with type='opportunity'. FlitStack maps msdyn_workorderId to a custom external_id field, msdyn_name to the opportunity name, msdyn_workorderstatus to a custom pick-list field, msdyn_priority to a custom field, and operational notes to the opportunity description. The Work Order's sub-status, internal priority, and resolution type all land as Odoo custom fields since Odoo CRM has no native service-status concept.

Connect Field Service

Work Order Sub-Status

maps to

Odoo CRM

Custom field on crm.lead

1:1

Fully supported

Connect Field Service uses msdyn_substatus as a second-level status pick-list on work orders beyond the primary msdyn_workorderstatus. Odoo CRM has no native two-tier status model. FlitStack creates a custom field Work_Order_Sub_Status__c on crm.lead and maps every active sub-status value from Connect, preserving the full operational resolution state.

Connect Field Service

Work Order Type

maps to

Odoo CRM

Custom field on crm.lead

1:1

Fully supported

msdyn_workordertype stores the service category (repair, inspection, installation, preventive maintenance) with a pick-list of values. Odoo CRM has no native service-type field on opportunities. FlitStack creates Work_Order_Type__c as a custom selection field on crm.lead and maps the pick-list values value-by-value so the operational category survives the migration intact.

Connect Field Service

Service Task (msdyn_serviceTask)

maps to

Odoo CRM

crm.activity / mail.message on crm.lead

many:1

Fully supported

Connect Field Service work orders contain multiple Service Tasks (line items specifying what the technician must perform). FlitStack merges all tasks per work order into a single crm.activity record attached to the migrated opportunity, with task descriptions concatenated and the msdyn estimated duration stored as a custom field. Individual task completion flags migrate as a JSON-encoded custom field for audit traceability.

Connect Field Service

Product / Service (msdyn_product)

maps to

Odoo CRM

product.product

1:1

Fully supported

Connect Field Service product catalog items map directly to Odoo product.product. FlitStack maps product type (msdyn_productservicetype: product vs. service) to Odoo's product_type field, transfers the internal product code to Odoo's default_code, and maps unit cost to lst_price or standard_price depending on the type. Product images and attachments re-upload to Odoo's filestore.

Connect Field Service

Bookings (msdyn_bookings)

maps to

Odoo CRM

Custom field on crm.lead

1:1

Fully supported

Connect Field Service booking records store technician-to-work-order assignments with start/end times, resource IDs, and booking status. Odoo CRM has no native bookings or resource scheduling object. FlitStack preserves the booking data as a JSON-encoded custom field Assigned_Bookings__c on each migrated opportunity and surfaces it in the migration diff so Odoo project management or a third-party FSM module can consume it.

Connect Field Service

Customer Asset (msdyn_customerAsset)

maps to

Odoo CRM

Custom field on res.partner / product.product

1:1

Fully supported

Connect Field Service customer asset records store installed equipment with location, serial number, installation date, and operational status. Odoo CRM has no native asset registry (that lives in Odoo Maintenance module). FlitStack preserves asset data as custom fields on res.partner or product.product, with serial numbers and installation dates in structured custom fields so the information is queryable even without the Maintenance module.

Connect Field Service

Custom Fields on msdyn_workorder

maps to

Odoo CRM

Custom fields on crm.lead

1:1

Fully supported

Any custom fields added to the Work Order object in Connect Field Service settings are individually exported and created as Odoo ir.model.fields entries on crm.lead before migration data loads. FlitStack applies the Odoo field naming convention (snake_case, descriptive) and maps field type (text, date, pick-list, number) to the nearest Odoo field type. Pick-list values are mapped value-by-value.

Connect Field Service

Notes / Attachments on Work Order

maps to

Odoo CRM

ir.attachment on crm.lead

1:1

Fully supported

Work order notes and file attachments (images, PDFs, signatures) are exported from Connect and re-uploaded to Odoo's ir.attachment table linked to the migrated opportunity. Signature capture images from mobile submissions are stored as attachment files. Odoo's 25MB file size limit is enforced per file; files exceeding the limit are flagged for manual retrieval guidance.

Connect Field Service

IoT Alert / Remote Monitoring Data

maps to

Odoo CRM

Custom field on crm.lead / ir.attachment

1:1

Fully supported

Connect Field Service IoT alert records (sensor readings, threshold breaches, remote diagnostic triggers) attach to customer assets and work orders. Odoo CRM has no native IoT connector. FlitStack preserves the most recent alert timestamp and summary as a custom field on the opportunity; full alert history is exported as a JSON file and attached to the opportunity record as a reference document for post-migration IoT integration.

Connect Field Service	Odoo CRM	Compatibility
Account (msdyn_account)	res.partner1:1	Fully supported
Contact (msdyn_contact / Contact)	res.partner1:1	Fully supported
Work Order (msdyn_workorder)	crm.lead (Opportunity)1:1	Fully supported
Work Order Sub-Status	Custom field on crm.lead1:1	Fully supported
Work Order Type	Custom field on crm.lead1:1	Fully supported
Service Task (msdyn_serviceTask)	crm.activity / mail.message on crm.leadmany:1	Fully supported
Product / Service (msdyn_product)	product.product1:1	Fully supported
Bookings (msdyn_bookings)	Custom field on crm.lead1:1	Fully supported
Customer Asset (msdyn_customerAsset)	Custom field on res.partner / product.product1:1	Fully supported
Custom Fields on msdyn_workorder	Custom fields on crm.lead1:1	Fully supported
Notes / Attachments on Work Order	ir.attachment on crm.lead1:1	Fully supported
IoT Alert / Remote Monitoring Data	Custom field on crm.lead / ir.attachment1:1	Fully supported

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.

Connect Field Service gotchas

High

Per-seat licensing applies to dispatchers, technicians, and often read-only users

High

Custom fields and non-standard objects require explicit mapping before migration

Medium

Offline sync state is not persistently exported via standard API

Medium

Scheduling optimization rules and territory logic do not transfer between platforms

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

Connect Field Service gotchas		Odoo CRM gotchas
Severity	Issue	Severity	Issue
High	Per-seat licensing applies to dispatchers, technicians, and often read-only users	High	Odoo.sh version gating blocks assisted migrations from trial
High	Custom fields and non-standard objects require explicit mapping before migration	High	Enterprise modules fail to install on Community after database restore
Medium	Offline sync state is not persistently exported via standard API	Medium	Custom module view inheritance breaks between Odoo major versions
Medium	Scheduling optimization rules and territory logic do not transfer between platforms	Medium	Custom fields risk losing their application context on Community
		Low	API access for Community is gated behind the Custom Plan

Pair-specific challenges

Connect Field Service operational model has no native equivalent in Odoo CRM

Connect Field Service is built around field-technician operations: work order dispatch, technician scheduling, resource booking, IoT alert routing, and multi-site customer asset tracking. Odoo CRM is a sales and lead-management tool — it has no native work order object, no schedule board, no dispatch console, and no IoT connector. The operational semantics of Connect (Work Order status lifecycle, Service Task line items, msdyn_bookings resource assignments) cannot be mapped to standard Odoo CRM fields. They must be translated into custom opportunity fields, stored as structured text or JSON in ir.attachment notes, or accepted as data that requires a separate FSM add-on post-migration. FlitStack surfaces every untranslatable field in the migration plan so your team knows exactly what needs rebuild attention.
IoT alert and remote monitoring data has no destination home

Connect Field Service Connected Spaces and Azure IoT Central integration stores sensor telemetry, threshold alerts, and remote diagnostic readings against customer asset records. Odoo CRM has no IoT module in its standard CRM app — that functionality lives in Odoo IoT (a separate, hardware-oriented module) or requires custom development. FlitStack captures the most recent alert timestamp and alert summary as a custom Char field on the opportunity, and exports the full alert history as a JSON file attached to the record. Your team will need to rebuild the IoT integration with an Odoo-compatible IoT platform or accept the alert history as a reference document post-migration.
Scheduling and dispatch engine is non-transferable

Connect Field Service's schedule board, real-time technician dispatch, and route optimization use the msdyn_bookings object and the Universal Resource Scheduling (URS) engine in Dynamics 365 or Salesforce Field Service. Odoo CRM's scheduling is limited to planned activities on opportunities — there is no schedule board, no resource capacity model, no live dispatch view, and no integration with Google Maps or route optimizers in the base CRM. The msdyn_bookings records (technician-to-work-order assignments with start/end times and resource IDs) are preserved as a JSON-encoded custom field in Odoo, but the scheduling automation, auto-reassignment rules, and travel-time optimization cannot migrate. Teams should plan to use Odoo Project for task scheduling or evaluate a dedicated FSM add-on from the Odoo Apps store.
Connect Field Service Enterprise extensions may require Odoo Enterprise

Some Connect Field Service configurations — particularly those involving IoT monitoring, advanced resource scheduling, or integrations with Dynamics 365 Project Operations — are only available on Salesforce Enterprise or Dynamics 365 Field Service Premium tiers. Odoo Community (the free tier) does not include the Odoo Field Service module, advanced inventory, or IoT connectivity that some FSM-heavy setups require. If your Connect Field Service instance uses Enterprise-only extensions, migrating to Odoo Community may create a functional gap. FlitStack audits your current tier and extension usage during discovery and flags whether Odoo Enterprise is required to preserve equivalent functionality before migration data mapping begins.
Large work order histories require staged import with multi-pass validation

Organizations with multi-year Connect Field Service histories can accumulate tens of thousands of work order records, each with multiple Service Tasks, time entries, and attachments. Odoo's XML-RPC import throttles at approximately 1,000 records per batch, and the crm.lead model has no native bulk-import optimization. FlitStack chunks work order data into validated batches, runs a field-level diff after each batch, and generates a reconciliation report before committing the next chunk. This multi-pass approach adds 1–2 days to the migration timeline for histories exceeding 100,000 work order records but prevents orphaning relationships between work orders, tasks, and attachments mid-load.

Migration approach

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

Schema discovery and field mapping design

FlitStack exports the full Connect Field Service object schema — msdyn_workorder, msdyn_serviceTask, msdyn_account, msdyn_contact, msdyn_product, and all custom fields on each object. We then map each object and field to its Odoo CRM equivalent, creating Odoo custom fields (via ir.model.fields) for any Connect operational fields that have no native Odoo destination. The mapping plan covers pick-list value translations, custom field creation order (since Odoo requires fields exist before data loads), and a dependency graph showing which objects must migrate first.
Sequenced bulk migration in dependency order

Migration runs in strict order: res.partner (accounts) first so company IDs exist; then res.partner (contacts) with parent_id resolved against the migrated accounts; then product.product; then crm.lead records for work orders with the mapped custom fields populated. FlitStack uses Connect Field Service's REST API to pull full record payloads and loads Odoo via XML-RPC. Foreign-key references are validated before each batch commits — if a parent account is missing, its child contacts and work orders are held in a staging queue until the parent resolves. This prevents the orphan-record problem that breaks CRM reporting post-migration.
Sample migration with field-level diff

Before the full run, FlitStack migrates a representative slice — typically 200–500 records covering 3–5 accounts, 10–20 contacts, 5–10 work orders, and 3–5 products. We generate a field-level diff report comparing source and destination values for every mapped field, including custom fields, pick-list values, and timestamps. You review the diff with your team and approve the mapping before FlitStack commits the full migration. Any field mapping errors discovered in the sample are corrected in the mapping plan and the sample re-runs.
Delta-pickup and cutover with in-flight change capture

During the final migration run, FlitStack opens a delta-pickup window of 24–48 hours after the initial load completes. Any Connect Field Service records created or modified during this window — new work orders logged by technicians, status updates, new contacts — are captured in a second incremental migration pass and applied to Odoo. FlitStack logs every delta operation in an audit file. After the delta pass, a final reconciliation report compares record counts and custom field totals between systems. One-click rollback to the pre-migration Odoo snapshot is available if reconciliation finds discrepancies exceeding the agreed tolerance threshold.
Post-migration handoff and rebuild reference export

FlitStack delivers the full migration audit log, a field-mapping reference document, and an export of Connect Field Service workflow and automation definitions as JSON for your Odoo developer or admin to use as a rebuild guide. Scheduling rules, IoT alert triggers, and dispatch optimization logic are documented — not migrated — so your team knows exactly what requires Odoo Studio work, custom module development, or a third-party FSM add-on. The export includes screenshots or config exports from Connect Field Service where available, giving your Odoo admin a concrete reference for each automation that must be rebuilt.

Platform deep dives

Context on both ends of the pair

Connect Field Service

Source

Strengths

Tightly coupled with major CRM backends like Salesforce and Dynamics 365 for unified customer records.
Mobile-first design with offline sync capability for technicians working in low-connectivity environments.
IoT and remote monitoring integration for predictive maintenance alerting.
Dynamic scheduling with territory-based routing and real-time dispatcher reassignment.
Multi-currency and multi-region support for organizations operating across geographic business units.

Weaknesses

Per-user license costs scale linearly with technician and dispatcher count, creating budget pressure during seasonal peaks.
Workflow and business rule configuration requires specialized admin expertise, increasing total cost of ownership.
Custom field and object development requires Salesforce DX or equivalent developer tooling, limiting declarative extensibility.
API rate limits and bulk API availability vary by edition, constraining automated migration throughput.
Offline data synchronization can produce conflicts that require manual resolution when technicians work in intermittent connectivity.

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.

	Connect Field Service Source	Odoo CRM Destination
Strengths	Tightly coupled with major CRM backends like Salesforce and Dynamics 365 for unified customer records. Mobile-first design with offline sync capability for technicians working in low-connectivity environments. IoT and remote monitoring integration for predictive maintenance alerting. Dynamic scheduling with territory-based routing and real-time dispatcher reassignment. Multi-currency and multi-region support for organizations operating across geographic business units.	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	Per-user license costs scale linearly with technician and dispatcher count, creating budget pressure during seasonal peaks. Workflow and business rule configuration requires specialized admin expertise, increasing total cost of ownership. Custom field and object development requires Salesforce DX or equivalent developer tooling, limiting declarative extensibility. API rate limits and bulk API availability vary by edition, constraining automated migration throughput. Offline data synchronization can produce conflicts that require manual resolution when technicians work in intermittent connectivity.	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.

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

POPULAR PLATFORMS

POPULAR MIGRATIONS

Migrate from Connect Field Service to Odoo CRM

What this migration involves

Field-level fidelity

Schema-aware mapping

Relationships preserved

Full activity history

Attachments & notes

Two sides of the same decision