Migrate from Skyward CRM to Odoo CRM

Skyward CRM embeds company data within the contact record using a flat association model. We extract company-name, domain, address, and industry fields from each Skyward contact into a staging Company table, deduplicate by domain, then import Companies first in Odoo so that AccountId resolves on the Contact import. Any Skyward contact without a parent company lands in Odoo as a standalone Contact with a null partner_id, flagged for the customer's admin to review post-migration.

Skyward Lead records map directly to Odoo crm.lead with type='lead'. Lead name, email, phone, company_name (extracted to a stub Company if present), source, and priority migrate as Odoo lead fields. Any Skyward lifecycle-stage or lead-status property migrates as a custom Char field for audit purposes since Odoo's standard lead model uses stage_id rather than a lifecycle property.

Skyward Company records map to Odoo res.partner with customer_rank set to distinguish from Contact-level partners. Skyward's company domain becomes the partner's website field and the dedupe key. We extract industry, annual_revenue, number_of_employees, and address fields to their Odoo equivalents on res.partner. Company is imported before any Contact that references it so that the partner_id foreign key is satisfied.

Skyward Deal records map to Odoo crm.lead with type='opportunity'. Deal name, value, expected_close_date, and owner migrate as name, planned_revenue, date_deadline, and user_id on the Odoo opportunity. The contact_id on the opportunity links to the migrated Contact record. Pipeline stage names from Skyward require explicit mapping to Odoo stage_id records before deal import; we capture the full pipeline configuration during scoping and produce a stage-mapping table.

Each distinct Skyward deal pipeline stage becomes an Odoo crm.stage record within the corresponding team_id. We preserve stage sequence order using Odoo's sequence field. Stage probability percentages migrate from Skyward to Odoo stage probability. Multi-stage pipelines with conditional transitions require additional mapping validation to confirm all opportunity records land in the correct stage after import.

Skyward deal pipelines map to Odoo crm.team records, each with its own crm.stage sequence. A Skyward pipeline maps to one Odoo Sales Team, allowing the customer to separate deals by line of business or territory in Odoo. We configure the team before any opportunity import so that user_id assignments and stage scoping resolve correctly.

Skyward Activity records (calls, emails, meetings, tasks, notes) map to Odoo mail.message, calendar.event, and ir_attachment records. Activity type, date, notes, and duration migrate as the Odoo equivalent. Email content lands as mail.message with partner_ids resolved to the migrated Contact or Lead. Meeting records become calendar.event with start_datetime, stop_datetime, and attendee_ids resolved to the migrated contacts and sales team members.

Skyward Product catalog entries map to Odoo product.template records with name, default_code (SKU), list_price, and description. We extract product pricing and description fields during the extraction phase. Product-to-deal associations in Skyward require junction-table handling: we extract the deal-product associations into a staging table and create Odoo sale.order.line records linked to the migrated Opportunities and Product templates after both objects exist in Odoo.

Skyward's partner management module uses a non-standard schema with fields for partner type, commission structure, and shared lead attribution that do not map to standard Odoo contacts. We extract partner records into a separate staging table with all commission and attribution fields preserved. The customer chooses during scoping whether partner records map to Odoo Contacts with a partner_type custom field or to the Odoo Contacts application if the customer licenses it for partner-facing relationship management.

Skyward Owner records map to Odoo res.users by email match. We extract every distinct owner referenced on Contact, Company, Deal, and Activity records into a reconciliation queue before record import begins. Any Skyward owner without a matching Odoo user is flagged for provisioning before the production migration phase resumes. Inactive owner assignments migrate as user_id on the Odoo record but are flagged for admin review.

Skyward CRM does not expose a public metadata API for custom field enumeration. During scoping we request admin panel access to manually discover all custom fields across Contact, Company, Deal, Activity, and Partner objects. We document each custom field's name, data type, and current values in the field-mapping spreadsheet. Odoo custom fields are created via Settings > Technical > Database Structure > Models before the data import phase, with Char, Integer, Float, Date, Datetime, Boolean, Selection, and Many2one types mapped from the discovered Skyward field types.

Skyward CRM Reports are generated from live data and are not stored as independent record sets. We do not migrate reports because they are configuration artifacts that reference the source data model. Customers rebuild reports in Odoo using its native reporting framework, pivot views, and dashboard designer. We deliver a written list of all source reports and their equivalent Odoo reporting approach during the handoff phase.

Skyward CRM workflow rules and automations are configuration artifacts that do not migrate to Odoo CRM because the two platforms use different automation models. Odoo uses server actions, automated actions, and CRM team-based routing; Skyward uses rule-based triggers with conditions and actions specific to its data model. We deliver a written inventory of every active Skyward automation with its trigger conditions, actions, and a recommended Odoo equivalent for the customer's admin to implement post-migration.