CRM migration

Migrate from Method:Field Services to Odoo CRM

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

Method:Field Services logo

Method:Field Services

Source

Odoo CRM

Destination

Odoo CRM logo

Compatibility

100%

12 of 12

objects map 1:1 between Method:Field Services and Odoo CRM.

Complexity

BStandard

Timeline

72–96 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Method:Field Services organizes field operations around Work Orders, Field Crew dispatch, and QuickBooks synchronization—its CRM layer stores contacts, companies, estimates, and a sales pipeline that mirrors job status. Odoo CRM models the same concepts as crm.lead for leads and opportunities, res.partner for contacts and companies, and sale.order for quotations, with pipeline stages managed through crm.stage records tied to sales teams. The migration carries everything Method stores natively—contacts with addresses, companies with billing details, work order history, estimates, and pipeline stage assignments—into Odoo's relational model. The harder problems are translating Method's work-order-to-job-status workflow into Odoo's opportunity stages, mapping dispatcher and technician assignments to Odoo user records by email match, and preserving estimate-to-invoice lineage where it exists. Automations and custom screens in Method have no Odoo equivalent and must be rebuilt using Odoo Studio. FlitStack uses Odoo's XML-RPC API to write records in dependency order—partners first, then leads/opportunities, then activities—honoring Odoo's foreign-key constraints and ir.sequence numbering for quotations.

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

Method:Field Services logo

Method:Field Services

What's pushing teams away

  • Per-user, role-based pricing scales unpredictably — adding dispatchers costs significantly more than adding technicians, and customers report sticker shock when the pricing conversation arrives.
  • Small companies without a developer on staff find customization time-consuming and expensive, especially when they need custom fields wired into screens beyond the defaults.
  • The scheduling interface has a steep learning curve; multiple reviewers note difficulty mastering the schedule view before becoming productive.
  • When comparing Method's per-user costs against flat-rate alternatives in the FSM space, companies with larger technician fleets report Method becomes the more expensive option at scale.

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 Method:Field Services objects map to Odoo CRM

Each row shows how a Method:Field Services 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.

Method:Field Services

Contact

maps to

Odoo CRM

res.partner

1:1
Fully supported

Method contacts map directly to Odoo res.partner records with company_type='person'. Email, phone, address, and custom fields transfer as partner fields. Company-linked contacts use res.partner's parent_id for the company relationship. This structure allows contacts to be linked to parent company records, enabling hierarchical views of customer data and proper billing/shipping assignments within Odoo's standard partner model.

Method:Field Services

Company

maps to

Odoo CRM

res.partner

1:1
Fully supported

Method companies map to res.partner with company_type='company'. Billing address, shipping address, and industry classification transfer to the partner record. Multi-location companies may require multiple partner records with parent_id linking. This handles scenarios where the same company operates across different sites, with each location stored as a child partner record while maintaining the parent company relationship for reporting and consolidated views.

Method:Field Services

Work Order

maps to

Odoo CRM

crm.lead

1:1
Fully supported

Method work orders map to Odoo crm.lead as opportunities. Job status (Scheduled, In Progress, Completed) maps to pipeline stage. Technician assignment, job location, and time-tracking entries transfer as custom fields on the crm.lead record. This preserves all operational details while fitting into Odoo's standard opportunity framework, allowing teams to leverage built-in CRM reporting and pipeline management tools.

Method:Field Services

Estimate

maps to

Odoo CRM

sale.order

1:1
Fully supported

Method estimates map to Odoo sale.order in quotation state. Line items, pricing, and customer reference transfer. If the Sales app is not installed, estimates land as crm.lead with a custom estimate_reference field for traceability. This ensures estimates aren't lost in migration and can be converted to sales orders later when the Sales module is activated, maintaining the complete audit trail.

Method:Field Services

Sales Pipeline Stage

maps to

Odoo CRM

crm.stage

1:1
Fully supported

Method pipeline stages map value-by-value to Odoo crm.stage records within each sales team. Stage order, probability, and category (e.g., New, Won, Lost) are preserved. Stages without a direct Odoo equivalent become custom stages created before migration. This approach maintains your existing sales process logic in Odoo while allowing flexibility for unique stage definitions that don't have native counterparts in the standard CRM.

Method:Field Services

Dispatcher

maps to

Odoo CRM

res.users

1:1
Fully supported

Method dispatchers resolve to Odoo res.users by email match. Unmatched dispatchers are flagged before migration; you either create Odoo users first or assign their records to a fallback user. Dispatcher permissions map to Odoo group membership (Sales / Field / Portal).

Method:Field Services

Field Crew Technician

maps to

Odoo CRM

res.users / res.partner (portal)

1:1
Fully supported

Technicians map to Odoo res.users if they need system login, or to res.partner with portal access if they only interact via Odoo's customer portal. Work order assignments transfer as custom fields on crm.lead referencing the technician's partner record. This dual approach accommodates different access levels and ensures technicians can view their assignments through the portal without requiring full system credentials.

Method:Field Services

Time Tracking Entry

maps to

Odoo CRM

account.analytic.line

1:1
Fully supported

Method time entries transfer to Odoo account.analytic.line if the Timesheet app is installed. Without it, time data lands as custom datetime fields on the related crm.lead. Original duration, date, and technician user are preserved. If the Timesheet module is activated post-migration, these custom fields can be mapped to proper analytic line records for enhanced reporting and billing integration.

Method:Field Services

Attachment / E-signature

maps to

Odoo CRM

ir.attachment

1:1
Fully supported

File attachments and e-signature images on work orders re-upload to Odoo ir.attachment records linked to the crm.lead. Original filenames and MIME types are preserved. Odoo's 25MB per-file limit is enforced; large files are flagged before migration. This ensures all supporting documentation travels with work orders and remains accessible within the opportunity record, maintaining compliance records and customer communication history.

Method:Field Services

Custom Property (Work Order)

maps to

Odoo CRM

ir.model.fields (x_ prefixed)

1:1
Fully supported

Method custom fields on work orders create corresponding custom fields on crm.lead in Odoo via Studio before migration. Field type mapping: text to char, number to float or integer, date to date, pick-list to selection. Nomenclature follows Odoo's x_ prefix convention for custom fields.

Method:Field Services

Customer Communication History

maps to

Odoo CRM

mail.message / mail.activity

1:1
Mapping required

Method's communication log entries (emails, call notes) migrate to Odoo mail.message records linked to res.partner or crm.lead. Call activities with duration and outcome map to mail.activity with type='call'. Original timestamps and author are preserved. This maintains the full customer interaction history within Odoo's native chatter system, enabling teams to review past communications directly on the opportunity or contact record.

Method:Field Services

QuickBooks Sync Reference

maps to

Odoo CRM

Custom Char field on res.partner / sale.order

1:1
Fully supported

Method's QuickBooks customer ID and invoice reference fields have no native Odoo equivalent. We preserve these as custom char fields (qb_customer_id__c, qb_invoice_ref__c) on the relevant records for audit trail and future reconciliation if a QuickBooks connector is installed. This prevents data loss and allows your finance team to cross-reference historical transactions once a connector is configured, supporting continuity in financial reporting.

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.

Method:Field Services logo

Method:Field Services gotchas

High

Role-based pricing means Dispatchers cost 3× Field Crew

Medium

API daily rate limits scale with active license count

Medium

Custom fields require manual screen assignment post-creation

Medium

Work Order and Field Crew apps are separate pack dependencies

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

  • Work order history has no native Odoo home and requires custom field architecture before migration

    Method:Field Services treats work orders as first-class objects with status, technician assignment, time tracking, and e-signature capture. Odoo CRM has no built-in work order entity—the closest analog is crm.lead. We map work orders to crm.lead and store the field-service-specific data (technician, job location, time entries, signature) as custom fields on the opportunity. This requires Odoo Studio field creation before migration runs; without pre-created custom fields, these values have nowhere to land and are dropped. We deliver a custom field manifest (field name, type, and target model) as part of the migration plan so your Odoo admin can create them in Studio before data transfer begins.

  • Method's QuickBooks sync references break in Odoo and require manual reconciliation workflow

    Method:Field Services stores QuickBooks customer IDs, invoice IDs, and payment references as fields on contacts and transactions. Odoo has no native QuickBooks integration, so these references have no home in a fresh Odoo installation. We preserve them as custom char fields (qb_customer_id__c, qb_invoice_ref__c) on res.partner and sale.order for audit purposes, but Odoo cannot match them to live QuickBooks records. If you plan to run QuickBooks alongside Odoo, you need a third-party connector (such as those on the Odoo Apps Store) or a custom integration to re-establish the sync. We flag every QuickBooks reference during migration so your finance team can audit the gap before go-live.

  • Dispatcher and technician role assignment depends on Odoo user creation before migration

    Method assigns work orders to Dispatchers (who schedule) and Field Crew Technicians (who execute). In Odoo, these roles map to res.users records, but Odoo does not have native Dispatcher or Technician role concepts—access is controlled through group membership (Sales/User, Field/Portal, etc.). We resolve dispatcher and technician email addresses to Odoo user records during migration, but any email without a matching Odoo user is flagged. Your team must create Odoo users for all active dispatchers and technicians before the migration runs, or their records land under a fallback owner. This is a planning dependency, not a data-loss risk, but it extends the pre-migration checklist.

  • Odoo's crm.lead requires stage_id and team_id before opportunity fields can be saved

    Odoo enforces referential integrity on crm.lead records: stage_id and team_id must be set before the record is created via XML-RPC, and custom fields on crm.lead are not writable until those two fields are populated. Method work orders do not have a direct team concept—dispatchers manage work regardless of team. We resolve the target sales team by matching dispatcher to an Odoo sales team, or default to the base CRM team. The practical implication is that Odoo stage records and sales team records must exist in Odoo before migration begins. We deliver a stage-and-team manifest (stage names, sequence, probability, team name) as part of the schema plan so these can be pre-created in Odoo Studio.

  • Method custom screens and workflow logic do not migrate to Odoo Studio automations

    Method:Field Services allows deep customization through custom screens, custom tables, and workflow logic built on its development platform. These artifacts are stored in Method's own database schema and have no structural equivalent in Odoo. Specifically, any custom screens that extend the Work Order or Contact views, any custom relationship tables beyond Method's standard associations, and any workflow rules that fire on field changes or record events must be rebuilt from scratch in Odoo Studio. We export Method's screen definitions, custom table schemas, and workflow configurations as JSON and PDF documentation that your Odoo consultant can use as a rebuild reference. The data migration and the automation rebuild are separate workstreams.

Migration approach

Six steps for a successful Method:Field Services to Odoo CRM data migration

  1. Audit Method data model and export via API

    FlitStack connects to Method:Field Services via its REST API using your account credentials. We pull a complete inventory of all tables accessible via the API: Contact, Company, WorkOrder, Estimate, SalesTransaction, and any custom tables. We also retrieve the custom field definitions from Method's tables/fields configuration endpoint so we know field types and pick-list values. API rate limits are respected (5,000 base + 1,000 per license). The export produces structured JSON per object, with foreign-key references preserved as IDs for later resolution. We validate record counts against your stated scope and flag any tables that require custom field creation in Odoo before migration.

  2. Create Odoo schema: stages, teams, users, and custom fields

    Before any data is written, your Odoo admin (or FlitStack's Odoo consultant) creates the target schema. We deliver a schema manifest: crm.stage records keyed to each Method pipeline stage, crm.team records for each dispatch team, res.users for all active dispatchers and technicians, and custom fields on crm.lead for work-order-specific data (technician, job location, time entries, signature). Custom fields use Odoo Studio's field creation UI and follow the x_ prefix convention. This step is the longest planning step for Method migrations because custom fields on work orders often number 10–30 per installation.

  3. Resolve owner and user references by email match

    Method stores dispatcher and technician assignments as user references (email or internal ID). Odoo requires a res.users record to assign user_id on crm.lead. We run an email match against your Odoo user list: any email with a matching active Odoo user gets the Odoo user ID written to the record. Unmatched emails are flagged in a pre-flight report with the option to create Odoo users before migration or assign to a fallback owner. Contacts without a primary company get attached to a default 'Unassigned Partner' res.partner record. This step prevents foreign-key violations during the crm.lead write phase.

  4. Migrate partners, then leads, then activities in dependency order

    Odoo enforces referential integrity: res.partner records must exist before crm.lead can reference them via partner_id, and crm.lead must exist before mail.message can link to it. We sequence the migration in three phases: (1) res.partner for all contacts and companies, (2) crm.lead for work orders and crm.lead for estimates (as leads with custom fields), with stage_id and team_id set before custom fields are written, and (3) ir.attachment for files and signatures, mail.message for communication history, and account.analytic.line for time entries. Each phase generates a write log and a de-duplication report. Duplicate detection uses Method's internal object IDs stored in x_source_id.

  5. Run sample migration with field-level diff, then cutover with delta pickup

    A representative slice (typically 200–500 records spanning contacts, companies, work orders, and estimates) migrates first. We generate a field-level diff between the Method JSON export and the Odoo XML-RPC response so you can verify stage mapping, technician assignment, custom field population, and attachment linkage. After your sign-off, the full migration runs. A delta-pickup window (24–48 hours) captures any records created or modified in Method during cutover. Audit log captures every operation. One-click rollback is available if reconciliation fails. We deliver a final reconciliation report comparing Method record counts to Odoo record counts per object.

Platform deep dives

Context on both ends of the pair

Method:Field Services logo

Method:Field Services

Source

Strengths

  • Deep bidirectional QuickBooks sync for contacts, invoices, and transactions
  • Purpose-built two-role model (Dispatcher and Field Crew) maps directly to field service org structure
  • Mobile app lets field technicians view jobs, capture e-signatures, and log time on-site
  • Drag-and-drop calendar scheduling with optimized map routing for dispatchers
  • Free training sessions and a developer platform for non-standard customization needs

Weaknesses

  • Role-based per-user pricing is more expensive than flat-seat competitors for large technician fleets
  • Customization requires technical knowledge — small teams without developers struggle with custom fields and custom tables
  • Scheduling UI has a steep learning curve; multiple reviewers cite difficulty mastering the calendar
  • Custom fields must be manually added to screens after creation, a non-obvious workflow for new users
  • API rate limits scale with license count rather than offering high-volume tiers, capping bulk migration throughput
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. 1 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Method:Field Services and Odoo CRM.

  • Object compatibility

    B

    1 of 8 objects need a mapping; the rest are 1:1.

  • 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

    Method:Field Services: 5000 + (1000 × active license count) requests per day, per organization.

  • Data volume sensitivity

    B

    Method:Field Services doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Method:Field Services 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 Method:Field Services to Odoo CRM data migrations

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

Can't find your answer?

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

Book a free 30 minute consultation

Most Method:Field Services to Odoo CRM migrations complete in 72–96 hours of clock time for under 10,000 records (contacts, companies, work orders, estimates). Larger setups with 50,000+ records or extensive custom fields on work orders extend to 7–10 days. The longest single step is pre-migration Odoo schema setup—creating crm.stage records, sales teams, and custom fields for work-order data in Odoo Studio. The actual data transfer via Odoo's XML-RPC API runs in a few hours for a typical field-service dataset.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Method:Field Services.
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