Migrate from Oracle Service Cloud (formerly RightNow) to Salesforce Service Cloud

Oracle Incidents map to Salesforce Cases. The Incident.Threads array (customer and agent message history) migrates as EmailMessage records linked to the Case, preserving message author, timestamp, and body content. Incident status (Open, Pending, Solved, Closed) maps to Salesforce Case Status values that we configure as a Status field picklist before migration. Custom fields on Incident (Config Object extensions) migrate to Salesforce custom Case fields created during schema pre-creation. Oracle's Incident Priority maps to Salesforce Case Priority (High/Medium/Low) and is preserved.

Oracle Contacts map directly to Salesforce Contacts. The critical constraint is Oracle's known contact auto-deletion behavior: contacts can be silently removed when orphaned from an Organization or when duplicate-merge rules fire unexpectedly. We run a pre-migration contact health check to identify contacts with null or invalid Organization references, flagging these for customer review before migration. Contacts are inserted after Accounts (Organizations) to satisfy the AccountId lookup and prevent orphaned record insertion in Salesforce. Multi-contact roles per organization are noted but map to the Salesforce standard Contact object without a direct roles field; we preserve role information in a custom field contact_role__c.

Oracle Organizations map to Salesforce Accounts. Oracle's hierarchical Organization parent-child structure (Parent_org_id) maps to Salesforce Account hierarchy (ParentId). Organization.Industry, Organization.Size, and custom Organization properties migrate to matching Salesforce Account fields or custom fields. Organization is inserted before Contact to satisfy the AccountId foreign key. The Organization.Name becomes Account.Name, and Organization.External_ID__c becomes an external ID field for dedupe validation.

Oracle Answers (KB articles) migrate to Salesforce Knowledge. Oracle's Knowledge Advance ML ranking and access rules have no Salesforce equivalent; we document these as a written inventory for the customer's admin to rebuild using Salesforce Sharing Sets or Account-based KB visibility rules. The migration runs in two phases: first, article metadata (Title, Summary, Category/Folder) exports from Oracle and imports into the designated Salesforce article type; second, article body HTML migrates as the Salesforce Knowledge Article Body field. Folder hierarchy in Oracle maps to Salesforce Data Category Groups, which require pre-configuration in the destination org. Answer versioning and approval workflows are noted in the written handoff document but do not migrate as workflow automation.

Oracle Assets link products and warranties to Contacts and Organizations, supporting entitlement checking. Assets map to Salesforce Asset records with the ContactId and AccountId lookups resolved from the Oracle source references. Product reference, serial number, and contract status fields migrate to matching Salesforce Asset fields. Asset.Product2Id resolves via Product2 lookup created during the Product migration phase. Entitlement and warranty date fields migrate to Salesforce custom date fields if the destination does not include Salesforce Entitlements (a Service Cloud add-on).

Oracle Tasks tied to Incidents or standing alone migrate to Salesforce Task records. Task.WhatId points to the migrated Case ID; Task.OwnerId resolves via the Owner mapping (email-to-User lookup). Due dates, status, priority, and assignee migrate directly. Oracle Task types (Internal, Customer Follow-up) map to Salesforce Task.Status and Task.Priority values that we configure before migration.

Oracle Custom Objects defined in Object Designer migrate to Salesforce Custom Objects with __c API names. Custom Objects are not always exposed in Oracle's REST API unless the sandbox is published; we use the Oracle CX Service Connector or database-level export when REST API coverage is incomplete. Pre-migration, we create the equivalent Salesforce custom object schema including all custom fields, lookup relationships, and validation rules via Salesforce Metadata API. Custom Objects with parent lookups to standard objects (Incident, Contact, Organization) are migrated last to ensure parent record IDs are available for foreign key resolution.

Oracle Opportunities (lighter than Oracle Sales Cloud) map to Salesforce Opportunity with standard fields (Name, Amount, CloseDate, StageName, OwnerId) migrating directly. Oracle Opportunity.ProductLine items map to Salesforce OpportunityLineItem via Pricebook2 and Product2 resolution. If the destination org uses Opportunity Team or custom forecast fields, we map these during the schema design phase. Stage mapping uses a configuration mapping table between Oracle Opportunity.Status and Salesforce Opportunity.StageName values.

Oracle chat transcripts are stored as part of the Incident thread history. Chat messages migrate as EmailMessage records linked to the parent Case, with the Chat channel identifier preserved in a custom EmailMessage field. Oracle's chat session metadata (wait time, handle time, agent name) maps to custom fields on the EmailMessage record for reporting continuity.

Oracle CX Survey responses have no direct Salesforce Service Cloud standard equivalent. We migrate survey response records to a Salesforce custom object Survey_Response__c linked to the parent Contact and Case, preserving score, response text, and submission timestamp. The customer's admin rebuilds survey logic using Salesforce Surveys, Qualtrics integration, or a third-party survey tool post-migration.