Migrate from myCRMS.com to Microsoft Dynamics 365 Sales

myCRMS.com Company records map to Microsoft Dynamics 365 Sales Account. We use the Company name as the Account Name and domain as Website for deduplication. Account is the parent record and must be created before any Contact import so that the AccountId lookup is satisfied at Contact insert time. We flag any Company records without a primary contact during pre-migration audit so the customer can decide whether to create standalone Accounts or suppress orphan records.

myCRMS.com Contact records map to Microsoft Dynamics 365 Sales Contact with AccountId set to the resolved Account from the Company mapping. Standard fields (FirstName, LastName, Email, Phone, JobTitle) migrate directly. Custom fields discovered during the pre-migration audit are mapped to typed Dataverse columns (text, number, date, picklist, lookup) before any Contact records load. OwnerId resolves by email match against the Dynamics 365 User table.

myCRMS.com Deals map to Microsoft Dynamics 365 Sales Opportunity. The deal stage from myCRMS.com maps to a corresponding StageName value within a Sales Process that we configure during destination setup. If myCRMS.com exposes closed-won and closed-lost dates, these map to CloseDate and a custom loss-reason field. We create the Opportunity's Record Type and Sales Process in Dynamics 365 before migration so that stage values are valid at insert time.

Each distinct pipeline or stage group in myCRMS.com becomes a Microsoft Dynamics 365 Sales Process and an Opportunity Record Type. We map stage names from myCRMS.com to StageName values within the Sales Process and configure probability percentages per stage. The Record Type controls the Page Layout that sales reps see when opening an Opportunity.

myCRMS.com Owners map to Microsoft Dynamics 365 Sales User records by email address. We extract the distinct Owner list from Contact, Company, and Deal exports and cross-reference against the destination User table. Any Owner without a matching Dynamics 365 User enters a reconciliation queue; the customer's admin provisions the missing User before record import resumes. Active and inactive status is preserved as a boolean flag.

myCRMS.com engagement records (calls, emails, meetings, notes) map to Dynamics 365 Task and Event objects. Calls migrate as Task with TaskSubtype = Call. Emails migrate as EmailMessage records with the body preserved and linked to the parent Contact or Opportunity. Meetings migrate as Event with StartDateTime and EndDateTime. Notes migrate as Note records linked via ContentDocumentLink to the parent Contact, Account, or Opportunity. Activity timestamps are preserved in ActivityDate.

Custom fields discovered during the myCRMS.com pre-migration audit are pre-created in Microsoft Dynamics 365 Sales as typed Dataverse columns before data migration begins. We map field types (text to Text, number to Number, date to DateTime, dropdown to Picklist) and create any dependent picklist values. Custom field names from myCRMS.com become API-compatible names in Dynamics 365 with the __c suffix. The customer reviews and approves the custom field schema in the Dynamics 365 sandbox before production migration.

myCRMS.com Smart Lists are named saved filters for contacts and deals. Smart Lists do not migrate as data or as configured filters. We deliver a written inventory of every Smart List with its filter conditions, sort order, and visible columns. The customer's Dynamics 365 admin recreates these as Saved Views using the Advanced Find tool. The handoff document includes the filter logic in a format compatible with Dynamics 365 query builder.