Migrate from Striven to Odoo CRM

Striven Customers map to Odoo res.partner records with partner_type set to contact. Customer portal credentials do not migrate; Odoo Portal access requires separate invitation after migration. We preserve the original Striven customer ID in a custom field x_striven_id for reconciliation. Customer-specific Custom Fields (both global and type-level) are audited during discovery to map to Odoo custom fields on the partner record or to a partner-related model.

Striven Vendors map to Odoo res.partner with partner_type set to supplier. Vendor payment terms and tax identification numbers transfer to Odoo's supplier-specific fields. We resolve the vendor-specific type-level Custom Fields during discovery to avoid orphaning fields on the wrong partner subtype in Odoo.

Striven Employee records migrate to Odoo hr.employee for HR purposes, but also serve as the prerequisite for accounting module activation. Employee roles and permissions are not migratable as Odoo access rights must be reconfigured in Settings > Users. We import employee names, contact details, and employment status; permission sets require manual rebuild in Odoo.

Striven's GL Chart of Accounts maps directly to Odoo's account.account. Account numbers, names, and types (Asset, Liability, Equity, Revenue, Expense) transfer using Odoo's standard account type codes. This is a hard prerequisite: the Chart of Accounts must be fully populated in Odoo before any Invoices, Bills, or Journal Entries can be imported. We sequence this as the first object loaded.

Striven Items map to Odoo product.product with type set to product (for inventory items) or service (for non-stocked items). Product code (Item ID), name, list price, standard cost, and unit of measure transfer. Items must exist in Odoo before Sales Orders or Purchase Orders referencing them can be imported. We map Striven's item type flags to Odoo's product_type selection.

Striven Invoices migrate to Odoo account.move with move_type = out_invoice. Invoice headers and line items transfer, with the Customer (res.partner) and Item (product.product) lookups resolved before insert. Convenience Fee and Discount configurations tied to Striven payment methods do not migrate; we document the original settings during discovery for manual reconfiguration in Odoo's Invoicing > Customer Payment Methods.

Striven Bills migrate to Odoo account.move with move_type = in_invoice, following the same dependency chain as Invoices (Vendors, Items, Chart of Accounts must exist first). Tax codes and payment terms that differ between Striven and Odoo require field-level mapping review during scoping. We flag any tax rate mismatches for customer approval before import.

Striven Sales Orders map to Odoo sale.order when the Odoo Sales app is activated. The order must reference an existing Customer (res.partner) and Items (product.product). Striven order status (Draft, Confirmed, Shipped, Invoiced) maps to Odoo sale.order state values. If the customer does not activate the Sales app, Sales Orders cannot be imported; we confirm app activation during scoping.

Striven Purchase Orders map to Odoo purchase.order when the Odoo Purchase app is activated. PO approval workflows attached to POs in Striven do not migrate; Odoo purchase approval rules must be configured separately. Vendor and Item dependencies must be resolved before PO import. We confirm Purchase app activation during scoping since it is a separate Odoo module.

Striven Projects migrate to Odoo project.project. Project phases and milestones map to Odoo project.task hierarchy. Custom fields scoped to specific project types require audit during discovery to map to Odoo project tags or custom project fields. If the Odoo Project app is not activated, Projects cannot be imported; we confirm app scope during scoping.

Striven Tasks under Projects migrate as project.task records with parent_id resolving to the correct project.project. Assignee (Employee) mapping resolves via the hr.employee import. Subtask hierarchies and dependency relationships transfer using Odoo's parent_id and dependency fields. Task-specific Custom Fields are audited against the Odoo project.task model during discovery.

Striven's distinction between global-level and type-level Custom Fields requires field-level audit before migration. Global fields visible on all records of a type map to Odoo custom fields on the corresponding model. Type-level fields scoped to specific entity subtypes (e.g., fields visible only on certain Sales Order types) require individual mapping work to ensure correct visibility in Odoo. We include a custom field audit report in discovery deliverables.