Migrate from OASYS to Salesforce Service Cloud

OASYS Tickets map directly to Salesforce Cases. The ticket subject or title maps to Case Subject; ticket description maps to Case Description; status and priority map to Case Status and Priority respectively. OASYS conversation threads migrate as EmailMessage records linked to the Case via the Case Number reference. We flag tickets missing a Subject value (OASYS allows empty subject) and default to a constructed subject using the ticket ID and creation date before inserting into Salesforce.

OASYS Customer records map to Salesforce Contacts. We use the customer email address as the dedupe key and map name fields (first, last, full name) to Contact FirstName, LastName, and Email. Phone, company association, and lifecycle data migrate to Contact Phone, AccountId (resolved via the Company mapping), and custom fields respectively. Customers without a company association in OASYS require a decision on whether to link to an existing Account or create a placeholder.

OASYS Company records map to Salesforce Account. The company name maps to Account Name; company domain maps to Account Website. If OASYS Company records include a parent-child hierarchy, we map it to Salesforce Account Hierarchy (Parent AccountId lookup). Account is created before Contact import so that AccountId is available as a required or optional lookup on Contact insert.

OASYS Agent records map to Salesforce User objects. We match by email address. Any OASYS Agent without a matching Salesforce User record is held in a reconciliation queue for the customer's admin to provision before the agent assignment data (Case OwnerId) is written. We preserve inactive agents to maintain historical assignment accuracy using an Active = false Salesforce User if the customer's admin provisions one for historical purposes.

OASYS team structures and queue assignments do not export as structured data. We audit team rosters during discovery and map each OASYS team to a Salesforce Queue (for Case routing) and a Salesforce Group (for reporting). The customer's admin recreates queue membership and routing rules in Salesforce Setup after migration. We provide a Team-to-Queue mapping spreadsheet as part of the migration deliverables.

OASYS custom fields on Tickets, Customers, and Companies map to Salesforce custom fields (__c API name) on the equivalent objects. We audit field types during discovery and flag any OASYS field types that have no Salesforce equivalent (e.g., rich text with conditional display logic, multi-currency numeric fields). These fields must be created in Salesforce before migration data is loaded, or values are stored as Text custom fields. Field-level security is set to Read/Write for the migration user during load.

OASYS conversation thread entries (customer replies and agent responses) migrate as Salesforce EmailMessage records linked to the parent Case. Each EmailMessage stores the from/to/cc addresses, subject, body (HTML or plain text), and timestamp. We preserve thread chronology by ordering EmailMessage insertion by the original OASYS timestamp. Internal notes from OASYS migrate as Salesforce Notes or as private Case Comments depending on whether the destination org uses the Case Comment object.

File attachments on OASYS tickets and conversations are downloaded from the source and uploaded to Salesforce as ContentDocument records linked via ContentDocumentLink to the parent Case. We validate each file against Salesforce's 25 MB per file upload limit and flag files exceeding this threshold before migration day so the customer can compress, re-upload manually post-migration, or exclude. Unsupported file types (e.g., certain executable formats) are flagged and excluded.

OASYS tags on tickets and customers migrate to Salesforce. During scoping the customer chooses between storing tags as a Multi-Select Picklist field on Case (simpler, native) or as Salesforce Topics with TopicAssignment records (better for reporting and discovery). Tag taxonomy reorganization may be needed post-migration if OASYS used a flat tag list that conflicts with Salesforce's naming conventions.

OASYS SLA definitions use internal naming conventions and condition logic that does not export as structured data. We photograph and document every SLA rule during the audit phase (trigger conditions, time targets, escalation actions). Post-migration, we provide a written configuration guide mapping each OASYS SLA to a Salesforce Entitlement Process and Milestone definition so the customer's admin can rebuild them in Salesforce Setup. SLA rules are not migrated as code.

OASYS ticket status values (e.g., Open, Pending, Resolved, Closed) map to Salesforce Case Status values on a Case Record Type. We use the OASYS status values as the Label and map them to a Status field picklist that the customer configures in Salesforce Setup. If OASYS uses custom status values not available in the default Case Status picklist, we add them as new Status values before migration.

OASYS ticket Priority values map directly to Salesforce Case Priority (High, Medium, Low). The mapping is 1:1 with no transformation required. We verify that the Case Priority picklist in the destination Salesforce org includes all OASYS priority values during the schema pre-creation phase.