Migrate from GoldMine to Odoo CRM

GoldMine's primary contact record maps to Odoo res.partner with partner_type = contact. Name fields (FIRSTNAME, LASTNAME, COMPANY) parse into Odoo's name field and individual address subfields. Phone, email, and address blocks transfer as typed fields. GoldMine's AccountNo field becomes Odoo's ref field for cross-reference during reconciliation. The RECID from GoldMine becomes an external identifier (external_id) stored in ir.model.data so that activity history can re-link to the correct res.partner after import.

GoldMine Company records map to res.partner with partner_type = company. The Company-Contact linkage in GoldMine becomes the parent_id reference on the contact res.partner record pointing to the company res.partner. Companies are imported before Contacts so that parent_id can be resolved at Contact insert time. Company-level fields such as industry, annual revenue, and number of employees map to Odoo's custom field extensions on res.partner for the company type.

GoldMine Opportunities map to Odoo crm.lead records with type = opportunity. The GoldMine pipeline stage maps to Odoo's stage_id within the mapped pipeline. Probability percentages transfer as Odoo calculates probability automatically from stage by default but accepts a manual override stored in probability. Closed-Won and Closed-Lost stages from GoldMine become Odoo stage records marked as won or lost. If the customer has multiple GoldMine pipeline categories, each becomes a separate Odoo CRM pipeline in CRM > Configuration > Stages.

GoldMine stores communication history in a non-normalized history table with mixed formats (plain text, HTML, MIME-encoded). We extract each history entry, detect encoding format, normalize to plain text or HTML, and write it as a mail.message record linked to the migrated res.partner or crm.lead via model = res.partner or crm.lead and res_id = the migrated record's Odoo ID. Email type entries become mail.message with message_type = email; call and meeting entries become mail.message with subtype comment and a body noting the interaction type and duration.

GoldMine appointments synced from Outlook or entered directly map to Odoo calendar.event records. We extract subject, start datetime, end datetime, location, and attendees. Attendees transfer as calendar.attendee records linked to the res.partner for external attendees and res.users for internal attendees. Recurring appointments are noted as exceptions in the event description and flagged for manual rebuild in Odoo Calendar if the customer uses recurring meeting patterns.

GoldMine attachments stored as database BLOBs extract as binary files with their original filename and MIME type preserved. We re-upload each file as an Odoo ir.attachment record with res_model = res.partner or crm.lead and res_id = the migrated record's Odoo ID. GoldMine attachments stored as file paths on network shares require the file to be accessible at the path in the GoldMine database; any path returning a file-not-found error is flagged for the customer to restore from backup or skip. Attachments over 25MB are flagged for manual re-upload to avoid XML-RPC payload limits.

GoldMine Premium Project records map to Odoo project.project. Project tasks map to project.task with parent_id resolving the Odoo project ID. Milestone dates transfer as stage deadlines on project.task records. If the destination Odoo instance does not have the Project app installed, we map Projects to crm.lead records with custom fields for task names and milestone dates, and the customer installs the Project app during or after migration to promote these to native project records.

GoldMine stores custom fields in separate extended columns linked to CONTACT1, COMPANIES, and other tables by RECID. We run a discovery query against the GoldMine database that enumerates all non-system columns, classifies each as char, float, integer, date, datetime, or selection (picklist), and presents the full inventory for mapping before any data moves. Each mapped custom field is pre-created in Odoo as an ir.model.fields record with the correct ttype, and the customer configures its label and placement in Odoo's form views via Studio after migration.

GoldMine user accounts do not map automatically to Odoo res.users. We extract the full user roster including email, name, and active/inactive status. Matching is performed by email address. Any GoldMine user without a matching Odoo res.users account goes to a reconciliation queue for the customer's admin to provision before record import resumes. Inactive GoldMine users whose records need reassignment are flagged with the target owner for manual reassignment in Odoo before cutover.

GoldMine groups, marketing lists, and tag-like labels stored on records map to Odoo crm.tag records. We extract all distinct group names, create corresponding crm.tag entries in Odoo, and apply them as tag_ids on the crm.lead records at migration time. If GoldMine groups represent marketing list membership rather than CRM pipeline tagging, we map them to a custom res.partner field (e.g., marketing_list_ids) rather than crm.tag, and the customer configures the segment in Odoo's Email Marketing app post-migration.

GoldMine's Sales Literature module files are exported as binary files and re-uploaded to Odoo ir.attachment with res_model = ir.ui.menu as a document library reference. We also attach each literature file to the related res.partner or crm.lead record it was referenced against in GoldMine so that sales reps find relevant materials in the record's attachment list. Literature metadata (document name, category, last modified) becomes the attachment's description field.

GoldMine's dedupe relies on manual user action and does not store duplicate-group metadata. During migration, we run a pre-import deduplication pass on contact records using email address as the primary key and company name as a secondary key. Odoo's native duplicate detection (Contacts > mass duplicate action) is configured to flag the same keys post-migration. Any duplicates identified in GoldMine before migration are resolved manually in a staging pass before production import.