Migrate from Oracle Service Cloud (formerly RightNow) to Intercom

Oracle Incidents map to Intercom Conversations. The Incident thread hierarchy (parent incident record with comment children) flattens into a linear message sequence in Intercom, with the first agent reply becoming the initial message in the conversation. Incident status (Open, Pending, Solved, Closed) maps to Intercom's Open, Snoozed, and Closed states. Custom Incident fields migrate to Intercom custom attributes on the conversation. Oracle's incident reference number (Incident.ReferenceNumber) becomes the Intercom conversation ID or a custom attribute for cross-system audit trails.

Oracle Contacts map to Intercom Users. All standard properties (Name, Email, Phone) and custom contact fields migrate to Intercom User attributes. We resolve the contact's Organization relationship during migration and link the User to the corresponding Intercom Company before insert to prevent orphaned contacts. If a Contact in Oracle is not linked to an Organization, we create the User without a Company association but flag it for the customer's admin to review post-migration.

Oracle Organizations map to Intercom Companies. Organization name becomes the Company name, and Organization.Address maps to the Company address fields. Oracle's hierarchical org structure (parent Organization with child Organizations) maps to Intercom's flat Company model; we flatten the hierarchy by associating child contacts with the top-level parent Company and add a custom attribute parent_organization__c to preserve the original hierarchy for reporting.

Oracle Answers (KB articles) map to Intercom Articles. The Answer body (rich text, HTML) migrates directly; Oracle's folder hierarchy maps to Intercom Collections with articles placed into their corresponding collection based on the Answer's category assignment. Answer versioning in Oracle becomes a single latest-version article in Intercom; we capture version history in a custom attribute version_history__c if the customer requires audit traceability. Approval workflow status is noted but not enforced in Intercom since Articles do not have a native approval gate.

Oracle Assets link products and warranties to Contacts and Organizations for entitlement checking. Intercom does not have a native Asset object. For migrations where Asset data is critical for support eligibility, we create a custom Intercom object (using Intercom's custom data extensions on User or Conversation) to store product_name, serial_number, contract_status, and entitlement_end_date linked to the User. If Asset data is not needed for support routing, we export it as a CSV inventory for the customer's admin to maintain separately.

Oracle Tasks map to Intercom Tasks. Task title, due date, assignee (lookup to Contact), and status migrate directly. Oracle Tasks tied to a parent Incident map to a Task attached to the corresponding Intercom Conversation. Standalone Oracle Tasks become standalone Intercom Tasks without a conversation association. Task priority maps from Oracle Priority (1-5) to Intercom Task priority options.

Oracle Custom Objects created in Object Designer may not be fully exposed in the REST API unless the sandbox has been published and deployed. We audit the source API response during discovery to confirm Custom Object visibility. For visible Custom Objects, we map them to Intercom custom attributes on User (if the custom object is contact-scoped) or to a separate Intercom data extension. Custom Objects with lookup relationships to standard Oracle objects require parent-record resolution during migration, and we add them last in the migration sequence after all standard objects are loaded.

Oracle Opportunities (lighter-weight B2C Service variant) do not have a meaningful equivalent in Intercom's support-centric data model. Opportunities represent sales pipeline data rather than service data. We extract Opportunity records as a CSV export for the customer's admin if they are moving to a separate CRM alongside Intercom. No Opportunity records load into Intercom.

Oracle enforces a Contact-Organization relationship where a Contact must be linked to an Organization. Intercom's User-Company association is optional. We enforce a strict migration sequence: Companies (from Organizations) load first, then Users (from Contacts) with their Company association resolved via the Organization reference. This prevents orphaned Users in Intercom and preserves the account context that agents rely on for routing and entitlement checks.

Oracle Incident status transitions follow configurable workflow rules. Intercom conversations have fixed Open, Snoozed, and Closed states without workflow-gating. We document the customer's Oracle workflow rules during discovery and deliver a written recommendation for equivalent routing logic using Intercom Rules and Workflows. No automated status transitions migrate; the customer's admin configures these post-migration in Intercom's workflow builder.