Migrate from Kuverto to Odoo CRM

Kuverto agents may hold or process contact records fetched from connected CRM integrations (HubSpot, Salesforce, Gmail contacts). We extract these records from Kuverto's agent conversation outputs and integration connection metadata during scoping. Each contact maps to an Odoo res.partner with type=contact (individual) or type=company (organization). The partner's email, phone, address, and company affiliation migrate as direct field mappings. Kuverto does not expose a native contact store; we work from agent memory snapshots and integration-connected record exports collected during discovery.

If Kuverto agents connect to platforms that hold company or account records (e.g., a HubSpot Company, a Salesforce Account), we extract those records and map them to Odoo res.partner with type=company. The company domain from Kuverto's integration metadata becomes the partner's website field and is used as a dedupe key during import. Account records are inserted before any child Contact records so that the contact's parent_id (company link) is satisfied at import time.

Kuverto agents may generate deal or opportunity records as structured outputs or stored conversation state. We extract these as structured data exports and map them to Odoo crm.lead records with type=opportunity. The agent-generated deal name becomes crm.lead.name, stage maps to Odoo's stage_id with a stage probability assigned, expected revenue maps to planned_revenue, and the agent-generated close date maps to date_deadline. If Kuverto tracks multiple deal pipelines, each pipeline becomes a separate Odoo Sales Team (crm.team) with its own stage sequence.

Kuverto agents may capture inbound leads via connected webhooks, form integrations, or chat sessions. These map to Odoo crm.lead with type=lead (unqualified prospect). The agent-generated lead score, source attribution, and UTM parameters captured during the agent conversation migrate as custom fields on the Odoo lead. Lead priority maps to crm.lead.priority. Any lead qualification notes generated by the agent become internal notes on the crm.lead record.

Kuverto Workflows are sequential step definitions with trigger conditions and branching logic, each step consuming 1 AO in Workflow Mode. We sequence every step, capture trigger conditions (field changes, scheduled triggers, webhook events), and represent them as Odoo Studio Automated Actions (ir.actions.server) triggered on the same object and condition. Complex branching that exceeds Odoo's condition builder maps to a chain of Server Actions with a Python domain filter to approximate the original logic. The automation rebuild is documented in our handoff inventory; we do not code custom Odoo Python modules as standard scope.

Kuverto agents carry LLM prompt templates, system instructions, tool permissions, and memory settings. Odoo CRM has no autonomous AI agent runtime equivalent. We extract the agent's name, description, and core instruction text as an Odoo CRM template (crm.lead template or mail.template) that a sales rep can apply manually. The agent's tool permission set is documented as a named integration connection in our integration inventory, and the re-authentication checklist maps each tool to its equivalent Odoo integration module. Agent memory settings do not migrate; Odoo does not have a session-memory model.

Kuverto Custom Tools define API endpoint specs, parameter schemas, and response parsing logic used by agents. These map to Odoo's external API credential storage (ir.config_parameter for generic API keys, auth.oauth.provider for OAuth-based integrations). The tool's endpoint URL and authentication headers are documented in our integration handoff as a named credential reference for the Odoo developer to reconnect. Custom tool parameter schemas do not map to Odoo fields without custom development.

Kuverto stores OAuth tokens and API keys for connected third-party platforms (Slack, Gmail, HubSpot, Salesforce, Stripe, etc.) scoped to Kuverto's environment. These credentials are not portable across platforms. We inventory every active Kuverto integration during scoping, document the connection name and intended function, and produce a re-authentication checklist ordered by CRM dependency (which integrations must be live before which CRM features are usable). OAuth token expiration dates are noted so the team knows which integrations go stale first during the migration window.

AO consumption is Kuverto's internal billing meter, not user-owned data. Historical AO usage records cannot be exported and are irrelevant to Odoo CRM's data model. We do not migrate AO records. As a scoping step, we advise the customer to audit their current AO pack balance before migration cutover to avoid paying for unused capacity on Kuverto after the switch.

Agent conversation history and execution logs stored by Kuverto are operational outputs, not configuration data, and cannot be exported via the public-facing platform. We do not migrate them. The customer should export any business-critical run reports before the migration window if agent-generated outputs need to be preserved. In Odoo, these would need to be re-generated from source systems (email, calendar, phone) after integrations are re-connected.

Kuverto team workspaces with role assignments (editor, viewer, integration manager) map to Odoo access rights groups. We extract Kuverto role definitions and map them to the closest Odoo security groups: Kuverto's editor role maps to Sales / User: All Documents; viewer role maps to Portal / Public User; integration manager role maps to Settings / Technical Features. Workspace-level permissions that have no Odoo equivalent are documented in the role mapping appendix.

Kuverto pre-built and customized agent templates carry a name, description, default prompt, and tool set. We extract the template's name and description as an Odoo mail.template record that can be used to pre-fill CRM lead and opportunity communications. The template's default prompt and tool chain do not have an Odoo equivalent and are documented as a Kuverto-specific configuration that the customer's admin must manage outside Odoo or reproduce via a custom module.

Kuverto workflows with scheduled recurrence (daily digest agents, weekly report agents) are represented as Odoo ir.cron records scheduled against the target Odoo model (res.partner, crm.lead). The schedule frequency migrates directly (daily, weekly, monthly interval). The Kuverto agent's output action (send email, update record, create task) maps to an Odoo Server Action with the equivalent mail.post or write action. Timezone handling uses Odoo's company timezone setting.

Kuverto agents may log call and meeting data when connected to calendar or phone integrations. These migrate to Odoo calendar.event (meeting) and crm.phonecall records. The agent-generated call disposition, duration, and participant list map to corresponding Odoo fields. Calendar events preserve start/end datetime; phone calls preserve duration and disposition. Activity timeline ordering is preserved by setting create_date to the original Kuverto log timestamp.