Migrate from YetiForce CRM to Salesforce Sales Cloud

YetiForce Organizations map to Salesforce Account records. Organization name maps to Account Name; address fields map to BillingAddress composite; industry maps to Industry picklist; type maps to Account Type picklist. Account is created first in migration order so that the AccountId lookup is satisfied at Contact import time. The organization ID from YetiForce is preserved in a custom field yetiforce_id__c for cross-system reconciliation.

YetiForce Contacts map to Salesforce Contact records attached to the migrated Account. First name, last name, email, phone, and address fields map to standard Contact fields. The YetiForce assigned owner resolves to a Salesforce User by email match. Any Contact without a matching Account in the destination org is held in a reconciliation queue because Contact requires an AccountId on standard page layouts.

YetiForce Leads (pre-conversion prospect records) map directly to Salesforce Lead. Lead_Source and Lead_Status custom fields preserve the original YetiForce values and are mapped to Salesforce LeadSource and Status picklists via a configuration table. Unconverted Leads in YetiForce (those that never went through an Organization attachment) map to Salesforce Lead rather than Contact to maintain the qualification funnel.

YetiForce Potentials map to Salesforce Opportunity. The related Organization becomes AccountId; the Potential name becomes Opportunity Name; amount and closing date map directly. YetiForce stage names ( Prospecting, Proposal, Negotiation, Closed Won, Closed Lost) map to Salesforce StageName via a configuration table built during the audit phase. Stage probability percentages migrate from YetiForce to Salesforce StageProbability.

Each YetiForce Potential pipeline becomes a Salesforce Record Type on Opportunity with a corresponding Sales Process that whitelists the relevant stage values. We build the stage mapping during scoping and deploy it to the Salesforce sandbox before any Opportunity data loads. Probability percentages round to the nearest integer allowed by Salesforce.

YetiForce Projects (name, status, start/end dates, assigned owner) do not have a direct Salesforce standard object equivalent. We pre-create a custom Project object (Project__c) in Salesforce with fields for Project Name, Status, Start Date, End Date, and Description. For organizations with Salesforce Field Service licenses, Project maps to ServiceAppointment or a custom WorkOrder extension depending on scope. YetiForce-specific picklist values (tree picklists, reference fields) require type-aware transformation during import.

YetiForce Project Tasks link to a parent Project record and include subject, status, priority, and assigned user. We create a custom Project_Task__c object with a lookup to Project__c (the custom Project object above). Parent record ID mapping requires that the YetiForce Project ID is preserved in yetiforce_id__c so that we can cross-reference and update the Salesforce lookup after Project records are created. Status and priority picklist values map via the configuration table built during audit.

YetiForce Tickets map to Salesforce Case if the destination org includes Service Cloud or Field Service. Ticket title becomes Case Subject; ticket status maps to Case Status via configuration table; priority maps to Case Priority; category maps to a custom Case Category field. Related Contact and Organization references from YetiForce become Case ContactId and AccountId lookups after those records are migrated.

YetiForce Products (name, unit price, vendor link, description, stock levels) map to Salesforce Product2. The vendor reference resolves to a migrated Vendor record by matching on vendor name. Unit price becomes the Standard Price Book entry. Product code maps from YetiForce's product code field. Stock levels migrate to a custom field since Salesforce standard Product2 does not include inventory tracking.

YetiForce Services (recurring offerings with price per unit and description) share the same data shape as Products. They migrate to Salesforce Product2 with the Product Type field set to Service. We create a separate Pricebook entry for each Service so that Opportunity Line Items can reference both Products and Services from the same pricebook.

YetiForce Vendors map to Salesforce Account records with the Account Type field set to Vendor. Company name maps to Account Name; website and address map to standard fields. Vendors are migrated before Products so that the foreign-key relationship between Product and Vendor is satisfied at Product import time. A custom field account_vendor_type__c flags vendor accounts for segmentation.

YetiForce User records (login, name, role, preferences) are mapped to Salesforce User by email address match. Direct user-to-user migration is not performed because Salesforce User provisioning requires admin action and license assignment. We produce a reconciliation report listing every YetiForce owner email and its matched Salesforce User Id. Any YetiForce owner without a Salesforce User match goes to the customer's admin for provisioning before record migration resumes.

YetiForce file attachments are stored in the file system and linked via record ID. The standard API does not expose binary download endpoints, so we use YetiForce's built-in Export action per record type to generate downloadable file sets. Files are then attached to the corresponding Salesforce records via ContentVersion upload and ContentDocumentLink association. Large attachment sets (>5,000 files) are chunked by parent record type to avoid Salesforce storage limits during migration.

YetiForce engagement records (calls, emails, meetings, tasks) map to Salesforce Task, Event, and EmailMessage objects. Call engagements map to Task with TaskSubtype=Call and disposition preserved in a custom field. Email engagements map to EmailMessage records (the content) linked to a Task record (the activity timeline entry). Meeting engagements map to Event with StartDateTime and EndDateTime preserved. Activity timestamps migrate as ActivityDate to maintain timeline ordering. The parent record WhoId and WhatId are resolved via the YetiForce record ID preserved in yetiforce_id__c on the migrated Lead, Contact, Account, or Opportunity.