Migrate from Groundhogg to Odoo CRM

Groundhogg Contacts with a status indicating no sales activity (subscriber, lead) map to Odoo CRM Lead. Contacts with a status indicating active sales engagement or customer relationship map to Odoo CRM Contact attached to a Company record. We use Groundhogg's contact status field as the split criterion during migration, and preserve the original status value in a custom field on the Odoo Lead or Contact for audit and reporting continuity.

Groundhogg Company records map to Odoo's res.partner model with partner_type = 'company'. We use the Groundhogg company name as the partner display name and set contact_type = 'contact' for the associated individual Contact records. Company addresses, phone numbers, and website migrate to the corresponding Odoo partner fields. The Company-to-Partner mapping must resolve before Contact import because Odoo requires a parent_company_id on child Contact records.

Groundhogg Contact records without an associated Company map to Odoo res.partner with partner_type = 'individual'. We map email, first name, last name, phone, and address fields directly. Custom fields migrate as Odoo res.partner custom fields created via Odoo Studio before migration. Contact records with an associated Company link via parent_id to the corresponding Company partner record.

Groundhogg tags are a flat taxonomy. We map tags to Odoo CRM crm.tag records created in the destination database. Tags apply to Leads and Opportunities via crm.lead.tag_REL records. Alternatively, we can map tags to Odoo's res.partner.category (contact tags) for broader CRM-wide use. The customer chooses the tag strategy during scoping based on whether they want tags scoped to opportunities or contacts.

Groundhogg Deals map to Odoo CRM crm.lead with type = 'opportunity'. The Groundhogg pipeline stage name maps to Odoo's stage_id, and we create the destination stage values before migration so the foreign key is satisfied at import time. Deal value maps to Odoo's expected_revenue field, and the deal close date maps to the date_deadline field. Owner assignment maps via the WordPress-to-Odoo User email remap.

Groundhogg pipeline stages are available on Pro and above. We export the stage names, display order, and win/loss flags and create corresponding crm.stage records in Odoo. Each stage gets a sequence number matching Groundhogg's ordering. Stages are scoped to the Odoo CRM team if the customer uses team-based pipelines.

Groundhogg custom contact properties map to Odoo res.partner custom fields created via Odoo Studio before migration. Choice and dropdown fields map to Odoo selection fields or many2one relations depending on the field cardinality. We pre-create the destination schema in a staging database during discovery, then deploy it to production before data migration begins.

Groundhogg logs contact activities (email opens, link clicks, form submissions, tag applied, tag removed) as timestamped events. We map these to Odoo mail.message records linked to the res.partner or crm.lead. Each activity type gets a distinct mail.message.subtype to render differently in Odoo's chatter timeline. Email open events map to mail.message with subtype 'email_sent_open', link clicks map to 'email_link_click', form submissions map to 'form_submission'.

Groundhogg contact-level notes migrate to Odoo mail.message records with message_type = 'comment' attached to the corresponding res.partner or crm.lead. Author attribution migrates from the Groundhogg WP user email to the Odoo User id via the owner remap. Note body migrates as plain text; attachments migrate as ir.attachment records linked via res_id/res_model.

Groundhogg maps owners via WordPress user IDs, which have no Odoo equivalent. We extract the Groundhogg WP user email addresses and match them against Odoo res.users by login email. Users without a matching Odoo account go to a reconciliation queue for the customer's admin to provision before record import. Owner assignments on Deals and Contacts resolve via this lookup at migration time.

Groundhogg Broadcast emails are exported with subject, send date, and recipient count as metadata records. We create mail.mass_mailing records in Odoo capturing the broadcast name and send timestamp. The broadcast content and recipient list do not migrate as discrete objects; contacts who received broadcasts are identifiable via the activity history mapping of email_sent_open events. We flag this limitation during scoping so the customer can decide whether to export broadcast content as separate notes.

Groundhogg Flows cannot be exported as automation logic via the REST API. We extract the trigger type, step count, and step names for each Flow and produce a written Flow Audit document listing every automation with its trigger, step sequence, and recommended Odoo Automated Action or server action equivalent. This document is handed off to the customer's Odoo admin or implementation partner for rebuild post-migration.