Migrate from Vryno CRM to Odoo CRM

Vryno Lead records (including auto-assignment by geography, product line, and rep availability fields) map to Odoo crm.lead. Lead scoring fields migrate to crm.lead.x_studio_lead_score or a custom integer field created during schema setup. The Vryno lead_type and assignment_route properties become custom fields on crm.lead if the customer requires them post-migration. We preserve the original lead creation date in crm.lead.create_date and the last modified timestamp in crm.lead.write_date for audit continuity.

Vryno Contacts map to Odoo res.partner records with partner_latitude/longitude for address data. The customer field on res.partner is set to contact (not delivery or invoice) to preserve the person-record semantics. Email deduplication runs on partner_email before insert using a normalized lowercase comparison to catch duplicates that differ only by case. Custom fields on the Vryno Contact record become custom fields on res.partner, created during the schema discovery pass.

Vryno Accounts map to Odoo res.partner records with partner_latitude/longitude set to company (customer = True). The Account name maps to partner_latitude/longitude.name, industry to x_studio_industry (custom field), and address fields to partner_latitude/longitude.street, partner_latitude/longitude.city, partner_latitude/longitude.country_id. The Account-to-Contact relationship is preserved by linking each Contact res.partner record to its parent Account res.partner via the parent_id field on res.partner.

Vryno Deals map to Odoo crm.lead records where stage_id places them in a pipeline stage above the initial qualification state. Deal value maps to crm.lead.planned_revenue; expected close date maps to crm.lead.date_deadline; owner assignment maps to crm.lead.user_id via email lookup against res.users. Stage probability migrates from Vryno to the probability field on crm.lead, rounded to the nearest integer as Odoo requires.

Vryno pipeline stages map to crm.stage records within each crm.team. We create stage records in Odoo matching the Vryno stage name, sequence order, and probability percentage. The Vryno stage color (if used for visual differentiation) maps to a custom field x_studio_stage_color on crm.stage. If the destination is Odoo Community, only one crm.team pipeline is available; multiple Vryno pipelines beyond the first require crm.team creation in Odoo Enterprise.

Each Vryno pipeline becomes an Odoo crm.team record. The team member list (sales reps) maps to crm.team.member_ids by resolving each Vryno Owner email to the corresponding res.users record. If the destination Odoo instance is Community edition, we consolidate to a single crm.team and flag the pipeline reduction in the migration report so the customer understands the visual layout difference before cutover.

Vryno Activity records of type Call map to Odoo mail.message records on the crm.lead model. The call outcome and duration from Vryno populate the message body and a custom field x_studio_call_duration. The message_date carries the original Vryno timestamp to preserve activity timeline ordering. For res.partner-linked calls, the message attaches to the parent partner record instead.

Vryno Activity records of type Meeting map to Odoo calendar.event. Start datetime, end datetime, location, and description migrate directly. Attendees resolve from Vryno contact references to res.partner records, creating calendar.attendee entries for each participant. Recurring meeting patterns in Vryno are documented as a separate note for the Odoo admin because calendar recurrence rules use iCal RRULE format not native to Vryno.

Vryno Activity records of type Email map to Odoo mail.message records with message_type = email. The email body and subject migrate as mail.message.body and mail.message.subject. The email_from field populates from the Vryno sender's contact email. We link each message to the Vryno contact or deal record's Odoo equivalent via res_id and model fields. Note that Odoo requires an active incoming mail server configured for mail.thread to auto-link replies; we document the required configuration steps in the migration handoff.

Vryno Activity records of type Task map to project.task if the task is linked to a Vryno project or custom module with project semantics, or to mail.message on the parent record otherwise. Task status (open, completed) maps to project.task.stage_id or a custom mail.message subtype. The due date from Vryno populates the task date_deadline field.

Vryno Products (name, SKU, unit price) map to Odoo product.template records with product_type = service or product depending on the Vryno product category. The Vryno hs_sku property maps to product.template.default_code. Tax code mapping from Vryno's country-specific taxation module requires a per-country review during schema discovery because Odoo's tax engine uses account.tax records tied to fiscal positions rather than a flat tax code field.

Vryno Custom Modules are user-defined objects with custom field schemas that differ per instance. We perform a schema discovery pass against the source Vryno instance before migration, generating a per-customer field map that targets Odoo custom fields on crm.lead, res.partner, or crm.lead.opportunity (opportunity model) depending on the module's primary relationship. Fields that cannot map to a standard Odoo model are documented as x_ custom fields with their original Vryno field type and value samples. Odoo Studio is required to activate custom field creation in the Odoo UI; we use XML-RPC direct field creation when Studio is not available.

Vryno Custom Dashboards (widget definitions, metric names, and role-based layouts) do not export as data. We document the active dashboard configuration during discovery, capturing the widget types, data source fields, and segmentation logic, so the Odoo administrator can rebuild equivalent dashboard views using Odoo's reporting engine or Studio. Live data queries do not transfer because Odoo re-evaluates reports against its own database.

Vryno Owner assignments on Deals, Leads, and Activities resolve by matching the owner email to res.users.login in the destination Odoo instance. Owners without a matching Odoo user go to a reconciliation queue for the customer's admin to provision the res.users record before record import proceeds. We do not create Odoo users automatically because user provisioning involves access rights and team membership that require admin decisions.