CRM migration

Migrate from MobileWorker to Odoo CRM

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

MobileWorker logo

MobileWorker

Source

Odoo CRM

Destination

Odoo CRM logo

Compatibility

90%

9 of 10

objects map 1:1 between MobileWorker and Odoo CRM.

Complexity

BStandard

Timeline

24–72 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

MobileWorker organizes field workforce data around workers, assignments, locations, and site records. Odoo CRM models the same business entities across res.partner (contacts and companies), crm.lead (leads and opportunities), and project.task (service activities). The migration maps each MobileWorker worker profile to a res.partner record, converts assignments into crm.lead opportunities based on revenue potential, and preserves location data as partner addresses with GPS coordinates in custom fields. FlitStack reads MobileWorker via its XML-RPC or REST export endpoints, transforms the data using Odoo's xmlrpc.create() calls, and validates referential integrity before committing. Certification and skills data migrate as partner_tags or custom_char fields on res.partner. Workflows, assignment rules, and scheduling automations require manual rebuild using Odoo's Studio or server actions — FlitStack exports MobileWorker's rule definitions as reference documentation for your Odoo admin. This migration enables field operations teams to transition from standalone workforce management into Odoo's integrated ERP environment where CRM data connects directly to sales quotations, purchase orders, and financial reporting.

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

MobileWorker logo

MobileWorker

What's pushing teams away

  • Pricing is not published on the vendor site — customers must book a discovery call to receive a quote.
  • Reviewer feedback (per Capterra/SoftwareWorld) notes that the platform 'doesn't work when you have no network cable access' — offline behavior may be limited for remote sites.
  • No public API documentation; integrations are configured via vendor engagement.
  • Specialized to UK civil/highways verticals — overseas customers find smaller partner network and localised content.
  • Smaller customer base than mainstream FSM platforms (Jobber, ServiceTitan, IFS) — comparison data is limited.

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 MobileWorker objects map to Odoo CRM

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

MobileWorker

Worker

maps to

Odoo CRM

res.partner

1:1
Fully supported

MobileWorker worker record maps directly to Odoo res.partner. The partner is created as type 'contact'. Employment status and worker type are preserved as custom selection fields on the partner record. Partner email, phone, and mobile map to standard res.partner fields. The original MobileWorker worker ID is stored in a custom char field for reference and delta-run matching during subsequent migration batches.

MobileWorker

Worker (certification fields)

maps to

Odoo CRM

res.partner (partner_tag + custom fields)

many:1
Fully supported

MobileWorker certifications and skill tags merge into Odoo res.partner_tags for broad categorization (HVAC, Electrical, Licensed) plus x_certification_date custom date fields per certification name stored as separate custom_char fields on the partner record. Certification expiry dates use separate custom date fields named x_<certification>_expiry on the res.partner.

MobileWorker

Assignment

maps to

Odoo CRM

crm.lead

1:1
Fully supported

MobileWorker assignments with estimated revenue map to Odoo crm.lead opportunities. The assignment status (Pending, In Progress, Completed) maps to crm.lead stage values via pre-agreed value mapping. Assignment description becomes crm.lead name. The associated customer site links via partner_id lookup against migrated location partners. Expected revenue from the assignment populates the opportunity expected_revenue field.

MobileWorker

Assignment (no revenue)

maps to

Odoo CRM

project.task

1:1
Fully supported

MobileWorker assignments representing time-and-materials work orders without a fixed deal value map to project.task in Odoo's Project app. The task inherits the partner_id from the associated customer location so timesheets, material expenses, and notes route back to the correct customer partner. This prevents zero-value items from cluttering the CRM pipeline.

MobileWorker

Location

maps to

Odoo CRM

res.partner (address)

1:1
Fully supported

MobileWorker location records map to Odoo res.partner addresses on the customer partner. Site name becomes partner name. Street, city, state, zip map to standard address fields. GPS latitude and longitude migrate to x_gps_latitude and x_gps_longitude custom float fields on the partner for map integration and route optimization capabilities.

MobileWorker

Customer

maps to

Odoo CRM

res.partner (company type)

1:1
Fully supported

MobileWorker customer accounts map to Odoo res.partner with company_type = 'company'. Child location partners are created as contacts under the parent company partner using the partner_id / child_ids relationship in Odoo. This preserves the customer-to-site hierarchy from MobileWorker in the Odoo partner structure.

MobileWorker

Worker availability schedule

maps to

Odoo CRM

res.partner (custom fields)

1:1
Fully supported

MobileWorker weekly availability patterns have no direct Odoo equivalent. We preserve the schedule as x_availability_json custom char fields on res.partner containing a JSON structure with day-of-week availability windows. This JSON format allows post-migration custom modules to parse and act on availability data using Odoo's Python model hooks.

MobileWorker

Assignment attachments

maps to

Odoo CRM

ir.attachment

1:1
Fully supported

Files attached to MobileWorker assignments (photos, signed forms, permits) migrate as Odoo ir.attachment records linked to the corresponding crm.lead or project.task via res_model and res_id. Attachment size limits and file type restrictions are respected per Odoo configuration during the migration upload process.

MobileWorker

Activity log entries

maps to

Odoo CRM

mail.message

1:1
Fully supported

MobileWorker log entries for completed tasks, notes, and status changes map to Odoo mail.message records on the parent crm.lead or project.task. Original timestamps, author information, and activity types are preserved from MobileWorker during the message creation in Odoo.

MobileWorker

Custom property (site-specific field)

maps to

Odoo CRM

res.partner custom field (x_)

1:1
Fully supported

MobileWorker custom properties unique to a location (meter numbers, site codes, contract tiers) require Odoo custom fields created as x_<property_name> on res.partner. We generate the complete field creation plan before migration so the Odoo schema is ready before data lands in the system.

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.

MobileWorker logo

MobileWorker gotchas

High

No public API documentation for schema or endpoints

High

No documented bulk export mechanism

Medium

Authentication method not publicly documented

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

  • MobileWorker locations collapse into Odoo partner addresses with GPS in custom fields

    MobileWorker stores locations as standalone records with GPS coordinates and site metadata. Odoo embeds address data into res.partner records with standard street/city/zip fields. GPS latitude and longitude have no native Odoo home — we create x_gps_latitude and x_gps_longitude custom float fields on res.partner. Site-specific custom properties (meter numbers, contract tiers, site codes) require separate custom fields on the partner record. If your MobileWorker setup uses multiple locations per customer, each location becomes a child contact under the parent company partner in Odoo, preserving the site hierarchy.

  • Assignment status values require Odoo stage-by-stage value mapping before migration

    MobileWorker uses custom assignment status values (New, Scheduled, In Progress, Awaiting Parts, Completed, Cancelled) that differ from Odoo's default crm.lead stage names. Odoo's stage_id is a many2one to crm.stage records that must exist in the destination database before mapping can occur. We deliver a stage-mapping plan before migration runs so your Odoo admin creates the required stages first. Probability values per stage are also re-applied from Odoo's side based on your forecast model.

  • Odoo XML-RPC API rate limits cap bulk write throughput

    Odoo's XML-RPC interface has no published per-request rate limit, but server resource constraints and PostgreSQL connection pooling limit sustained write throughput to roughly 500–2,000 records per hour depending on Odoo instance specs and concurrent user load. Large MobileWorker datasets (10,000+ records) run across multiple batch processes to stay within operational limits. We monitor for HTTP 503 responses and retry with backoff automatically. Enterprise Odoo instances with dedicated resources achieve higher throughput than shared-hosting Community deployments.

  • Worker certifications map to partner_tags but date tracking needs custom fields

    MobileWorker certification records carry a certification name and expiry date. Odoo's partner_tags are many2many relations without date attributes. We map certification names to tags for broad filtering and routing but store the expiry date as x_<certification>_expiry custom date fields on res.partner. Certification names with spaces are converted to snake_case for the field technical name (e.g., 'HVAC License' becomes x_hvac_license_expiry). If MobileWorker stores credentials with complex renewal logic, that rebuilds as Odoo automated actions using the stored expiry date.

  • No-equivalent fields for availability schedules require JSON custom field storage

    MobileWorker worker availability patterns (weekly recurring schedules with day/time windows) have no structural equivalent in Odoo res.partner. We store the raw availability structure as a JSON-encoded string in an x_availability_json custom char field. This preserves the data for reference and allows a post-migration Odoo custom module to parse and act on it using Odoo's Python model hooks. Scheduling logic that was automated in MobileWorker must be rebuilt as Odoo server actions or a custom module that reads the JSON availability field.

Migration approach

Six steps for a successful MobileWorker to Odoo CRM data migration

  1. Inventory MobileWorker objects and map to Odoo schema

    FlitStack extracts the full MobileWorker object inventory via API — workers, assignments, locations, customers, activity logs, and attachments. We generate an Odoo schema setup plan that includes custom field definitions (x_gps_latitude, x_gps_longitude, x_worker_id, x_availability_json, per-certification expiry fields), crm.stage records matching your MobileWorker assignment statuses, and partner_tags for certifications and skills. Your Odoo admin creates these schema elements in Odoo before data migration begins to ensure the destination fields exist when records start flowing in.

  2. Resolve partner hierarchy and worker relationships

    Before any records land in Odoo, FlitStack resolves the MobileWorker customer-to-location hierarchy. Each customer becomes a parent res.partner (company_type = company). Each location becomes a child contact under that parent via partner_id / child_ids. Worker records are created as separate res.partner contacts with tag_ids assigned from the migrated certifications and skills list. This step ensures partner_id foreign keys resolve correctly for all crm.lead records that follow.

  3. Migrate assignments to crm.lead with stage mapping

    Assignments with an estimated revenue value migrate as Odoo crm.lead opportunities linked to the customer partner via partner_id. The assignment status maps to stage_id using the pre-agreed stage mapping. Assignments without a revenue value (time-and-materials work orders) migrate as project.task records linked to the same partner. FlitStack generates a field-level diff report showing every mapped field with source value and destination value so you can verify stage mapping and partner linkage before the full run.

  4. Migrate activity logs and attachments

    MobileWorker activity log entries (calls, site visits, status changes) migrate as mail.message records threaded to the parent crm.lead or project.task. File attachments on assignments are downloaded and re-uploaded as Odoo ir.attachment records linked to the corresponding opportunity or task. Inline images in notes are extracted and stored as attachments with the record. This preserves the complete activity history for each assignment under the Odoo chatter interface.

  5. Run delta pickup and audit before cutover

    After the initial migration batch completes, a delta-pickup window (24–48 hours) captures any MobileWorker records created or modified during the cutover period. FlitStack maintains a migration audit log of every create() and write() call with source record ID and destination record ID. One-click rollback reverts all migration writes to Odoo if reconciliation identifies data integrity issues. Once audit passes, your team cuts over to Odoo as the system of record.

Platform deep dives

Context on both ends of the pair

MobileWorker logo

MobileWorker

Source

Strengths

  • Targeted vertical fit for UK civil engineering, construction, highways, plant hire, and traffic management.
  • Lone-worker protection built in (rare among general FSM tools).
  • Vehicle telematics and driver behavior tied to job records.
  • Mobile forms and document attachments cover compliance/site-handover workflows.
  • Free trial without credit card.

Weaknesses

  • No published pricing.
  • Reviewer comments on offline behavior suggest connectivity dependence at remote sites.
  • No public API documentation.
  • UK-centric vertical focus limits overseas fit.
  • Limited third-party reviewer footprint for benchmarking.
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 manual workaround.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across MobileWorker and Odoo CRM.

  • Object compatibility

    B

    1 of 8 objects need a manual workaround.

  • 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

    MobileWorker: Not publicly documented.

  • Data volume sensitivity

    B

    MobileWorker doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your MobileWorker 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 MobileWorker to Odoo CRM data migrations

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

Can't find your answer?

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

Book a free 30 minute consultation

Small sets under 5,000 records (workers, assignments, locations) complete in 24–72 hours of clock time. Mid-size datasets between 5,000 and 50,000 records extend to 3–7 days depending on custom field count and whether certification or availability data requires JSON transformation. Large setups exceeding 50,000 records with complex custom properties run 1–3 weeks. The longest planning step is agreeing on Odoo crm.stage names and creating the custom field definitions before data migration begins.

Adjacent paths

Related migrations to explore

Ready when you are

Move from MobileWorker.
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