Migrate from YetiForce CRM to Microsoft Dynamics 365 Sales

YetiForce Organizations map directly to Microsoft Microsoft Dynamics 365 Sales Account records. The Organization name becomes Account Name, industry and type map to Industry and Account Type picklist fields, and address fields map to Address composite fields. We create Accounts first in migration order to satisfy the parent lookup that Contacts, Potentials, and Tickets depend on. Organization-assigned owner maps to Account OwnerId by email match against the Dynamics 365 User table.

YetiForce Contact records map 1:1 to Dynamics 365 Contact. The parent Organization resolves to the AccountId lookup at migration time. Email, phone, job title, department, and address fields transfer directly. We preserve any YetiForce custom contact fields as custom fields on the Dynamics 365 Contact entity, applying the dynamic field schema map built during the audit phase to handle YetiForce's instance-specific cf_* field ID drift.

YetiForce Lead records map to Dynamics 365 Lead. Lead_Source and Lead_Status from YetiForce custom fields migrate as custom fields on the Salesforce Lead entity. If the YetiForce Lead is linked to an Organization, we flag the record for admin review during Salesforce Lead Convert rather than auto-converting, since Lead Convert in Dynamics 365 creates the Account and Contact relationship and we cannot know the customer's preferred conversion behavior without explicit scoping.

YetiForce Potentials map to Dynamics 365 Opportunity. The Organization reference resolves to AccountId, the assigned user resolves to OwnerId, and Potential name becomes Opportunity Name. We build a stage-value configuration table during scoping that maps each YetiForce Potential stage name to the matching Microsoft Dynamics 365 Sales Process stage label, since YetiForce stage names (e.g. Prospecting, Qualification) do not automatically match Dynamics 365 OpportunityStage values. Close Date and Amount transfer directly. Probability percentages are set via the stage configuration table.

YetiForce Products map to Dynamics 365 Product2. ProductName, ProductCode, and UnitPrice transfer directly. Vendor reference from YetiForce resolves by matching vendor name against the migrated Account record (flagged as vendor type) before Product import. We create Standard Pricebook entries during Product migration to support Opportunity product lines.

YetiForce Services share the same data shape as Products and map to Dynamics 365 Product2 with a product type flag distinguishing them from Products. Unit price and description transfer directly. If the customer uses separate product families for Products vs Services in Dynamics 365, we set the Product2 ProductStructure or a custom family field to differentiate during import.

YetiForce Vendor records map to Dynamics 365 Account with a vendor classification. We set Account Type to Vendor and preserve the vendor website and address. Vendor accounts are created before Products to satisfy the Product-to-Vendor lookup before Product migration begins. Assigned owner maps by email match to Dynamics 365 OwnerId.

YetiForce Projects have no direct Microsoft Dynamics 365 Sales standard object equivalent. During scoping we determine whether Projects map to a custom Project object in Dataverse (requires Microsoft Dynamics 365 Sales Premium or custom Dataverse table), to an Account with a project-status custom field, or to Opportunity if project tracking aligns with the sales cycle. Custom fields on YetiForce Projects (tree picklists, reference fields) require type-aware mapping. Project Tasks depend on the Project parent being created first, so Projects migrate before Project Tasks regardless of final destination object.

YetiForce Project Tasks map to Dynamics 365 Task records with WhatId pointing to the parent Project record. Subject, Status, Priority, and assigned user transfer directly. We resolve the assigned user to OwnerId by email match and set Activity Date to the original YetiForce timestamp. Status and Priority picklist values map through the configuration table to match Dynamics 365 allowed values.

YetiForce Tickets map to Dynamics 365 Case if the destination tenant includes Service Cloud or the Sales Hub case entity. Ticket status and priority values map through a picklist configuration table. The related Contact from YetiForce resolves to ContactId on the Case. If Service Cloud is not in scope, Tickets map to a custom Ticket object in Dataverse with a similar field structure. We flag this decision during scoping.

YetiForce User records map to Dynamics 365 User records by email address match. The customer's Dynamics 365 admin provisions Users in the destination tenant before migration begins. We run an owner reconciliation pass that extracts every distinct YetiForce Owner referenced on Contacts, Organizations, Potentials, and Tickets and reports any Owner without a matching Dynamics 365 User to the reconciliation queue. OwnerId references on records cannot be satisfied without a valid Dynamics 365 User ID.

YetiForce file attachments are stored in the file system and linked by record ID. The standard API does not expose binary file download endpoints, so we use YetiForce's built-in Export action per record type to generate downloadable attachment bundles. Files are then re-uploaded to Dynamics 365 as ContentDocument records and linked via ContentDocumentLink to the parent Contact, Account, Opportunity, or Case. PDF and image attachments migrate as-is; any attachments that fail binary export are flagged in the reconciliation report.