Migrate from APSIS One to Odoo CRM

APSIS One Profiles have no inherent qualification status, while Odoo CRM models prospects as Leads and qualified contacts as Contacts tied to Accounts. We design a routing rule during scoping: Profiles with recent engagement events (last 90 days), explicit purchase intent signals, or a CRM integration source field map to Odoo Lead for sales team qualification. Profiles marked as customers or with closed-won deal history in any linked CRM system map to Contact under a corresponding Account. The original Profile key and any APSIS One source attribution are preserved in custom fields for audit.

APSIS One standard Attributes (email, first name, last name, phone) map directly to Odoo CRM standard Contact fields. Custom Attributes require field-level mapping: we inspect the APSIS One attribute schema during discovery, create equivalent Odoo custom fields via Odoo Studio (with appropriate field types: char, selection, date, integer, float, boolean), and transform values at migration time. Multi-value Attributes map to Odoo tags or multi-select fields depending on cardinality.

APSIS One Tags are flat string labels stored as a list per Profile. Tags export as a per-Profile string array and insert into Odoo CRM Tags using the contacts.mapped('tag_ids') write method. We preserve the full tag set exactly and recreate tag associations on the migrated Lead or Contact record. Tag cardinality is validated against Odoo's tag model limits during scoping.

APSIS One Segments are dynamic or static audience groupings built with rule-based filters. Dynamic Segments cannot migrate directly because Odoo CRM's native segment model is static. We export the Segment definition (rule logic, criteria, and membership count at cutover time), then create corresponding Odoo CRM static segments (Contacts grouped by tag or domain filter) or document the Segment logic for the customer's admin to configure as an Odoo CRM Group post-migration. The Segment name and description are preserved as a tag prefix or CRM Group name.

APSIS One Events (email opens, page views, form submissions, custom events) store a type, timestamp, and optional JSON payload. Odoo CRM models past interactions as Activities: Tasks for action items, Meetings for calendar entries, and Calls for phone interactions. We map event type to Odoo Activity type, set ActivityDate to the event timestamp, and write the event payload as a note on the Activity. High-volume event streams (over 50 events per Profile) are summarized rather than imported as individual activities to avoid overwhelming the Odoo activity timeline.

APSIS One Consent 2.0 stores consent flags and timestamps per channel (email, SMS) as Profile Attributes. We preserve consent records exactly by mapping them to Odoo Contact fields: opt-in status becomes a boolean custom field, consent timestamp becomes a date field, and consent source (form, checkbox, verbal) maps to a selection field. Re-permissioning is avoided by migrating consent as-is and not triggering welcome emails or SMS campaigns during the initial post-migration window.

APSIS One Marketing Automation Canvas flows have no public API for export. We export flow screenshots, trigger conditions, branch logic, and action sequences during the discovery call, then deliver a written Flow Rebuild Document that maps each APSIS One flow step to an equivalent Odoo CRM automation action (stage-based assignment, lead scoring update, tag application, or external webhook). Complex multi-branch flows with delay nodes and A/B splits require the longest rebuild time; we flag these for prioritization in the handoff document.

APSIS One bidirectional CRM integrations (webCRM, Efficy Enterprise, Microsoft Dynamics 365, Lime CRM) maintain live sync state that is not accessible via the public API. We export the current Profile data and the integration configuration (field mappings, sync direction, CRM entity types) as a reference document. The customer's admin re-establishes CRM sync by configuring a new Odoo CRM integration or third-party connector for their CRM, triggering a full resync to repopulate sync metadata on the Odoo side.

APSIS One Sections organize Segments and Flows within an account. We map Section hierarchy to Odoo Teams (crm.team model) or workspace-level Odoo Apps depending on whether the customer is migrating multiple APSIS One accounts or consolidating into a single Odoo instance. Section names become Team names or workspace labels, and Section-level access controls map to Odoo user record rules if the customer's Odoo plan supports multi-team visibility settings.

Every APSIS One Profile has a unique profile key (typically email for known contacts, an anonymous cookie ID for unknown visitors). We use the profile key as the external_id on the Odoo Contact or Lead record, enabling downstream deduplication if the same contact is re-imported. Email address (when available) also maps to the standard email field on the Contact or Lead, serving as the primary dedupe key within Odoo.

APSIS One stores per-Profile channel preferences (email subscribed, SMS subscribed, push enabled) as Attributes. We map these to Odoo CRM custom boolean fields on the Contact or Lead (e.g., x_email_consent, x_sms_consent) with timestamps preserved. Channel-level suppression lists export from APSIS One and upload to Odoo's mailing suppression configuration post-migration to prevent sending to unsubscribed contacts.

APSIS One Profiles linked to a company domain (via company field or domain extraction) map to an Odoo CRM Account. We perform domain-based company matching: profiles sharing the same email domain are grouped and assigned to a single Account record, with the Account name derived from the domain. The Account's website, industry, and address fields populate from any matching APSIS One company Attributes if present.