CRM migration
Field-level mapping, validation, and rollback between SellingLane CRM and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
SellingLane CRM
Source
Odoo CRM
Destination
Compatibility
8 of 12
objects map 1:1 between SellingLane CRM and Odoo CRM.
Complexity
BStandard
Timeline
4-6 weeks
Overview
Moving from SellingLane CRM to Odoo CRM is a structural migration from an auction-specific platform into a modular ERP/CRM suite. SellingLane organizes around Buyers, Lots, Auction Events, and Bids; Odoo CRM uses Leads, Contacts, Accounts, and Opportunities. We resolve that schema gap by mapping SellingLane Buyers to Odoo Contacts (for winning bidders) and Leads (for registered but not-yet-winning registrants), Lots to Odoo Products, and Bids to Opportunities with the lot association preserved through a custom Lot Reference field. Auction Event groupings reconstruct as Odoo Tags with a sale-date anchor so auction houses can filter lots by sale session. Workflows, automations, and custom lot-field triggers that exist in SellingLane do not migrate; we deliver a written inventory for the customer's admin to rebuild in Odoo Studio.
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 SellingLane CRM 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.
SellingLane CRM
Buyers
Odoo CRM
Contact or Lead
1:manySellingLane Buyers with a Won bid map to Odoo Contact records attached to an Account. Buyers registered for an auction event but without a winning bid map to Odoo Lead records. We run the split using the presence of a bid record with status Won as the discriminator. Bidder ID from SellingLane becomes a custom field bidder_id__c on the Contact/Lead. Registration date and verification status (a SellingLane custom field) migrate to contact creation date and a custom verification_status__c picklist field.
SellingLane CRM
Lots
Odoo CRM
Product
1:1SellingLane Lots map to Odoo Product records with type=service for intangible auction items or type=product for tangible lots. Lot number becomes the product default_code (SKU field). Item description becomes the product name, reserve price becomes product.list_price, and starting bid becomes product.standard_price. Lot-specific custom fields from SellingLane (which are not schema-documented) require pre-migration field discovery via the SellingLane field configuration endpoint; we create equivalent Odoo Studio fields on product.template before import.
SellingLane CRM
Bids
Odoo CRM
Opportunity
1:manySellingLane Bids are not standalone records; each bid links a Buyer to a Lot and carries timestamp, amount, and bid type (floor, absentee, online). We reconstruct the bid stack as Odoo Opportunity records where the Opportunity name references the Lot and the Opportunity amount references the winning bid. For multi-bid auctions, we preserve the full bid stack in a custom model crm.auction.bid with fields buyer_id, lot_id, amount, timestamp, and bid_type, linked to the parent Opportunity. The Lot-to-Buyer relational link is preserved through Many2one references rather than a flat CSV export that would lose context.
SellingLane CRM
Auction Events
Odoo CRM
Tag (on Product) + Campaign
lossySellingLane Auction Events group lots and bids by sale date, location, and catalog. Odoo CRM has no native Auction Event object, so we reconstruct event groupings as Odoo Tags on the Product records (Lots), with the tag name formatted as the sale title and the tag description carrying the sale date. For auction houses that use Odoo Marketing, we optionally map Auction Events to Odoo Campaign records so that email follow-ups to registered buyers can be tracked against the Campaign. The customer decides the reconstruction strategy during scoping.
SellingLane CRM
Registrations
Odoo CRM
Lead/Contact Activity (Task)
1:1SellingLane Registration records link a Buyer to an Auction Event with registration date and payment method on file. Winning-bidder registrations (Buyer has a Won bid) link to the Contact record as a Task with subject 'Registration for [Event Name]' and registration date in the task date. Non-winning registrations link to the Lead record as a Task. Payment method on file migrates to a custom contact field payment_method__c.
SellingLane CRM
Payments/Checkout
Odoo CRM
Account Move (Invoice)
1:1Post-sale payment records from SellingLane (amount, method, date, buyer association) map to Odoo Account Move (Invoice) records. We create a Customer Invoice for each winning bidder with the Lot purchase as the invoice line, and the buyer payment as a customer payment linked to the invoice. Trust-account balances require a manual reconciliation step because SellingLane trust-account logic (a compliance feature) does not map directly to Odoo's standard accounting; we flag the carry-forward balance for the customer's accountant to post in Odoo Accounting.
SellingLane CRM
Custom Fields (Lot)
Odoo CRM
Custom Fields (product.template)
1:1SellingLane custom fields on auction listings are not schema-documented and must be discovered during the audit phase by querying the platform's field configuration endpoint. We generate a complete field manifest for all active lots, cross-reference each custom field against live lot records to confirm data completeness, and map the definitions to Odoo Studio fields on product.template. Any custom field with a deprecated or deleted definition in SellingLane is flagged for manual review before migration because it can silently drop values.
SellingLane CRM
Attachments (Lots and Buyers)
Odoo CRM
IrAttachment
1:1Item photos, condition reports, and registration documents attach to Lots and Buyers in SellingLane. We export attachments via the platform's file storage using the original filename as the naming key. In Odoo, we re-associate attachments to the corresponding Product (for lot photos) or Contact (for buyer documents) records using the ir.attachment model. Odoo's attachment storage requires a configured filestore path; we coordinate with the customer's Odoo instance admin to ensure the import uses the correct storage location.
SellingLane CRM
Pipeline Stages
Odoo CRM
CRM Stage
lossySellingLane auction-specific stages (Registered, Won, Lost, Paid, Closed) map to Odoo CRM Stage records within the default sales team pipeline. We create a stage mapping during migration scope: Registered maps to New, Won maps to Won, Lost maps to Lost, Paid maps to Won with an invoice issued flag, and Closed maps to Won with all payments received. Stage probability percentages transfer to Odoo Stage probability fields.
SellingLane CRM
Owners/Users
Odoo CRM
Res Users
1:1SellingLane staff assigned as lot owners or bidder managers map to Odoo Res Users. We validate user email uniqueness across the destination Odoo instance and flag any duplicates before import. Active SellingLane users without a matching Odoo user go to a reconciliation queue for the customer's admin to provision. Owner assignments on Lots and Buyers transfer to the related Odoo record's user_id field.
SellingLane CRM
Tags/Labels
Odoo CRM
Forum Tag (on Product)
1:1Classification tags on SellingLane Lots and Buyers migrate to Odoo Forum Tags on product.template and res.partner respectively. Tag-based automations in SellingLane do not transfer because Odoo automation rules are structured differently; we document each SellingLane tag that has an associated automation as part of the automation inventory delivered post-migration.
SellingLane CRM
Bidder Verification Status
Odoo CRM
Custom Field (Contact/Lead)
1:1Bidder verification status in SellingLane (approved, pending, suspended) is stored as a custom property on the Buyer record rather than a native enumerated field. We map this to a custom verification_status__c selection field on the Odoo Contact and Lead models, with the same picklist values preserved. Any buyer's verification status set to a deprecated value no longer in the active picklist is flagged for manual resolution during staging migration.
| SellingLane CRM | Odoo CRM | Compatibility | |
|---|---|---|---|
| Buyers | Contact or Lead1:many | Fully supported | |
| Lots | Product1:1 | Fully supported | |
| Bids | Opportunity1:many | Mapping required | |
| Auction Events | Tag (on Product) + Campaignlossy | Mapping required | |
| Registrations | Lead/Contact Activity (Task)1:1 | Fully supported | |
| Payments/Checkout | Account Move (Invoice)1:1 | Mapping required | |
| Custom Fields (Lot) | Custom Fields (product.template)1:1 | Fully supported | |
| Attachments (Lots and Buyers) | IrAttachment1:1 | Fully supported | |
| Pipeline Stages | CRM Stagelossy | Fully supported | |
| Owners/Users | Res Users1:1 | Mapping required | |
| Tags/Labels | Forum Tag (on Product)1:1 | Mapping required | |
| Bidder Verification Status | Custom Field (Contact/Lead)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.
SellingLane CRM gotchas
Custom fields on lots are not schema-documented
Bid history relies on Lot-to-Buyer relational links
Auction event groupings must be reconstructed
Buyer verification status is a custom field
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
Audit and field discovery
We audit the source SellingLane portal across all active objects: Buyer records with verification status, Lot records with custom field definitions discovered via the platform's field configuration endpoint, Bid records with Lot and Buyer relational links, Auction Event groupings, Registration records, and Post-sale payment data. We generate a field manifest for all SellingLane custom fields on Lots and Buyers, cross-reference each against live records to flag deprecated definitions, and produce a record-count report for every object. The audit output is a written migration scope document that defines the object mapping, the Auction Event reconstruction strategy, and the trust-account carry-forward plan.
Schema design and Odoo configuration
We design the destination schema in Odoo before any data moves. This includes creating Odoo Studio custom fields on product.template to match discovered SellingLane Lot custom fields, creating a verification_status__c selection field on res.partner and crm.lead, creating the crm.auction.bid custom model with lot_id, buyer_id, amount, timestamp, and bid_type fields, configuring CRM Stage values to match SellingLane auction stages (Registered, Won, Lost, Paid, Closed), and setting up the Tag strategy for Auction Event reconstruction. Schema is configured in a sandbox Odoo instance first for validation before applying to the production database.
Sandbox migration and reconciliation
We run a full migration into an Odoo sandbox using production-like data volume. The customer's auction operations lead reconciles record counts (Buyers in, Contacts/Leads in, Lots in, Products in, Bids in, Auction Events reconstructed), spot-checks 25-50 random records against the SellingLane source, and signs off the schema and mapping before production migration begins. Bid relational integrity (that every bid record has a resolved Lot and Buyer reference) is validated programmatically here. Any mapping corrections happen in sandbox, not in production.
Owner reconciliation and Odoo user provisioning
We extract every distinct SellingLane Owner (staff assigned to lots or bidder managers) and match by email against the destination Odoo instance's Res Users table. Any SellingLane Owner without a matching Odoo user goes to a reconciliation queue for the customer's admin to provision before record import resumes. Owner assignments on Lots (Products) and Registrations (Tasks) cannot be placed until the user resolution is complete because Odoo's user_id field requires a valid res.users reference.
Production migration in dependency order
We run production migration in record-dependency order: Products (Lots first, because Bids require a valid product reference), Contacts and Leads (with the Buyer split applied and bidder_id__c preserved), crm.auction.bid records (with product_id and partner_id foreign keys resolved), Tags for Auction Event reconstruction, Tasks for Registrations and Bids, Account Moves (Invoices) for payments, and IrAttachment records for item photos and documents. Each phase emits a row-count reconciliation report before the next phase begins. Trust-account balance carry-forward is posted as a separate journal entry by the customer's accountant.
Cutover, validation, and automation rebuild handoff
We freeze SellingLane 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 inventory document listing every SellingLane workflow and tag-based automation requiring rebuild in Odoo Studio. We support a one-week hypercare window where we resolve reconciliation issues raised by the customer's team. We do not rebuild SellingLane automations as Odoo Studio actions inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
SellingLane CRM
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across SellingLane CRM and Odoo CRM.
Object compatibility
1 of 8 objects need a mapping; the rest are 1:1.
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
SellingLane CRM: Not publicly documented.
Data volume sensitivity
SellingLane CRM 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 SellingLane CRM to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your SellingLane CRM 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 SellingLane CRM
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.