Migrate from ClientTether.com to Odoo CRM

ClientTether Contacts migrate to Odoo res.partner records with partner_type set to 'contact'. Name, phone, email, and address fields map directly. Communication history (SMS threads, email logs, call records) migrates as Odoo mail.message and crm.phone.call records linked to the res.partner via res_id. We preserve all tags as res.partner.category assignments. Parent linkage (Contact to Account) maps to the res.partner parent_id relationship.

ClientTether Leads migrate to Odoo crm.lead records with type='lead'. We preserve lead source attribution, the originating form ID or campaign ID, and any lead scoring values as custom fields on crm.lead. Stage mapping uses ClientTether's pipeline stage names mapped to Odoo's crm.stage sequence. Unqualified leads that should convert during migration follow the customer's lead-to-opportunity qualification criteria documented during scoping.

ClientTether Accounts represent franchisee or franchise owner entities and map to Odoo res.company for multi-company setups or res.partner with is_company=True for single-company configurations. The account hierarchy (brand account, franchise owner account, FBC structure) is exported as nested parent-child relationships and mapped to res.company parent_id or res.partner parent_id depending on the customer's Odoo configuration. We flag any hierarchy depth exceeding three levels for manual review before import.

ClientTether Pipelines map to Odoo crm.team records. Each pipeline stage becomes a crm.stage record within the corresponding team, with stage probability percentages preserved. If ClientTether pipeline names contain special characters or exceed Odoo's 50-character stage name limit, we normalize them during transform. ClientTether deal stage order maps to crm.stage sequence.

ClientTether Deals map to Odoo crm.lead records with type='opportunity', linked to the res.partner Account via partner_id and to the crm.team via team_id. Deal amount, close date, and stage map to expected_amount, date_deadline, and stage_id. Closed-Lost and Closed-Won status migrate from ClientTether's stage properties to Odoo's stage probability and probability fields. We resolve the parent Account and Owner at migration time to satisfy Odoo's opportunity requirements.

ClientTether Proposals migrate to Odoo sale.order records in draft state. Proposal body text migrates as sale.order.line description fields. Pricing and line items map to sale.order.line with product, quantity, and price_unit. Proposal start and end dates migrate as order_line effective dates or as custom fields if the customer requires them. Proposals with template-based rich content may require reformatting; we flag non-standard template elements for manual review before final import and preserve the original proposal URL in a custom field for audit.

ClientTether Work Orders split across two Odoo objects depending on the franchise operational model. Operational work orders (service execution, dispatch) migrate to project.task records linked to the related sale.order via project_id and sale_line_id. Inventory-based work orders migrate to stock.picking records with move lines and stock.move records. We determine the split based on Work Order type documented during discovery. Linked proposal dates and franchise owner assignments migrate as task description fields or custom fields.

ClientTether Tags are used for both segmentation and automation trigger conditions. All tags migrate to res.partner.category for Contact and Account tagging, and to crm.tag for lead and opportunity tagging. Tag trigger-action logic is not portable but is documented in the automation inventory for manual rebuild. We preserve the full tag vocabulary across all objects during migration.

ClientTether Workflows are not fully exposed via the public API and do not migrate as code. We extract the automation configuration from any available ClientTether export (CSV, configuration backup, or screen exports during discovery) and document each automation with its trigger condition, action sequence, time delays, and communication steps (SMS, email, call, task assignment). The document includes a recommended Odoo Studio or server action equivalent for the customer's admin to rebuild post-migration. Automations longer than three steps are flagged as high-effort rebuild items.

ClientTether Email Sequences are time-triggered drip campaigns attached to Leads or Contacts. Sequence step content, timing delays, and enrollment status export from ClientTether. Odoo does not have a native sequence equivalent; we document the sequence cadence and recommend Odoo Marketing Automation (Enterprise) or a third-party sales engagement tool as the replacement. Email template content migrates to Odoo mail.template records for reuse in manual and automated email actions.

ClientTether call records (inbound and outbound with duration, direction, and linked Contact) migrate to Odoo crm.phone.call if the Odoo instance has the VoIP module installed, or to mail.thread.activity records with call metadata in custom fields. Call disposition, duration, and recording URL preserve in custom fields on the activity or phone call record. Missed-call follow-up task generation logic is documented for Odoo server action rebuild.

ClientTether Custom Fields on Contacts, Leads, Accounts, and other objects are enumerated during discovery with field types and picklist options documented. We pre-create equivalent custom fields on Odoo res.partner, crm.lead, res.company, and sale.order using ir.model.fields before data import. Field type mapping handles text to char, number to float or integer, date to date, and picklist to selection fields. Validation logic on ClientTether custom fields is documented for Odoo python constraint recreation if required.

ClientTether User records (name, role, and assignment of Leads and Tasks) migrate to Odoo res.users. We resolve each ClientTether user by email match. Any ClientTether Owner without a matching Odoo user goes to a reconciliation queue for the customer's admin to provision before record import resumes. Task assignments migrate by resolving the user_id reference at migration time; unassigned tasks flag for manual reassignment.