CRM migration
Field-level mapping, validation, and rollback between FotoNotes and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
FotoNotes
Source
Odoo CRM
Destination
Compatibility
12 of 12
objects map 1:1 between FotoNotes and Odoo CRM.
Complexity
BStandard
Timeline
24–72 hours
Overview
FotoNotes structures its data around a Container/Containee model — projects holding work orders that group inspections, vendors, and customers — with a granular role system (Portal Admin, Manager, Field User, Customer, Vendor Admin, Vendor Field User) and heavy reliance on photo attachments as the primary record artifact. Odoo CRM models everything on crm.lead (leads and opportunities share the same table), res.partner for contacts and companies, and ir.attachment for files. There is no native inspection-work-order concept in Odoo CRM, so FlitStack AI translates FotoNotes containers into Odoo leads with a custom Property_Container__c field to preserve the parent-child relationship, and containees into child leads or opportunities linked by that field. FotoNotes role assignments (which are multi-permission sets per user) collapse into a single x_FotoNotes_Roles__c custom field on res.partner since Odoo grants access through user groups, not inline role lists. Photos stored in FotoNotes migrate as binary files re-uploaded to ir.attachment linked to the corresponding Odoo partner or lead record. Workflows, templates, and batch-report definitions have no Odoo equivalent — FlitStack exports FotoNotes template schemas as JSON for manual rebuild in Odoo Studio, and preserves batch report configurations as CSV exports for reimport. The migration uses FotoNotes' REST API for record export and Odoo's XML-RPC API for bulk upsert, with a 24–48h delta-pickup window capturing any records modified during cutover.
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 FotoNotes 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.
FotoNotes
Container (Project)
Odoo CRM
crm.lead
1:1FotoNotes containers (projects) map to Odoo crm.lead records. A custom x_Property_Container__c char field preserves the original FotoNotes container name so the parent-child relationship is queryable within Odoo. Container status maps to crm.stage by matching FotoNotes status labels to Odoo stage names.
FotoNotes
Containee (Work Order)
Odoo CRM
crm.lead
1:1FotoNotes work orders map to Odoo crm.lead records. The parent container ID is stored in x_Parent_Container_ID__c to reconstruct the project hierarchy in Odoo. Work order type (e.g., inspection, maintenance) maps to a custom x_Work_Order_Type__c pick-list on the lead record. The due_date from the work order populates date_deadline, and assigned user emails are resolved to Odoo res.users login identifiers to set user_id.
FotoNotes
Property
Odoo CRM
res.partner
1:1FotoNotes property records map directly to Odoo res.partner records. Property name becomes partner name, street/address fields map field-for-field, and a custom x_FotoNotes_Property_ID__c field stores the source FotoNotes ID for delta-run de-duplication. City, state_id, zip, and country_id are transferred to Odoo partner columns, while phone and email are stored in the partner phone and email fields. The ID field also enables the migration process to skip duplicate properties on subsequent runs.
FotoNotes
Vendor Contact
Odoo CRM
res.partner
1:1FotoNotes vendor contacts (Vendor Admin and Vendor Field User roles) map to res.partner records with vendor=True set. The full FotoNotes role label is stored in x_FotoNotes_Roles__c so the migration plan can specify which Odoo user groups each role maps to on the Odoo side.
FotoNotes
Customer Contact
Odoo CRM
res.partner
1:1FotoNotes customer-role contacts map to Odoo res.partner with customer=True. Customer-specific fields such as the can_view_reports flag are migrated as custom boolean fields on the partner record, preserving the original FotoNotes permission. The FotoNotes customer flag is stored in x_Is_FotoNotes_Customer__c to identify the contact source. Email, phone, and street address are transferred to the partner’s fields, and any role labels are recorded in x_FotoNotes_Roles__c for Odoo access-group assignment.
FotoNotes
Template
Odoo CRM
Custom field schema (JSON export)
1:1FotoNotes inspection templates have no Odoo CRM equivalent — they define required fields, approval chains, and form structure. FlitStack exports each template's field definitions as a JSON schema file and delivers it alongside the migration so your Odoo admin can recreate field sets in Studio.
FotoNotes
Batch Report
Odoo CRM
CSV export (reference file)
1:1FotoNotes batch reports (multi-project PDF exports) have no Odoo equivalent. We export the batch report configuration as CSV with record IDs and timestamps so your team can rebuild scheduled reporting in Odoo using its built-in report designer or a BI connector.
FotoNotes
Photo / File Attachment
Odoo CRM
ir.attachment
1:1FotoNotes inspection photos and flagged images migrate to Odoo ir.attachment linked to the corresponding crm.lead (work order) or res.partner record. Each file is downloaded from FotoNotes storage, Base64-encoded, and POSTed to Odoo's /web/binary/attachment/file endpoint. Files over 25MB are split before upload.
FotoNotes
User (Internal)
Odoo CRM
res.users
1:1FotoNotes internal users (Portal Admin, Manager, User, Field User) are matched to Odoo res.users by email address. Unmatched users are flagged before migration so your Odoo admin can create accounts first. FotoNotes role names are noted in the migration plan for Odoo access-group assignment.
FotoNotes
Activity Log (Status History)
Odoo CRM
mail.message
1:1FotoNotes records status-change timestamps in its activity log. These translate to Odoo mail.message records on the crm.lead, preserving the original timestamp, the user who made the change, and the old/new status values. Body text is formatted as a readable activity note.
FotoNotes
Service / Type Definition
Odoo CRM
Custom field on crm.lead
1:1FotoNotes services and work-order types have no direct Odoo equivalent. We create a custom pick-list field x_Work_Service_Type__c on crm.lead and map each FotoNotes service name to a corresponding pick-list value, preserving the drop-down semantics your team uses to categorize work.
FotoNotes
Comments / Notes on Work Orders
Odoo CRM
mail.message
1:1FotoNotes work order comments migrate as Odoo mail.message records with message_type='comment', attached to the corresponding crm.lead. The timestamp of each comment is stored in the mail.message date field to preserve order. Author is resolved by email match to res.users; if unmatched, the author name is stored in the body as plain text. After migration, comments appear in the lead’s chatter and can be viewed in the Odoo UI alongside history.
| FotoNotes | Odoo CRM | Compatibility | |
|---|---|---|---|
| Container (Project) | crm.lead1:1 | Fully supported | |
| Containee (Work Order) | crm.lead1:1 | Fully supported | |
| Property | res.partner1:1 | Fully supported | |
| Vendor Contact | res.partner1:1 | Fully supported | |
| Customer Contact | res.partner1:1 | Fully supported | |
| Template | Custom field schema (JSON export)1:1 | Fully supported | |
| Batch Report | CSV export (reference file)1:1 | Fully supported | |
| Photo / File Attachment | ir.attachment1:1 | Fully supported | |
| User (Internal) | res.users1:1 | Fully supported | |
| Activity Log (Status History) | mail.message1:1 | Fully supported | |
| Service / Type Definition | Custom field on crm.lead1:1 | Fully supported | |
| Comments / Notes on Work Orders | mail.message1: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.
FotoNotes gotchas
Container-to-contained field inheritance is implicit
Batch PDF reports are the only bulk export mechanism
Vendor sub-accounts require hierarchical mapping
FotoNotes is now SiteCapture — documentation split
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
Export FotoNotes data via REST API and enumerate container/containee hierarchy
FlitStack AI authenticates to FotoNotes using your API credentials (OAuth or API key), exports all Container records, all Containee records with their parent links, all res.partner records (vendors, customers, and internal users), all ir.attachment metadata, all activity log entries, and all template schemas as JSON. The export produces a manifest CSV listing record count per object, average attachment size, and container depth so we can estimate Odoo XML-RPC batch count and flag any FotoNotes accounts with over 1,000 containers early.
Design Odoo custom field schema and stage mapping plan
Based on the FotoNotes export, FlitStack AI creates a schema setup plan: custom fields x_Property_Container__c, x_Parent_Container_ID__c, x_Work_Order_Type__c, x_FotoNotes_Roles__c, x_FotoNotes_Property_ID__c, x_Original_Create_Date__c, x_Work_Service_Type__c, and x_Is_FotoNotes_Customer__c are defined on crm.lead and res.partner. A FotoNotes-status-to-Odoo-stage value map is built per crm.team. A role-mapping plan CSV lists each FotoNotes role and the target Odoo access group. Your Odoo admin creates these fields in Odoo Studio before migration data arrives.
Resolve FotoNotes users and contacts to Odoo res.users and res.partner records
FlitStack AI matches FotoNotes user emails to Odoo res.users login field — matched users get their FotoNotes role stored in x_FotoNotes_Role__c for group assignment. Unmatched users are listed in an unresolved-owners report. All FotoNotes vendor and customer contacts are matched by email to existing Odoo res.partner records; duplicates are flagged for your team to decide whether to merge or keep separate. This step ensures every containee and attachment has a valid res_id before the Odoo write cycle begins.
Migrate partners, containers, and containees in dependency order with XML-RPC batch cycles
FlitStack AI writes FotoNotes vendor and customer contacts to res.partner first (required for foreign-key integrity). Containers are written as crm.lead records with x_Property_Container__c set and stage_id mapped from FotoNotes status. Containees are written as child crm.lead records linked to their parent via x_Parent_Container_ID__c. Each batch of 500 records is followed by a 2-second pause to prevent Odoo worker saturation. Activity log entries are written as mail.message records after their parent crm.lead records exist. A migration audit log records every XML-RPC call's record ID, timestamp, and status.
Re-upload FotoNotes photo attachments to ir.attachment via Odoo binary API
After crm.lead and res.partner records are committed, FlitStack AI downloads each FotoNotes photo from its source URL or binary endpoint, Base64-encodes it, and POSTs it to Odoo's /web/binary/attachment/file endpoint with res_model=crm.lead (or res.partner), res_id pointing to the migrated record, and the original file name preserved. Files over 25MB are split. Attachment names, create dates, and owner IDs are set from FotoNotes metadata. A final attachment count diff is generated against the FotoNotes export manifest to confirm zero missing files.
Run delta pickup, validate record counts and field values, deliver rollback package
FlitStack AI runs a delta pickup window (24–48 hours) to capture FotoNotes records created or modified after the initial export snapshot. Delta records are written in a second migration pass using the same batch-cycle approach. A field-level validation report compares source vs destination counts per object, null-rate per custom field, and attachment completeness. If reconciliation fails, FlitStack AI delivers a one-click rollback that purges all migrated crm.lead, res.partner, and ir.attachment records created by the migration run, leaving your Odoo instance in its pre-migration state.
Platform deep dives
FotoNotes
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. All 8 core objects map 1:1 between FotoNotes and Odoo CRM.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across FotoNotes and Odoo CRM.
Object compatibility
All 8 core objects map 1:1 between FotoNotes and Odoo CRM.
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
FotoNotes: Not publicly documented.
Data volume sensitivity
FotoNotes 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 FotoNotes to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your FotoNotes 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 FotoNotes
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.