Migrate from ConSol*CM to Salesforce Service Cloud

ConSol*CM Request records map to Salesforce Case. The Request ID becomes an External ID field on Case for upsert integrity. Request status maps to Case Status, priority maps to Case Priority, and origin/source information maps to Case Origin. Any custom field groups attached to a Request are extracted field-by-field and mapped to Salesforce custom fields (Custom__c) on Case. Conversation history linked to the Request migrates as Salesforce EmailMessage records attached to the Case.

ConSol*CM Contacts map to Salesforce Contact with the Contact's primary organization mapped to a Salesforce Account. ConSol*CM's extensible contact model with field groups requires explicit field-by-field mapping because the system documentation export describes field existence but does not provide a machine-readable schema. We extract the field group configuration during discovery, map each field to a typed Salesforce field, and resolve any multi-value fields (e.g., multi-select picklists) to Salesforce equivalents. Contacts without an organization map to a placeholder Account for reconciliation.

ConSol*CM Resources represent internal staff and system entities that appear as owners or assignees on Requests and workflow activities. Resource records map to Salesforce User by email resolution. Any Resource without a matching Salesforce User is placed in a reconciliation queue for the customer's admin to provision. We preserve the original Resource name and ID in a custom field consol_resource_id__c on User for audit and cross-reference.

Conversations linked to ConSol*CM Requests are exported via the REST API and imported as Salesforce EmailMessage records (for email-thread content) and CaseComment records (for internal notes and messaging activity). Author attribution, timestamp, and internal/external flags are preserved. The EmailMessage WhoId links to the migrated Contact; the CaseId links to the migrated Case.

File attachments associated with Requests and Contacts are downloaded from ConSol*CM and re-uploaded to Salesforce as ContentVersion records linked to the parent record via ContentDocumentLink. We handle filename deduplication by appending the source record ID to duplicates, and we verify attachment size against Salesforce's 25 MB per file limit during staging. Files exceeding the limit are flagged for the customer to split or re-host externally.

Tags on ConSol*CM Requests and Contacts export as flat lists. We map them to Salesforce Topics with TopicAssignment records for cross-object tagging, or to a custom multi-select picklist field (consol_tags__c) on Case and Contact if the customer prefers tag isolation per object. The customer chooses the strategy during scoping.

ConSol*CM team structures map to Salesforce Queues (for case routing) or Groups (for internal organization). We preserve team-to-agent assignments from the Resource mapping and flag any differences between ConSol*CM's permission model and Salesforce's role hierarchy and sharing model that affect ticket routing and visibility.

ConSol*CM field groups define custom property sets on Contacts that vary per installation. We extract the field group configuration from the system documentation export and map each field individually to Salesforce Contact custom fields. Date fields, number fields, and text fields map directly; picklist values require manual mapping to Salesforce picklist value sets. We present the mapping for customer sign-off before committing to migration.

ConSol*CM field groups on Requests map to custom fields on Salesforce Case. The mapping approach mirrors the Contact field group handling: extract via system documentation, map each field to a typed Salesforce field, and present for customer sign-off. Fields that reference other ConSol*CM objects require lookup resolution to their Salesforce equivalents before Case import.

ConSol*CM knowledge base articles export with content and metadata. The article category hierarchy requires manual mapping to Salesforce Knowledge data categories. We extract article body content, summary, and URL-name fields and import them into Salesforce Knowledge as KnowledgeArticleVersion records. The customer's admin rebuilds the data category structure in Salesforce Knowledge post-migration.

ConSol*CM workflows built in the Process Designer are not API-exportable. We extract the system documentation export to document the workflow logic, including activities, conditions, decision branches, and action sequences. We deliver a written inventory of each workflow with its trigger conditions, step logic, and recommended Salesforce Flow equivalent. The customer's admin or a Salesforce partner rebuilds them post-migration.