CRM migration
Field-level mapping, validation, and rollback between MobileWorker and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
MobileWorker
Source
Odoo CRM
Destination
Compatibility
9 of 10
objects map 1:1 between MobileWorker and Odoo CRM.
Complexity
BStandard
Timeline
24–72 hours
Overview
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.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
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
Odoo CRM
res.partner
1:1MobileWorker 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)
Odoo CRM
res.partner (partner_tag + custom fields)
many:1MobileWorker 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
Odoo CRM
crm.lead
1:1MobileWorker 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)
Odoo CRM
project.task
1:1MobileWorker 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
Odoo CRM
res.partner (address)
1:1MobileWorker 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
Odoo CRM
res.partner (company type)
1:1MobileWorker 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
Odoo CRM
res.partner (custom fields)
1:1MobileWorker 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
Odoo CRM
ir.attachment
1:1Files 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
Odoo CRM
mail.message
1:1MobileWorker 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)
Odoo CRM
res.partner custom field (x_)
1:1MobileWorker 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.
| MobileWorker | Odoo CRM | Compatibility | |
|---|---|---|---|
| Worker | res.partner1:1 | Fully supported | |
| Worker (certification fields) | res.partner (partner_tag + custom fields)many:1 | Fully supported | |
| Assignment | crm.lead1:1 | Fully supported | |
| Assignment (no revenue) | project.task1:1 | Fully supported | |
| Location | res.partner (address)1:1 | Fully supported | |
| Customer | res.partner (company type)1:1 | Fully supported | |
| Worker availability schedule | res.partner (custom fields)1:1 | Fully supported | |
| Assignment attachments | ir.attachment1:1 | Fully supported | |
| Activity log entries | mail.message1:1 | Fully supported | |
| Custom property (site-specific field) | res.partner custom field (x_)1:1 | Fully supported |
Gotchas + challenges
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 gotchas
No public API documentation for schema or endpoints
No documented bulk export mechanism
Authentication method not publicly documented
Odoo CRM gotchas
Odoo.sh version gating blocks assisted migrations from trial
Enterprise modules fail to install on Community after database restore
Custom module view inheritance breaks between Odoo major versions
Custom fields risk losing their application context on Community
API access for Community is gated behind the Custom Plan
Pair-specific challenges
Migration approach
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.
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.
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.
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.
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
MobileWorker
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a manual workaround.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across MobileWorker and Odoo CRM.
Object compatibility
1 of 8 objects need a manual workaround.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
MobileWorker: Not publicly documented.
Data volume sensitivity
MobileWorker doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during MobileWorker to Odoo CRM migration scoping. Not seeing yours? Book a call.
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 consultationAdjacent paths
Other ways to leave MobileWorker
Other ways to arrive at Odoo CRM
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.