Migrate from myCRMS.com to Salesforce Sales Cloud

myCRMS.com contact records contain embedded company information that we split into two objects. The company name and domain from each contact record become a Salesforce Account. We deduplicate by company name during the extract phase so that multiple contacts from the same company produce a single Account. The Account is created before any Contact import so that the AccountId lookup is satisfied at the moment of Contact insert. Any website or domain data becomes the Account Website field.

myCRMS.com contact records map to Salesforce Contact with AccountId resolved from the company split in step one. The contact's name, email, phone, title, and address fields map to standard Salesforce Contact fields. Custom fields on the myCRMS.com contact are mapped to Salesforce custom fields (with __c suffix) whose types are determined during the pre-migration schema audit. Any myCRMS.com owner assignment resolves to a Salesforce User by email match.

myCRMS.com company records that exist independently of contacts (not derived from an embedded field) map directly to Salesforce Account. Company name becomes Account Name; industry and website migrate to standard Account fields. If both a standalone company record and an embedded company from a contact record share the same name, they are merged into a single Account during deduplication before insert.

myCRMS.com Deal records map to Salesforce Opportunity. Deal name becomes Opportunity Name; deal value maps to Amount; expected close date maps to CloseDate. The deal stage from myCRMS.com becomes StageName in Salesforce, and we configure a corresponding Sales Process before migration so that only the relevant stage values appear per Record Type. AccountId on Opportunity is resolved via the company lookup derived from the embedded or standalone company on the source deal record.

myCRMS.com pipeline stages are read from the source export and mapped to Salesforce Opportunity Stage values. We configure a Salesforce Sales Process with the exact stage values from myCRMS.com, preserving stage probability percentages where the source exposes them. Stage ordering is preserved to maintain pipeline visualization accuracy in Salesforce reports.

If myCRMS.com exposes multiple deal pipelines in the export, each pipeline becomes a Salesforce Opportunity Record Type with its own Sales Process and Page Layout. This allows different lines of business within the customer's org to use different stage sets without conflict. Record Types are configured in the Salesforce Sandbox before any Opportunity data is loaded.

myCRMS.com owner assignments on Contact, Company, and Deal records are resolved by email match against the Salesforce destination org's User table. Any owner without a matching Salesforce User is held in a reconciliation queue for the customer's admin to provision before record import resumes. We flag inactive Salesforce Users against active myCRMS.com owners so the admin can decide whether to create an active user or map to a generic system user.

Where the myCRMS.com export exposes activity timestamps on Contact or Deal records (last contacted date, last modified timestamps, or engagement dates), these migrate to Salesforce Task records linked to the Contact or Opportunity. The ActivityDate is set to the original timestamp from myCRMS.com to preserve the activity timeline order. If the source exposes activity type (call, email, meeting), the TaskSubtype is set accordingly.

myCRMS.com Smart Lists are filtered saved views of contacts or deals. These do not migrate as code because Salesforce list views are a different filter syntax. We deliver a written inventory of every active Smart List with its filter conditions and criteria, so the customer's admin can recreate them as Salesforce list views using standard filter logic. Smart Lists that represent segmentation for campaigns map to Salesforce Campaign with Campaign Member Status.

myCRMS.com custom field schemas are discovered during the pre-migration audit where the source exposes them. Each custom field is type-mapped to a Salesforce field type (Text, Number, Picklist, Checkbox, Date, etc.) based on the data values observed. Custom fields are created in Salesforce before any data load, and __c API names are matched to the source field label for readability. Any picklist values in myCRMS.com become Salesforce picklist values on the corresponding custom field.

myCRMS.com engagement records of type call or note migrate to Salesforce Task. Subject, description, and activity date migrate from the source. If call duration is exposed, it maps to CallDurationInSeconds on the Task. OwnerId on the Task is resolved via the User email match. Task is linked to the Contact or Opportunity via WhatId or WhoId as the source relationship permits.

myCRMS.com email engagements migrate as Salesforce EmailMessage records (the email body and headers) linked to an Activity Task (the timeline entry). The WhoId on the Task points to the Contact; the WhatId points to the related Opportunity or Account. Subject and timestamp preserve from the source. We use Bulk API 2.0 for email migration because the volume can exceed REST API limits at scale.