Migrate from Oracle CRM On Demand to Microsoft Dynamics 365 Sales

Oracle Accounts map directly to Dynamics 365 Accounts. Oracle account name, address records (primary and alternate), industry, and ownership fields translate cleanly. Dynamics 365 supports multi-level parent-account hierarchy; any Oracle accounts with a parent relationship map to the Parent AccountId field, and any flat Oracle accounts are imported as top-level Accounts without a parent. We create Accounts first in the migration sequence so that Contact and Opportunity imports can resolve the AccountId lookup immediately.

Oracle Contacts map directly to Dynamics 365 Contacts. The Contact-to-Account link is required in Dynamics 365; we resolve this by matching the Oracle Contact's Account reference to the imported Account record's Dynamics 365 ID. If a Contact in Oracle has no Account reference, we assign it to a default organizational Account created at the start of migration or to the customer's specified default, and we flag these records in the reconciliation report. Email address is used as the deduplication key during import.

Oracle Opportunities map to Dynamics 365 Opportunities with stage, amount, probability, and close date preserved. Dynamics 365 requires Opportunity.AccountId to be set on every Opportunity record; Oracle does not enforce this link. We resolve AccountId during the transform layer by matching the Oracle Opportunity's Account reference to the imported Dynamics 365 Account, or we create a placeholder organizational Account for any Oracle Opportunity without an Account reference. The Oracle Opportunity Close Date maps directly to Dynamics 365 EstimatedCloseDate.

Oracle Leads map to Dynamics 365 Leads. If the source tenant is on the Enterprise Lead Referral tier, lead record history beyond creation events (status changes, lead scoring, conversion events) may not be accessible via the Oracle API. We flag this limitation during discovery and scope any accessible lead fields (Lead_Status, Lead_Source, custom lead fields) into the mapping. Dynamics 365 Lead Status values are configured to match the Oracle lead status vocabulary as closely as possible during schema setup.

Oracle's unified Activities object (containing Tasks, Calls, and Appointments) splits into Dynamics 365's separate Task and Event objects. Oracle Tasks map to Task records with Status, Priority, and ActivityDate preserved. Oracle Call activities map to Task with TaskSubtype = Call and CallDisposition in a custom field. Oracle Appointments map to Event records with StartDateTime, EndDateTime, and Location preserved. Activity volumes can be large; we scope the last 12-24 months of activities as the primary migration window and flag older records for archival handling during discovery.

Oracle custom object schema is tenant-specific and must be reverse-engineered from the source API before mapping. We extract the custom object definition (field names, data types, picklist values, lookup relationships) during the discovery phase and pre-create the corresponding custom entities in Dynamics 365 before any data loads. Any lookup fields in Oracle custom objects that reference standard objects (Account, Contact, Opportunity) are resolved to the Dynamics 365 IDs of the imported parent records.

Oracle attachments associated with records can be exported in bulk, but Microsoft Dynamics 365 Sales stores file attachments differently depending on configuration. We evaluate whether to use Dynamics 365 native notes with file attachments or SharePoint document libraries for the migrated files. Attachment volumes and file sizes are scoped separately from record migration. We handle both URL-based attachments (referencing external storage) and blob-stored attachments with separate storage estimation during discovery.

Oracle Workflow Rules do not migrate as code. Oracle's Migration Tool can transfer Workflow Rules only between tenants on the same release version, and there is no equivalent native workflow engine in Dynamics 365. We extract every active Oracle Workflow Rule via the API, document its trigger (object, event, condition), all actions (field updates, assignments, notifications, outbound messages), and any time-based delays. This written inventory is delivered to the customer's admin team as the rebuild specification for Power Automate or Dynamics 365 workflows.

Oracle Named Users map to Dynamics 365 User records by email address. We extract every distinct Oracle Owner referenced on Account, Contact, Opportunity, and Activity records and match by email against the destination Dynamics 365 User table. Any Oracle Owner without a matching Dynamics 365 User goes to a reconciliation queue, and the customer's admin provisions the missing User before record migration resumes. OwnerId references on Opportunities and Activities cannot be resolved until all Users are provisioned.