Migrate from Oracle EBS CRM to Microsoft Dynamics 365 Sales

Discovery and database connection scoping

We audit the source Oracle EBS environment to identify the CRM-relevant schemas (ARHZTA_RZ, CZ, HZ_PARTIES, FZ_NOTES, AS_TERRITORIES, and any custom object tables), the installed EBS CRM module version, and the active EBS version number. We validate direct database connectivity from our migration infrastructure to the EBS Oracle server, confirm the read-only credential requirements with the customer's Oracle DBA, and enumerate the distinct EBS org contexts (multi-org installations may have multiple sets of the same tables per org_id). We also extract FND_USER and FND_RESPONSIBILITY to get an accurate CRM user count and responsibility matrix. The discovery output is a written migration scope document covering schema inventory, data volume estimates, and a risk assessment for the APPS schema coupling.

Data quality assessment and cleansing

Legacy EBS data frequently contains duplicates, inactive records, and orphaned relationships (particularly in multi-org setups where the same account may appear in multiple org contexts). We run a data quality assessment against the extracted CRM records, flagging duplicate Account records by account_number, inactive Contacts without email addresses, and Opportunities with missing parent Account references. We deliver a cleansing report to the customer's CRM admin and agree on exclusion criteria before migration begins. Skipping this step is the most common cause of Dynamics 365 post-migration data cleanup projects.

Destination schema provisioning in Microsoft Dynamics 365 Sales

We pre-create any custom Dataverse tables required for EBS custom objects, including all columns, lookup relationships, and alternate keys that map to the source EBS table primary keys. We configure Sales Processes in Microsoft Dynamics 365 Sales that match the EBS Opportunity stage names and probability percentages. Territory structures extracted from AS_TERRITORIES are documented for post-migration rebuild. We deploy the destination schema into a Dynamics 365 Sandbox environment first for validation, then into the production org after customer sign-off. Oracle Workflow definitions are inventoried and documented for separate rebuild in Power Automate; they do not deploy into Dynamics as part of the migration.

Owner reconciliation and User provisioning

We extract every distinct EBS user referenced on Account, Contact, Opportunity, and Activity records and match by email against the Microsoft Dynamics 365 Sales User table. Users without a matching Dynamics User are held in a reconciliation queue. The customer's Dynamics admin provisions any missing Users (active or inactive depending on whether the original EBS user is still active in the organization). Migration cannot proceed past this step because OwnerId references on Account, Contact, and Opportunity are required fields in Microsoft Dynamics 365 Sales .

Production migration in dependency order

We run production migration in record-dependency order: Accounts (from EBS RA_CUSTOMERS base tables), Contacts (with AccountId resolved via party_id mapping), Opportunities (with AccountId, OwnerId, and stage resolved from the CZ schema), Custom Objects (with their parent lookups resolved to Account or Contact), Attachments (BASE64-encoded and linked via annotation records), Activities and Tasks (mapped from Interaction Center or Teleservice tables to Dynamics Activity types), and Notes (from FZ_NOTES). Each phase emits a row-count reconciliation report before the next phase begins. We use the Dynamics Dataverse Bulk API 2.0 with batch chunking and exponential backoff for large record volumes.

Cutover, validation, and Workflow rebuild handoff

We freeze EBS writes during the cutover window, run a final delta migration of any records modified during the migration process, then enable Microsoft Dynamics 365 Sales as the system of record. We deliver the Oracle Workflow inventory document and the Territory mapping document to the customer's admin team, who rebuilds these in Power Automate and Dynamics native Territory Management respectively. We support a one-week hypercare window where we resolve any reconciliation issues raised by the customer's sales team. We do not rebuild Oracle Workflows as Power Automate flows or Dynamics workflows inside the migration scope; that is a separate engagement.