Migrate from Serviceaide Intelligent Service Management to Salesforce Service Cloud

Discovery and ISM tenant scoping

We audit the Serviceaide ISM tenant across all modules in scope: CCTI ticket counts and custom fields, CI records with approval phase data, Knowledge Manager articles with metadata, Asset Center inventory, Service Catalog entries with SLA bindings, Change Manager records with risk scores, and user/agent accounts. For MSP or BPO environments with multi-tenancy, we identify each tenant's organization ID and scope each as a separate migration project. We also capture ISM SLA configuration (escalation thresholds, breach timers, group assignments) and workflow rule definitions for the written inventory deliverable. Discovery output is a written migration scope document with record counts, object inventory, and a schema gap analysis.

Sandbox staging environment and Salesforce schema setup

We create a Salesforce Sandbox (Full Copy or Partial Copy depending on data volume) and configure the destination schema: Case Record Types (IT Service, Customer Support, Change), custom fields matching ISM custom ticket fields, Entitlement and Milestone records for SLA reconstruction, Knowledge Article data categories, and Asset and Configuration Record objects. We validate that Salesforce field-level security and validation rules will not block the import before any extraction begins. The ISM CI Approval Phase character validation rule is deployed as a pre-flight transform script in the staging environment.

ISM data extraction with CI character validation and SLA artifact tracking

We extract data from Serviceaide ISM using per-object queries against the reporting layer, applying explicit tenant scoping per organization ID. CCTI extraction includes the full ticket history, custom field values, and SLA timestamps. CI records are extracted with approval phase data fed through the ISM-13238 character validation script to strip non-ASCII characters before staging. SLA-driven group reassignments (ISM-13232) are tracked as a separate artifact by querying the ISM SLA configuration and CCTI history, not from webhook events. Knowledge article extraction includes the approver metadata header block. Each extraction batch is reconciled against ISM record counts before staging proceeds.

Sandbox migration dry run and reconciliation

We run a full migration into the Salesforce Sandbox to validate the extraction and transformation logic before production. The customer's service desk lead reconciles record counts across all object types, spot-checks 25-50 records against ISM source data, validates SLA milestone reconstruction against ISM SLA timestamps, and confirms Knowledge Article attachments are correctly linked. ISM-13238 character validation and ISM-13232 SLA group reassignment reconstruction are both tested in the sandbox run. All mapping corrections happen in sandbox before any production data moves.

User provisioning and ownership resolution

We extract every distinct ISM user and agent referenced on CCTIs, CIs, Change records, and Knowledge Articles and match by email against the Salesforce destination org's User table. ISM agents become Salesforce Users with the appropriate Service Cloud profile; ISM end-users without Salesforce User records become Salesforce Contacts on the relevant Account. Any ISM owner without a matching Salesforce User goes to a reconciliation queue for the customer's admin to provision before record import resumes. This step gates the production migration because OwnerId is required on most Case and Asset records.

Production migration in dependency order

We run production migration in record-dependency order: Salesforce Users and Contacts first (validated against the ownership queue), Accounts (from ISM Organizations with per-tenant scoping), Assets, Configuration Records (with CI approval phase character validation applied), Entitlements and Milestones (for SLA reconstruction), Knowledge Articles (with approver metadata header block), Cases (with Entitlement lookup resolved and SLA milestone timers calculated from ISM timestamps), Change Cases (with risk score and approval metadata), and Attachments (ContentDocument via chunked upload). SLA-induced group reassignments are applied as Salesforce Case Team assignments post-Case insert using the ISM-13232 artifact. Each phase emits a row-count reconciliation report before the next phase begins.

Cutover, validation, and workflow rebuild handoff

We freeze ISM writes during cutover, run a final delta migration of any records modified during the migration window, then enable Salesforce Service Cloud as the system of record. We validate SLA milestone breach counts against ISM SLA reporting as a final check. We deliver the written workflow and SLA automation inventory document to the customer's admin team, covering ISM workflow rules, SLA escalation triggers, and Luma AI knowledge deflection configurations. We support a one-week hypercare window where we resolve reconciliation issues raised by the service desk team. We do not rebuild ISM workflows as Salesforce Flow inside the migration scope; that is a separate engagement or an internal Salesforce admin task.