Migrate from GoldMine to Salesforce Sales Cloud

GoldMine's Contact1 table holds the primary contact and company record. We parse the CompanyName field from each Contact1 record to create a Salesforce Account. The Account's Name maps from GoldMine's Company field or the Contact1 record's company identifier. Account is the parent object created first so that subsequent Contact imports can resolve the AccountId lookup. Deduplication uses Account Name as the external ID with fuzzy matching on variations and abbreviations.

GoldMine Contact1 records map to Salesforce Contact. The Contact's AccountId lookup is resolved to the Account created from the same GoldMine CompanyName. Name fields (FirstName, LastName) parse from GoldMine's Name1 or separate FirstName/LastName columns depending on the GoldMine version. GoldMine's Title field maps to Contact.Title, and the primary phone block maps to Phone and MobilePhone on the Contact.

GoldMine Contact2 records represent secondary contacts at the same company as a Contact1 record. We link each Contact2 record to the same Account as the parent Contact1 by matching on the GoldMine internal RECID or company key. Contact2 fields (name, title, phone, email) map to Contact fields identically to Contact1. If GoldMine Contact2 stores a Role value, we map it to the Salesforce Contact Role object on the Account-Contact relationship. Contacts without an email address are flagged during reconciliation for manual review.

GoldMine Companies (separate from the company embedded in Contact1) map directly to Salesforce Account. Where GoldMine stores separate Company and Contact records with a linkage between them, we create a single Account from the Company record and link all Contacts that reference that company. If GoldMine uses only Contact1 records without separate Company records, we extract the distinct CompanyName values and create Accounts from those, treating Contact1 as the account-defining record.

GoldMine Opportunities map to Salesforce Opportunity. The GoldMine pipeline stage name maps to a Salesforce StageName that we configure as part of the Record Type and Sales Process setup. GoldMine's Project or deal value maps to Amount, expected close date maps to CloseDate, and Opportunity name maps to Name. If GoldMine stores multiple deal products per opportunity, we create OpportunityLineItem records in Salesforce after resolving the Pricebook2 reference.

Each GoldMine pipeline becomes a Salesforce Record Type on Opportunity with a corresponding Sales Process that restricts the allowed StageName values to those matching the GoldMine pipeline stages. Stage probability percentages from GoldMine migrate to Salesforce StageProbability values. We configure the Record Type in the destination org before Opportunity migration begins.

GoldMine History records are the migration's highest-risk object. GoldMine stores emails, calls, meetings, and notes in a non-normalized history table with mixed formats including plain text, HTML, and MIME-encoded content. We normalize each entry type: emails become Salesforce EmailMessage records (with the email body in HtmlBody or plain TextBody) linked to an Activity Task; calls become Task with TaskSubtype=Call; meetings become Event with StartDateTime, EndDateTime, and Location; notes become Note linked via ContentDocumentLink. Encoding artifacts are stripped and character set integrity is verified for each record. History completeness testing is performed before sign-off.

GoldMine calendar entries (whether entered directly or synced from Microsoft Outlook via COM integration) map to Salesforce Event. Subject, StartDateTime, EndDateTime, Location, and Description migrate directly. Attendees map to EventRelation records linked to the corresponding Salesforce Contacts, Leads, or Users. Recurring appointments require special handling: each occurrence in the GoldMine recurrence series becomes a separate Salesforce Event record to maintain accurate scheduling data.

GoldMine attachments stored as BLOBs in the database or as files on network shares require extraction and re-upload to Salesforce's ContentDocument model. We export each attachment with its parent record reference, upload to Salesforce as ContentVersion linked to ContentDocument, and create a ContentDocumentLink to the parent Contact, Account, or Opportunity. Network share paths that return file-not-found errors are flagged for the customer to investigate or skip. Attachments over 25MB are flagged for chunked upload via Bulk API.

GoldMine Premium's Project tracking (with tasks, assignments, and milestones) maps to a Salesforce custom Project object if the destination org uses the Salesforce Project Management starter pack or a similar AppExchange solution. Tasks within the GoldMine Project map to Salesforce Task records with a custom parent Task or a custom Milestone__c field. If the destination Salesforce org has no native project object, we map GoldMine Projects to a custom object with a Tasks sub-object and preserve milestone dates as custom date fields. The customer selects the model during scoping.

GoldMine stores custom fields in extended columns linked to the primary record by RECID. These extended tables are not visible in the GoldMine UI and require SQL schema inspection to enumerate. We run a discovery query that pulls all non-system columns across CONTACT1, CONTACT2, COMPANIES, and PROJECTS, classifies each as text, numeric, date, or picklist, and presents the full custom field inventory for mapping. Text fields map to Salesforce Text custom fields; numeric fields map to Number or Currency depending on content; dates map to Date fields; picklist values map to Salesforce Picklist with the allowed values defined before migration. We pre-create the destination custom fields in the Salesforce org before any data import.

GoldMine user accounts do not map automatically to Salesforce Users. We extract the full GoldMine user roster during discovery and match by email address against the Salesforce destination org's User table. Active GoldMine users require a corresponding active Salesforce User before record migration begins. Inactive GoldMine users whose records need reassignment are flagged and their records held in a reassignment queue. Any GoldMine user without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before migration resumes.

GoldMine groups and marketing lists (tag-like labels applied to records) are extracted as segment data and mapped to Salesforce Campaign membership or to the Salesforce Lists feature depending on the destination edition. Group membership logic migrates as CampaignMember records linking each Contact or Lead to its originating GoldMine group. The customer selects Campaign-based segmentation or List-based segmentation during scoping based on their ongoing marketing use case.

GoldMine's Sales Literature module stores content used in mail merges and document generation. We export these files and re-upload them to Salesforce's Salesforce Files (ContentDocument) model, optionally organized into Salesforce ContentLibrary structures. We note which Contact, Account, or Opportunity records reference each Sales Literature document so that ContentDocumentLinks can be created during migration to preserve the association.

GoldMine tag-like labels applied to records (stored as text values in extended columns or as group membership) migrate to Salesforce multi-select picklist fields on the relevant object. If the tag count exceeds Salesforce's 500-value picklist limit for a single field, we create a separate custom object for Tags with a junction relationship to Contacts and Accounts. The customer chooses the tag strategy during scoping.