CRM migration
Field-level mapping, validation, and rollback between SalesTown CRM and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.
SalesTown CRM
Source
Odoo CRM
Destination
Compatibility
9 of 12
objects map 1:1 between SalesTown CRM and Odoo CRM.
Complexity
BStandard
Timeline
4-8 weeks
Overview
Moving from SalesTown CRM to Odoo CRM is a platform-level migration driven by two structural gaps: the absence of a documented public API on the source side and the need for an open, scalable ERP-CRM integration on the destination side. SalesTown CRM has no published endpoint reference, so all extraction relies on its in-product CSV/Excel export, which flattens thread-level WhatsApp activity metadata and applies per-tier row caps that require multiple export cycles to paginate through large datasets. We handle this by running timed export batches, reconstructing parent-child thread relationships in the transform layer using timestamp ordering and sender IDs, and loading parent records (Pipelines, Stages, Accounts, Contacts) before any child records (Deals, Activities) to preserve referential integrity in Odoo. Odoo CRM's modular architecture means the CRM module can be provisioned standalone or alongside Sales, Accounting, and Inventory from the same Odoo instance, which eliminates the dual-system sync problem cited by enterprises leaving SalesTown. We do not migrate Workflows, automations, custom templates, or report configurations; we deliver written inventories of these for your admin to rebuild inside Odoo's automation framework.
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 SalesTown 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.
SalesTown CRM
Lead
Odoo CRM
Lead
1:1SalesTown Leads are the primary acquisition object collected via auto-capture and smart distribution rules. They map 1:1 to Odoo CRM Lead records. The SalesTown lead status and source attribution migrate to Odoo's LeadStatus and Source fields. Any SalesTown custom fields on Lead records create Odoo custom field entries (char, integer, selection) before migration so that no source data is dropped at import time.
SalesTown CRM
Pipeline
Odoo CRM
Team (crm.team)
lossySalesTown Pipelines with configurable Stages map to Odoo CRM Sales Teams. We export the pipeline names, stage order, and stage-specific win/loss flags, then configure Odoo Sales Teams with the matching stage sequence before any Deal records load. If the customer has multiple SalesTown pipelines, we create one Odoo Sales Team per pipeline and attach the stage configuration to each.
SalesTown CRM
Pipeline Stage
Odoo CRM
Stage (crm.stage)
lossySalesTown Stage records carry names, probabilities, and ordering per pipeline. We map each SalesTown stage explicitly to an Odoo Stage by name rather than by position, handling the common case where the source and destination have different stage counts. Stage probability percentages from SalesTown become Odoo Stage probability values. The Odoo stage sequence is ordered to match the SalesTown pipeline flow before Deals import.
SalesTown CRM
Deal
Odoo CRM
Opportunity
1:1SalesTown Deals carry amount, stage assignment, owner, and expected close date. They map to Odoo CRM Opportunity records. The Deal stage maps to Odoo Stage via the pipeline-to-Sales-Team resolution established in the stage mapping step. Closed-won and closed-lost reasons from SalesTown custom fields become Odoo Opportunity lost reason values. Deals are sequenced after Pipelines and Stages during migration to preserve stage associations.
SalesTown CRM
Contact
Odoo CRM
Contact
1:1SalesTown Contact records map 1:1 to Odoo CRM Contact. Standard fields (name, phone, email) transfer directly. Owner assignment migrates by email-based user reconciliation. Custom properties on SalesTown Contacts create corresponding custom fields in Odoo before import; we inspect the CSV export to identify all available fields and flag any that lack a clear Odoo equivalent for post-migration review.
SalesTown CRM
Company (Account)
Odoo CRM
Partner / Company
1:1SalesTown Company records map to Odoo Partner records with the is_company flag set to true. The SalesTown field schema is not publicly documented, so we inspect the export output to identify available company fields and map them to Odoo Partner fields (street, city, country, phone, website, vat). Any unmapped fields are flagged in the field inventory delivered alongside the migration.
SalesTown CRM
Activities: Calls, Emails, WhatsApp
Odoo CRM
Chatter / Tasks / Events
1:1SalesTown Activities are individual touchpoints linked to Contacts or Leads. WhatsApp activities include message status flags that lose thread-level association in flat CSV exports. We reconstruct thread relationships using timestamp ordering and sender IDs during the transform phase, then load individual activities into Odoo Chatter on the corresponding Lead, Contact, or Opportunity record. Calls migrate as Task records with subtype=call; emails migrate as mail.message records in Chatter; generic tasks migrate as Odoo Project Task entries linked to the CRM record.
SalesTown CRM
User / Owner
Odoo CRM
User
1:1SalesTown Users carry name, email, and team assignment. They map to Odoo Users by email address match. Any SalesTown Owner without a matching Odoo User is held in a reconciliation queue for the customer's admin to provision before Deal and Activity imports resume. Duplicate email addresses in the destination Odoo instance block user creation and are flagged during scoping.
SalesTown CRM
Custom Templates
Odoo CRM
Email Templates / Custom Fields
1:1SalesTown custom communication templates exist in the product but have no documented schema. We export available template metadata (name, subject, body content) and attempt to map body structure to Odoo Email Templates using the mail.template model. Template body mapping is flagged as a post-migration cleanup task because template field naming conventions differ between platforms and may require manual adjustment in Odoo's template editor.
SalesTown CRM
Reports / Dashboards
Odoo CRM
Reports (not migrated)
1:1SalesTown CRM report and dashboard definitions are stored server-side with no documented export mechanism. We migrate the underlying data records (Leads, Deals, Activities) so that equivalent reports can be rebuilt in Odoo CRM. The customer receives a written inventory of the report types and dashboard configurations visible in SalesTown, along with recommended Odoo Reporting equivalents (Odoo Invoicing Reports, Sales Analysis, Pipeline Reports) for the admin to implement.
SalesTown CRM
Lead Management System (LMS)
Odoo CRM
Tags / Sales Teams
lossySalesTown LMS associations on Leads (routing rules, lead source attribution, distribution assignments) have no direct Odoo equivalent. We preserve LMS metadata as Odoo Tags on Lead records, preserving the assignment context for post-migration audit. If the customer requires full LMS rule recreation, this is scoped as a separate Odoo automation rebuild task outside standard migration scope.
SalesTown CRM
Custom Objects
Odoo CRM
Custom Models (ir.model)
1:1If the SalesTown instance carries custom objects beyond the standard Contact, Lead, Deal, and Activity schema, we inspect the export for additional record types and map them to Odoo custom models. Odoo supports custom model creation via its Studio app or directly via the ir.model and ir.model.fields interfaces. We pre-create the destination schema including all fields and relational links before any custom object data is loaded.
| SalesTown CRM | Odoo CRM | Compatibility | |
|---|---|---|---|
| Lead | Lead1:1 | Fully supported | |
| Pipeline | Team (crm.team)lossy | Fully supported | |
| Pipeline Stage | Stage (crm.stage)lossy | Fully supported | |
| Deal | Opportunity1:1 | Fully supported | |
| Contact | Contact1:1 | Fully supported | |
| Company (Account) | Partner / Company1:1 | Fully supported | |
| Activities: Calls, Emails, WhatsApp | Chatter / Tasks / Events1:1 | Fully supported | |
| User / Owner | User1:1 | Fully supported | |
| Custom Templates | Email Templates / Custom Fields1:1 | Mapping required | |
| Reports / Dashboards | Reports (not migrated)1:1 | Not supported | |
| Lead Management System (LMS) | Tags / Sales Teamslossy | Fully supported | |
| Custom Objects | Custom Models (ir.model)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.
SalesTown CRM gotchas
iPhone-only app excludes iPad and small-screen devices
No documented public API for programmatic export
WhatsApp activity thread integrity across migration
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
Source data scoping and export design
We audit the SalesTown CRM instance by accessing the CSV/Excel export interface for each object type (Leads, Contacts, Companies, Deals, Activities, Users, Custom Templates). We identify row counts, date ranges, and any export errors or truncation indicators. For large datasets, we design the pagination strategy using creation-date slicing to ensure all records are captured across multiple export cycles. We also document visible automation rules, pipeline configurations, and stage definitions during this phase.
WhatsApp thread reconstruction and transform design
We inspect the exported Activity CSV to assess timestamp granularity, sender IDs, and message status fields. We design the thread reconstruction logic that groups rows by Contact/Lead and conversation ID, orders by timestamp, and assigns sequential message numbers. This transform step is built before any Odoo schema is created so that the output format is finalized before the destination schema is designed.
Odoo CRM schema provisioning
We create the Odoo CRM schema before any data loads: Sales Teams (one per SalesTown pipeline), CRM Stages (mapped by name to SalesTown stage values), custom fields (created to match identified SalesTown custom property names and types), and Partner/Contact/Lead/Opportunity models. If Odoo Sales, Accounting, or Inventory modules are also being provisioned, we coordinate the module installation and shared-partner setup at this stage. Schema is deployed into an Odoo Sandbox or staging database for validation before production.
User reconciliation and Owner provisioning
We extract every distinct SalesTown Owner referenced on Leads, Deals, and Activities and match by email address against the destination Odoo User list. Owners without a matching Odoo User are queued for admin provisioning. This step gates the Deal and Activity imports because OwnerId references must be satisfied at insert time. We also map SalesTown Teams to Odoo Sales Teams for territory-level routing consistency.
Staged data migration and reconciliation
We run a staged migration into the Odoo staging environment in dependency order: Accounts/Partners (from SalesTown Companies), Contacts, Leads, Pipeline Stages and Sales Teams, Deals/Opportunities, Activity history (via Odoo JSON-RPC API with batch chunking and parent-record lookup resolution), and Custom Objects last. Each phase emits a row-count reconciliation report comparing source export counts to Odoo import counts. The customer's admin reviews and signs off the staging results before production migration begins.
Production cutover and automation inventory delivery
We freeze writes to SalesTown CRM during the cutover window, run the final export delta, apply it to the production Odoo database, and validate record counts and data quality post-load. We deliver the automation and template inventory document to the customer's admin team with Odoo equivalent recommendations for each item. We support a one-week hypercare window for reconciliation issues. We do not rebuild SalesTown automations as Odoo automated actions inside migration scope; that is a separate engagement.
Platform deep dives
SalesTown CRM
Source
Strengths
Weaknesses
Odoo CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. All 8 core objects map 1:1 between SalesTown CRM and Odoo CRM.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across SalesTown CRM and Odoo CRM.
Object compatibility
All 8 core objects map 1:1 between SalesTown CRM 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
SalesTown CRM: Not publicly documented.
Data volume sensitivity
SalesTown 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 SalesTown CRM to Odoo CRM migration scoping. Not seeing yours? Book a call.
Walk through your SalesTown 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 SalesTown 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.