Migrate from Signpost to Odoo CRM

Signpost Contacts migrate directly to Odoo CRM Contacts. Core fields (name, phone, email, address) map 1:1. Signpost's business association (linking a Contact to a Business record) migrates as a Many2one field pointing to the mapped Odoo Company. Tags and segments from Signpost migrate as Odoo Tags via the res.partner.category model. Contact suppression status from Signpost's contact-level messaging controls migrates as a boolean field for re-enrollment rules in Odoo.

Signpost's Business records map to Odoo Companies (res.partner with is_company=True). The parent-child structure in Signpost (franchise locations under a parent business) maps to Odoo's commercial partner model where the parent Company holds the corporate record and child Contacts or Companies represent locations. Address, phone, and website fields migrate directly.

Signpost campaigns (SMS and email) migrate as CRM Leads with a custom campaign_type field (email or sms) and a campaign_name field preserving the original campaign title. Contact targeting lists migrate as Lead Tags so the customer can rebuild campaign membership in Odoo. The automated trigger logic managed by Mia does not migrate (see gotchas); we document the campaign triggers for manual Odoo Business Automations rebuild.

Signpost's review solicitation object has no native Odoo equivalent. We migrate the most recent review request status (requested, responded, positive, flagged, resolved) and the request timestamp as custom fields on the Contact record (e.g., last_review_request_date, last_review_status, last_review_score). Full solicitation history across all time requires flattening into a notes field or a custom Odoo model, which we scope separately during discovery.

Signpost Appointments map to Odoo Calendar.Event records linked to the Contact and Company. Appointment status (scheduled, confirmed, completed, cancelled) maps to Odoo's event state or a custom status field. Custom appointment types (e.g., estimate visit, follow-up call) migrate as custom fields on the event or as tagged Lead records depending on Odoo's module configuration at the destination.

Signpost Payments (a separate product tier) records map to Odoo Account Invoice records if the destination Odoo instance includes the Invoicing app. Payment status (pending, completed, failed, refunded) migrates as Invoice state. Note that Signpost Payments integration requires a compatible Odoo payment provider module; we flag this during scoping if the customer uses Signpost Payments and Odoo Online without the Invoicing app.

Referral and loyalty enrollment records migrate as custom fields on Contact (e.g., loyalty_tier, referral_code, enrollment_date) or as a linked custom Odoo model if the customer's loyalty program has complex point balances. Program rules (point accrual, reward tiers) require manual setup in Odoo and are documented in the automation handoff packet.

Signpost contact segments and tags migrate to Odoo Tags (res.partner.category). We preserve tag names exactly and resolve any segment logic that relied on Mia's behavioral scoring by tagging the segment membership on the Contact record. The customer's admin rebuilds dynamic segment rules in Odoo using its native domain filters.

Signpost Owner assignments on Contacts, Businesses, and Campaigns map to Odoo Users (res.users). We resolve by email match against the destination Odoo instance's user list. Any Signpost Owner without a matching Odoo User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive Signpost owners migrate as inactive Odoo users with a note field for admin review.

Signpost custom fields on Contacts and Businesses migrate as custom fields on Odoo res.partner via Odoo Studio. Field types are preserved where possible (text to char, number to float or integer, date to date, checkbox to boolean, dropdown to selection). Incompatible type mappings (e.g., Signpost array properties with no Odoo equivalent) are flagged for customer review and mapped to a char field with the serialized value.

Mia-driven behavioral triggers (automated review requests, follow-up timing, campaign sequences, contact scoring) are not accessible via any documented export endpoint. We do not migrate them. During scoping, we run a structured Mia workflow audit form with the customer to document every active automation, its trigger conditions, timing rules, and actions. We deliver this as a written handoff document so the customer's Odoo admin or implementation partner can rebuild in Odoo Business Automations.

Signpost's shared inbox stores two-way customer conversations with no export mechanism. Contact records, campaign history, and appointment data migrate cleanly, but the message thread history is not retrievable via any documented endpoint. We flag this upfront during scoping and recommend customers screenshot or manually archive critical threads before migration begins. Message history is considered lost post-migration unless the customer performs a manual archive before the cutover window.