CRM migration
Field-level mapping, validation, and rollback between Sunbase Data and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
Sunbase Data
Source
Odoo CRM
Destination
Compatibility
11 of 12
objects map 1:1 between Sunbase Data and Odoo CRM.
Complexity
CModerate
Timeline
3-5 weeks
Overview
Moving from Sunbase Data to Odoo CRM is a structural migration constrained by Sunbase's lack of a documented REST API. Sunbase organizes data across separate CRM, project, HR, and financial modules with independent export interfaces and no unified data dump. We coordinate with Sunbase's technical team to establish an extraction method during discovery, build cross-module relationship maps that connect Contact IDs to Deal IDs and Project IDs to Work Order IDs, and handle Odoo's XML-RPC API with batch chunking and exponential backoff to avoid rate-limit rejections. Sunbase's contractor-specific objects (Projects, Work Orders, Invoices, Employees) map into Odoo's Project Management and HR applications, which require the corresponding Odoo apps to be installed before migration. Pipeline board configurations, automation workflows, and custom module settings are not exportable; we document them manually for the customer's admin to rebuild in Odoo Studio. Odoo implementation timelines range from two to four weeks for straightforward CRM-only deployments to three to six months for full ERP configurations, which affects when the migrated data layer goes live relative to the broader Odoo rollout.
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 Sunbase Data 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.
Sunbase Data
Contact
Odoo CRM
res.partner
1:1Sunbase Contact records map to Odoo res.partner with company_type = 'person'. Standard fields (name, email, phone, street, city, state, zip) migrate directly. Sunbase's industry-specific contact fields (financing status, site address, aerial measurement reference) require Odoo custom fields created in Odoo Studio before migration. Contacts export from Sunbase's CRM module separately from Deals; we match by Sunbase contact_id during the import phase so the Odoo partner_id on any linked Deal resolves at insert time.
Sunbase Data
Lead
Odoo CRM
crm.lead
1:1Sunbase Leads (from door-to-door capture, web forms, and manual entry) map to Odoo crm.lead with type = 'lead'. Lead source and status fields from Sunbase map to Odoo's source_id and stage_id. Sunbase lead assignment data (assigned employee) maps to Odoo's user_id. Any Sunbase lead fields tied to automation workflows are migrated as data only; the automation logic does not transfer and requires rebuild in Odoo Studio.
Sunbase Data
Deal
Odoo CRM
crm.lead
1:1Sunbase Deals map to Odoo crm.lead with type = 'opportunity'. Deal value (currency amount), pipeline stage, and stage history migrate to Odoo's expected_revenue, stage_id, and stage history log. Custom deal fields (permit tracking flags, proposal version, financing approval status) require Odoo custom fields created before migration. Deals without an associated Sunbase Contact are loaded first; Deals with contacts are loaded after Contact migration to satisfy the partner_id lookup.
Sunbase Data
Pipeline Configuration
Odoo CRM
crm.stage + crm.team
lossySunbase pipeline stage names and deal statuses are migrated as Odoo crm.stage records within the relevant crm.team. Stage probabilities are set on each stage record. The visual pipeline board itself is not transferable; we document the stage names, ordering, and probability assumptions in a stage-mapping spreadsheet for the customer's Odoo admin to configure in Odoo Studio after migration.
Sunbase Data
Project
Odoo CRM
project.project
1:1Sunbase Projects (installation or job-site operations) map to Odoo project.project with the Project app installed. Project metadata (name, site address, customer link, status, budget) migrates directly. Sunbase project-specific fields (aerial measurement data, permit tracking, system specifications) map to project.project custom fields. Projects with linked Work Orders are migrated first so that the project_id lookup on Work Order records resolves at insert time. If the customer does not install the Odoo Project app, Projects are migrated as crm.lead custom fields with a note explaining the constraint.
Sunbase Data
Work Order
Odoo CRM
project.task
1:1Sunbase Work Orders map to Odoo project.task with the Project app installed. Task fields (name, description, permit info, system specifications) migrate directly. Linked employee assignments from Sunbase map to project.task user_ids (multi-assignee). Scheduling data (start date, due date) migrates to project.task date_start and date_deadline. Attachments on Work Orders migrate as ir.attachment records linked to the parent task. If the Project app is not installed at the destination, Work Orders are not migratable in standard Odoo CRM alone.
Sunbase Data
Invoice
Odoo CRM
account.move
1:1Sunbase Invoices map to Odoo account.move with move_type = 'out_invoice'. Invoice line items, payment status, and linkage to the originating project or client migrate to Odoo's account.move.line records. The Accounting app must be installed at the destination for invoice migration to succeed. Historical paid invoices are migrated with state = 'posted' and date set to the original invoice date. Draft invoices are migrated with state = 'draft'. Recurring financing-related invoices require Odoo recurring entry configuration post-migration.
Sunbase Data
Employee
Odoo CRM
hr.employee
1:1Sunbase Employee records (HR data, crew assignments, role information) map to Odoo hr.employee. Employee metadata (name, department, job title, hire date) migrates directly. GPS location history is not migratable as structured Odoo data; it is exported as a CSV and archived for the customer's reference. The HR app must be installed at the destination. Crew assignment linking (which employee is on which job) maps to project.task user_ids multi-assignee, which requires the Project app as well.
Sunbase Data
Appointment
Odoo CRM
calendar.event
1:1Sunbase Appointments (customer-linked scheduling synced with Google Calendar) map to Odoo calendar.event. Appointment date, time, duration, and linked contact migrate directly. The Odoo Calendar app must be installed at the destination. Google Calendar linkage is not transferable; appointments land as Odoo-native calendar events and must be re-linked to Google Calendar by the customer's admin post-migration using Odoo's Google Calendar synchronization app.
Sunbase Data
Document
Odoo CRM
ir.attachment
1:1Sunbase Documents (contracts, financing applications, permits, and other files stored within the platform) migrate as Odoo ir.attachment records. File binary content, file name, and upload date transfer directly. The attachment relationship to the parent record (Contact, Deal, Project, Work Order) is preserved via the res_model and res_id fields on ir.attachment. Large binary files are chunked for upload via Odoo's XML-RPC file endpoint.
Sunbase Data
Custom Object
Odoo CRM
ir.model (custom)
1:1Sunbase custom objects within its module system have no documented API or export schema and cannot be programmatically migrated. We coordinate with the customer during discovery to identify custom object records stored in Sunbase's database, export them manually, and recreate them as Odoo custom models via Odoo Studio or Python model definition before importing the data. The customer must provide the custom field manifest during scoping because Sunbase does not export field definition metadata.
Sunbase Data
Owner
Odoo CRM
res.users
1:1Sunbase Owner records (assigned sales reps, project managers) map to Odoo res.users by email match. We extract every distinct Owner referenced on Contact, Lead, Deal, Project, and Work Order records. Any Sunbase Owner without a matching Odoo res.users email is held in a reconciliation queue for the customer's admin to provision the corresponding User before record import resumes. Inactive Sunbase owners map to Odoo res.users with active = False unless instructed otherwise.
| Sunbase Data | Odoo CRM | Compatibility | |
|---|---|---|---|
| Contact | res.partner1:1 | Fully supported | |
| Lead | crm.lead1:1 | Fully supported | |
| Deal | crm.lead1:1 | Fully supported | |
| Pipeline Configuration | crm.stage + crm.teamlossy | Fully supported | |
| Project | project.project1:1 | Fully supported | |
| Work Order | project.task1:1 | Fully supported | |
| Invoice | account.move1:1 | Fully supported | |
| Employee | hr.employee1:1 | Fully supported | |
| Appointment | calendar.event1:1 | Fully supported | |
| Document | ir.attachment1:1 | Fully supported | |
| Custom Object | ir.model (custom)1:1 | Fully supported | |
| Owner | res.users1: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.
Sunbase Data gotchas
No publicly documented REST API or export endpoints
Module-level data isolation complicates bulk exports
Automation workflows and pipeline configurations are non-exportable
Custom fields lack a schema definition export
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
Discovery and extraction method agreement
We audit the source Sunbase instance across all active modules (CRM, project management, HR, financial), custom field usage, active automation workflows, pipeline board stage definitions, document attachment volume, and owner/employee headcount. Crucially, we coordinate with Sunbase's technical team to agree on an extraction method: direct PostgreSQL read access (preferred for data integrity), or manual per-module CSV exports as a fallback. We also identify which Odoo apps the customer will install (CRM, Project, Accounting, HR) because this determines which Sunbase objects can be migrated. The discovery output is a written migration scope document with extraction method, active module list, and destination Odoo app list.
Cross-module relationship mapping
Because Sunbase has no unified export, we build a cross-module ID relationship map from the extracted data. This map connects each Sunbase Contact ID to its associated Deal IDs, each Project ID to its linked Work Order IDs, each Work Order to its assigned Employee IDs, and each Deal or Project to its linked Document IDs. This map is the critical artifact that preserves relationship integrity across the modular export structure. We also deduplicate records at this stage, normalize address formats and phone number formats, and flag records with missing critical fields (contacts without email, deals without value) for customer review before import.
Destination Odoo schema setup
We design the destination Odoo schema based on the scoped Odoo apps. This includes creating custom fields on res.partner for Sunbase contact industry fields, custom fields on crm.lead for Sunbase deal custom properties, custom fields on project.task for Sunbase work order permit and specification fields, and crm.stage records mapped from Sunbase pipeline stage names. If the customer requires the Project app, we configure project.project and project.task with the relevant custom fields. Schema is deployed into the customer's Odoo Sandbox via XML-RPC before any data is imported.
Sandbox migration and reconciliation
We run a full migration into the customer's Odoo Sandbox using production-like data volume. The customer reconciles record counts (Contacts in, Leads in, Deals in, Projects in, Work Orders in, Documents in) against the source system, spot-checks 25-50 random records against the Sunbase source, and validates that linked records (Deal-to-Contact, Work Order-to-Project, Document-to-parent) resolve correctly. Owner and employee email matches against Odoo res.users are validated. Any mapping corrections happen in the Sandbox phase before production migration begins.
Production migration in dependency order
We run production migration in record-dependency order: res.partner (Contacts first), crm.lead (Leads and Deals second, with partner_id resolved), project.project (Projects third, with partner_id resolved), project.task (Work Orders fourth, with project_id and user_ids resolved), hr.employee (Employees fifth), account.move (Invoices sixth, with partner_id and project_id resolved), calendar.event (Appointments seventh), ir.attachment (Documents last, with res_model and res_id resolved). Each phase emits a row-count reconciliation report. We use Odoo's XML-RPC API with batch chunking (default batch size 100 records per request), exponential backoff on rate-limit responses, and parent-record lookup resolution before each phase begins.
Cutover, validation, and automation rebuild handoff
We freeze Sunbase writes during cutover, run a final delta migration of any records modified during the migration window, then enable Odoo as the system of record. We deliver the automation workflow inventory document to the customer's admin team covering Sunbase automation rules and pipeline configurations, with Odoo Studio and server Action equivalents documented for each. We support a one-week hypercare window where we resolve reconciliation issues raised by the customer's team. We do not rebuild Sunbase automations as Odoo Studio actions inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
Sunbase Data
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Moderate CRM migration. 1 of 8 objects need a manual workaround.
Overall complexity
Moderate migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Sunbase Data 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
Sunbase Data: Not publicly documented.
Data volume sensitivity
Sunbase Data 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 Sunbase Data to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your Sunbase Data 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 Sunbase Data
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.