Migrate from AdOrbit to Odoo CRM

AdOrbit Contact records map directly to Odoo res.partner records. The HubSpot-style advertiser-to-company linkage is preserved by sequencing Company imports before Contact imports so that the parent Company (advertiser) record exists before Contact inserts reference it. We map contact-type classification to res.partner partner_latitude fields or custom fields, and preserve custom contact properties as Odoo custom fields created via Odoo Studio before migration.

AdOrbit Company records map to res.partner records with is_company=True. The Advertiser classification in AdOrbit becomes a partner_tag or a custom field on the res.partner record. Company-contact linkage uses parent_id on the Contact-level res.partner record pointing to the Company-level res.partner record. We deduplicate by company name during import.

Ad Tickets are AdOrbit's core campaign execution record spanning print, digital, and service ticket types with status tracking and asset attachments. Odoo has no native Ad Ticket equivalent. We work with the customer during scoping to decide: map to crm.lead with custom fields for ticket type, publication reference, run dates, and pricing terms, or create a custom ad.ticket model via Odoo Studio before migration. Both approaches preserve the ticket's status, assignee, and linked advertiser.

AdOrbit Orders and Proposals map to Odoo sale.order records. Order pricing terms (fixed, CPM, hybrid) become custom fields on sale.order. The link from Order to the Advertiser (res.partner) and to the related Ad Ticket (crm.lead) is preserved via partner_id and x_studio_ad_ticket_id references. E-signature status migrates as a custom field since Odoo sign is a separate app install.

AdOrbit invoices migrate to Odoo account.move records with move_type=out_invoice. Open invoice status, aging data, and payment method fields map to Odoo's account_payment_relation records and aging fields. The advertiser res.partner reference carries through. Two-way QuickBooks Online sync is Odoo-specific configuration beyond the migration scope; historical invoice data migrates as records.

AdOrbit Publications and MagBuilder Layouts define the print layout context for ad tickets. These have no direct Odoo CRM equivalent. We export them as custom records in a publication object (created via Odoo Studio before migration) with fields for publication name, layout metadata, and frequency, or map to product.category with custom fields if the customer prefers a single-model approach. Publication metadata migrates as a lookup reference on Ad Ticket records.

AdOrbit Digital Media and Inventory Module tracks available ad slots, placements, and availability. Odoo's product.product handles product inventory but not media ad slots natively. We export inventory slots as custom ad.inventory records with fields for slot name, placement, dimensions, and availability dates, or map to product.product variants if the customer uses Odoo Inventory. The choice depends on whether the customer wants ad ops data co-located with the CRM or with the Inventory app.

AdOrbit Subscription Management records (recurring billing, subscriber status, billing frequency) map to Odoo sale.subscription if the customer licenses the Odoo Subscription app, or to res.partner with custom subscription fields if the Subscription app is not in scope. Subscription status migrates to the subscription record or custom partner field depending on the destination configuration.

AdOrbit Vendor records (personnel/vendor/subscriber classification) map to res.partner with supplier_rank set to 1 and partner_latitude vendor-type tags. Vendor contact records migrate alongside other res.partner records using the same sequencing and dedupe logic.

AdOrbit Freelancer Management records (rate and assignment data, available on Professional and Enterprise tiers) map to res.partner with custom fields for freelancer_rate, assignment_count, and freelancer_status. If the customer needs freelancer-specific workflows, we create a simple x_freelancer configuration via Odoo Studio before migration. The freelancer-to-Ad-Ticket assignment relationship is preserved as a Many2many link.

AdOrbit Project Management and task tracking (available on higher tiers) map to Odoo project.project and project.task. Task dependencies and assignees map to Odoo project.task records with stage and user assignment preserved. Automation workflows attached to AdOrbit projects are flagged for Odoo project automation rebuild documentation and are not migrated as code.

AdOrbit User records (role-based permissions, sales rep assignments on orders and tickets) map to Odoo res.users by email match. We resolve order and ticket owner references to the Odoo res.users record during migration. Any AdOrbit Owner without a matching Odoo res.users goes to a reconciliation queue for the customer's admin to provision before record import resumes.

AdOrbit ticket assets and uploaded files (exported via FTP or file sharing based on ticket status rule) migrate to Odoo ir.attachment records linked via res_model and res_id to the parent record. We transfer files via the configured export destination or direct download during migration, respecting the ticket status rule to avoid migrating premature or incomplete assets.

AdOrbit custom fields on tickets and contacts are extracted during discovery and pre-created in Odoo via Odoo Studio or direct field creation before any data import. Option lists and conditional logic on AdOrbit custom fields map to Odoo selection fields and computed fields. The full custom field schema, including any dependencies, is documented in the migration specification.