Migrate from Xurrent to Salesforce Service Cloud

Xurrent Requests map directly to Salesforce Cases. The request subject becomes Case Subject, description becomes Description, status maps to a Salesforce Case Status picklist that we configure to match Xurrent's status lifecycle (New, In Progress, Pending Customer, Resolved, Closed). Priority maps to Case Priority. The Service scoping decision is critical: we propose mapping each Xurrent Service to either a Salesforce Product with associated Entitlement or to an Account scope depending on whether the customer uses account-level or product-level SLA tracking.

Xurrent Services define the service catalog and record scoping boundary. We map Services to Salesforce Product2 records (for product-level support scopes) or to a custom Service__c object (for account-level scopes). Parent-child service hierarchy migrates as Product hierarchy or as self-referencing lookup on the custom object. Services with no direct Product equivalent become Salesforce Account-based service scopes with Entitlement linked to the Account.

Xurrent IMR Incidents map to Salesforce Cases with a custom field imr_incident_id__c to preserve the original incident identifier. Linked responders, on-call schedule references, and timeline events migrate as Case Comments, Tasks, and a custom Event timeline. Slack and Teams responder integrations do not transfer; the notification channel configuration is documented for rebuild in Salesforce Flow or Omni-Channel.

Xurrent Changes carry risk assessment, approval chains, and implementation plans. Salesforce Service Cloud does not include a native Change Request object in the standard license; organizations requiring formal change management use the Salesforce Change Management managed package or map Changes to a custom Change_Request__c object with approval workflow rebuilt in Flow. Approval chain logic does not migrate as workflow rules; we document the approval hierarchy for the admin to configure post-migration.

Xurrent Problems store root cause analysis and link to related Incidents. We map Problems to a custom Problem__c object with a junction object Problem_Incident_Link__c preserving the many-to-many relationship graph. If the customer prefers a simpler model, Problems map to a Case with a custom field problem_type__c and the related Incidents linked via Lookups. We preserve any attached Knowledge Articles as Salesforce Knowledge articles linked to the Problem record.

Xurrent Knowledge Articles migrate to Salesforce Knowledge with Article Type matching the source category structure. Article visibility tied to Xurrent Services maps to Salesforce Data Category Groups that control which channels (Customer Portal, Community, internal) can access each article. Large article bodies with structured content require reformatting for Salesforce Knowledge's rich text and Lightning knowledge component constraints.

Xurrent SLA Policies define response and resolution times tied to priority and Service. We map these to Salesforce Entitlelements (tied to Account or Product) and Entitlement Processes with Milestones. The policy definitions are exported as structured documentation; the actual milestone trigger and breach logic is configured in Salesforce by the admin post-migration using the Entitlement Process builder.

Xurrent Escalation Policies define multi-step notification sequences (who is notified, via which channel, after how long). These are structured configuration records that do not transfer as Salesforce workflow rules. We export the full escalation chain as a written policy document including step order, time triggers, notification channels, and assignee rules, so the customer's admin can rebuild using Salesforce Flow's time-based triggers and Action elements.

Xurrent Playbooks automate incident response steps and link to Knowledge Articles. Playbook step definitions and conditional logic are configuration records. We export the playbook structure as a reference document listing each step, its trigger conditions, the response actions, and any linked Knowledge Articles. The customer rebuilds the logic as Salesforce Flow record-triggered or Platform Event-driven flows post-migration.

Xurrent On-Call Schedules define rotation order and coverage windows. We export schedule configurations and rotation sequences as a custom On_Call_Schedule__c object with rotation detail records. The calendar-layer scheduling logic maps against Salesforce Events or a custom scheduling object. If the customer licenses Field Service Management, the Shift object provides a native scheduling model for on-call coverage.

Xurrent custom fields on Requests, Services, Incidents, and Problems migrate as Salesforce custom fields with type-mapped equivalents (dropdown to picklist, checkbox to checkbox, date to date, etc.). Multi-select fields map to Salesforce multi-select picklists. Custom field validation rules in Xurrent are documented for recreation as Salesforce validation rules post-migration. We run type compatibility checks during schema design to flag any unsupported field types before import.

File attachments on Requests, Incidents, Problems, and Knowledge Articles migrate as Salesforce Files (ContentDocument/ContentVersion) linked via ContentDocumentLink to the parent record. Large attachment volume requires chunked migration with batch size limits applied. We preserve the original file name and MIME type in ContentVersion metadata. Attachments exceeding Salesforce's 25 MB per file limit require the customer to decide between splitting the file or storing a link in Salesforce to the external storage location.