Migrate from SysAid to Salesforce Service Cloud

SysAid Service Records map to Salesforce Case. The Service Record subject becomes Case Subject, and the SysAid status values (Open, Pending, Resolved, Closed) map to Salesforce Status picklist values (New, Working, On Hold, Escalated, Closed). Priority, Urgency, Impact, and assignee fields migrate to their Salesforce Case equivalents. SysAid's category and sub-category levels map to a cascade of custom picklist fields in Salesforce because Salesforce does not have a native multi-level category structure. We resolve the requester to a Salesforce Contact during migration by matching email against the Contact table.

SysAid Service Record attachments (files stored at the service record level, including files from comments and notes) migrate as Salesforce ContentDocument records linked via ContentDocumentLink to the parent Case. We extract file names, MIME types, and binary content during the SysAid API export, then create ContentVersion records in Salesforce followed by ContentDocumentLink records pointing to the target Case. Attachment size limits in Salesforce (25 MB per file via API) are enforced during extraction; files exceeding this threshold are flagged for manual download and re-upload guidance.

SysAid Assets include Configuration Item records, catalog items, and agent-based inventory. We map CI records to Salesforce Asset where the asset represents a customer-facing or product asset with a lifecycle. Catalog items without a customer relationship may map to a custom Configuration Item object if the customer's Service Cloud edition does not include the Asset Management module. We extract asset type, status, assigned users, serial number, and relationship data. Asset-to-Service-Record relationships migrate as CaseAssetRelation records or custom junction objects.

SysAid Users include agents, administrators, and end users. Agents and administrators map to Salesforce User records by email match. End users who only create tickets but do not have agent permissions map to Salesforce Contact records. Role-based permission logic in SysAid does not migrate; we document role-to-profile assignments during discovery and the customer's Salesforce admin rebuilds permission sets and profiles post-migration.

SysAid Companies represent organizational entities that users and assets belong to. We extract company name, contact information, and multi-company segmentation. Companies map to Salesforce Account with the SysAid company domain or name used as the Account Name and as the dedupe key. Account is created before Contact or Case import so that the AccountId lookup is satisfied at the moment of record insert.

SysAid Tasks are sub-items that can be associated with Service Records, Projects, or standalone entities. We map task title, status, assignees, due dates, and parent entity references. Task dependencies in SysAid do not have a Salesforce equivalent and are documented as custom fields or in the rebuild inventory. Tasks linked to Service Records retain the parent Case relationship via WhatId.

SysAid Projects are standalone containers for tasks and milestones. Salesforce has no native project object in Service Cloud base. We design a custom Project__c object during schema pre-creation with fields for project name, status, start date, end date, and assigned users, or we aggregate project-contained tasks directly under a parent Case if the project scope maps to a single customer issue. The customer chooses the strategy during scoping based on whether Projects represent internal work tracking or customer-visible deliverables.

SysAid Knowledge Base articles migrate to Salesforce Knowledge articles. We extract article titles, body content (with formatting preserved where possible), categories, and associations to Service Records. Each SysAid article type maps to a Salesforce Knowledge article type, and the SysAid category hierarchy maps to Salesforce Knowledge data categories. Articles linked to specific Service Records are re-associated in Salesforce using a custom Case-Article junction field or a Case Link custom field on the article.

SysAid supports up to 200 custom fields per entity across Service Record, Asset, Task, Project, CI, User, Company, and Action Item. We pre-create all Salesforce custom fields during the schema design phase before any data import. Field types are mapped: SysAid text fields become Salesforce Text fields, date fields become Date fields, checkbox fields become Checkbox fields, and multi-select options become Multi-Select Picklists. SysAid calculated or formula fields that reference SysAid-specific objects are converted to Salesforce formula fields with equivalent logic or become read-only custom fields requiring manual calculation post-migration.

SysAid Action Items are lightweight checklist or task-type objects. We map title, status, assignees, and parent references to Salesforce Task records. Action Items associated with Service Records link to the target Case via WhatId. Custom triggers on Action Items are not supported for migration and are documented in the automation rebuild inventory.

SysAid preserves note visibility (public vs. internal) as a platform-specific flag. We extract both note types and map public notes to Salesforce Notes linked via ContentDocumentLink to the parent Case. Internal notes map to a custom internal_note__c checkbox field on the Note record and a custom internal-only visibility flag so that the customer can control note access in Salesforce using a custom sharing model. Rich text formatting in SysAid notes migrates as Salesforce rich text.