CRM migration
Field-level mapping, validation, and rollback between Oracle EBS CRM and Zoho CRM. We move data and schema; workflows are rebuilt natively in Zoho CRM.
Oracle EBS CRM
Source
Zoho CRM
Destination
Compatibility
9 of 10
objects map 1:1 between Oracle EBS CRM and Zoho CRM.
Complexity
BStandard
Timeline
4-8 weeks
Overview
Migrating from Oracle EBS CRM to Zoho CRM is a database-to-API project rather than a standard API-to-API migration. Oracle E-Business Suite does not expose a REST API for CRM objects — we connect directly to the Oracle database with read-only credentials scoped to the CRM-relevant base schemas, enumerate the target tables at discovery, and export records in parent-before-child order to preserve referential integrity across the tightly joined APPS schema. Zoho CRM receives the data via its Bulk API and standard import wizard, with custom objects created as Zoho modules before data insertion. We flag Oracle Workflows, Territory routing rules stored in AS_TERRITORIES, and per-module user counts from FND_RESPONSIBILITY for admin-level rebuild or redesign in Zoho. Workflows, automations, and Oracle Forms do not migrate as code — we deliver a written inventory for the customer's admin to rebuild in Zoho Blueprint and workflow rules.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a Oracle EBS CRM object lands in Zoho CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
Oracle EBS CRM
Account (AR_CUSTOMERS / RA_CUSTOMERS)
Zoho CRM
Accounts module
1:1Oracle EBS Accounts are stored in AR_CUSTOMERS and exposed through the APPS schema RA_CUSTOMERS_V view. We map the customer number, account name, primary site address, and status fields directly to Zoho CRM Account fields. Account is the parent record — we extract and insert Accounts first so that the Zoho Account ID is available as a lookup reference when Contacts and Opportunities are inserted.
Oracle EBS CRM
Contact (PER_ALL_ASSIGNMENTS_F / HZ_PARTIES)
Zoho CRM
Contacts module
1:1Contacts reside in HZ_PARTIES (person type) and HZ_CONTACT_POINTS with employee contacts sourced from PER_ALL_ASSIGNMENTS_F. We map the party ID, name fields, email, phone, and the FK reference to the parent AR_CUSTOMER account. The relationship between Contact and Account is resolved by matching the EBS party_id to the Zoho Account lookup.
Oracle EBS CRM
Opportunity (CZ tables)
Zoho CRM
Deals module
1:1Opportunities in Oracle EBS are stored in the CZ (Collaborative Selling) schema or deprecated ASF schema depending on the CRM module version deployed. We identify the correct schema at discovery, extract stage, amount, probability, expected close date, and owner. Stage values map to Zoho Deal StageName, and the EBS owner email resolves to a Zoho User record via the FND_USER mapping.
Oracle EBS CRM
Territory (AS_TERRITORIES)
Zoho CRM
Zoho CRM Territory or custom module
lossyTerritory definitions in EBS CRM are stored in AS_TERRITORIES with hierarchical org structure references. There is no direct Zoho CRM Territory equivalent — territories do not migrate as code. We extract the full territory hierarchy, assignment rules, and salesrep-to-territory mappings in a structured report and hand it to the customer's Zoho admin to rebuild using Zoho's custom modules and assignment rules.
Oracle EBS CRM
Sales Activities / Tasks (Interaction Center / Teleservice tables)
Zoho CRM
Activities module
1:1Activities and tasks are stored across multiple EBS CRM schemas — the deprecated Teleservice tables or the modern Interaction Center tables — depending on which CRM module is installed. We identify the active schema at discovery, extract task type, subject, status, due date, and owner, and insert them into Zoho Activities in dependency order after the parent Contact or Deal record exists in Zoho.
Oracle EBS CRM
Notes / History (FZ_NOTES)
Zoho CRM
Notes
1:1Notes and audit history in Oracle EBS CRM are stored in generic note tables (FZ_NOTES or equivalent) or in the application-level audit trail. We extract them as text with timestamps and owner reference and insert them into Zoho CRM Notes linked to the parent Account, Contact, or Deal record via ContentDocumentLink.
Oracle EBS CRM
Custom Objects (user-defined tables)
Zoho CRM
Custom Modules
1:1Custom objects in EBS CRM are stored in user-defined tables within base product schemas. They frequently reference FK columns pointing to core tables like RA_CUSTOMERS or OE_HEADERS. We extract the DDL for each custom table at discovery, pre-create matching custom modules in Zoho CRM (with fields typed to Zoho's supported types), then insert records in parent-resolved order so that lookups are satisfied at insert time. Zoho's 300-field and 5-lookup-field limits per module are validated against the custom table column count before migration begins.
Oracle EBS CRM
Attachments (BFILE / CLOB in database)
Zoho CRM
Attachments
1:1Attachments in Oracle EBS CRM are stored as LOB data in the database (BFILE or CLOB columns) or on the file system depending on the attachment configuration. We extract binary attachments as BASE64-encoded blobs and insert them into Zoho CRM as file attachments linked to the parent record. Zoho's file size limit per attachment and total migration size cap of 25 GB are validated against the EBS attachment volume during scoping.
Oracle EBS CRM
User / Employee (FND_USER + FND_RESPONSIBILITY)
Zoho CRM
Users
1:1Users in EBS CRM are employees sourced from PER_ALL_ASSIGNMENTS_F with CRM-specific responsibilities assigned via FND_RESPONSIBILITIES. We extract FND_USER (username, email, start_date, end_date) and FND_RESPONSIBILITY (responsibility_name, application_id) to build a user matrix. The customer's Zoho admin provisions matching User accounts before production migration — we resolve by email match during record import.
Oracle EBS CRM
Oracle Workflows (WF_ tables)
Zoho CRM
Workflows (rebuild required)
1:1Oracle Workflows stored in WF_ tables and implemented via PL/SQL packages encode routing, approval, and notification logic specific to EBS. These definitions cannot be exported as structured data and have no equivalent construct in Zoho CRM. We document every active Workflow at discovery — trigger event, routing conditions, approver assignments — in a structured report for the customer's admin to rebuild using Zoho Blueprint and workflow rules.
| Oracle EBS CRM | Zoho CRM | Compatibility | |
|---|---|---|---|
| Account (AR_CUSTOMERS / RA_CUSTOMERS) | Accounts module1:1 | Fully supported | |
| Contact (PER_ALL_ASSIGNMENTS_F / HZ_PARTIES) | Contacts module1:1 | Fully supported | |
| Opportunity (CZ tables) | Deals module1:1 | Fully supported | |
| Territory (AS_TERRITORIES) | Zoho CRM Territory or custom modulelossy | Fully supported | |
| Sales Activities / Tasks (Interaction Center / Teleservice tables) | Activities module1:1 | Fully supported | |
| Notes / History (FZ_NOTES) | Notes1:1 | Fully supported | |
| Custom Objects (user-defined tables) | Custom Modules1:1 | Mapping required | |
| Attachments (BFILE / CLOB in database) | Attachments1:1 | Mapping required | |
| User / Employee (FND_USER + FND_RESPONSIBILITY) | Users1:1 | Mapping required | |
| Oracle Workflows (WF_ tables) | Workflows (rebuild required)1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
Oracle EBS CRM gotchas
No native REST API for EBS CRM data extraction
APPS schema coupling spans CRM, ERP, and HR in one database
Premier Support for EBS 12.1 ended — Extended Support for 12.2 has a cost cliff
Oracle Workflow engine has no direct migration path to cloud CRM automation
Per-module licensing creates billing ambiguity at destination
Zoho CRM gotchas
API access requires Professional tier or above
Subform fields do not export cleanly via CSV
API credit consumption is non-linear
Export download links expire in 7 days
Owner (User) assignments require pre-mapped user IDs
Pair-specific challenges
Migration approach
Database access provisioning and discovery
We work with the customer's DBA to provision read-only Oracle database credentials scoped to the CRM-relevant base schemas (AR, CZ, AS, HZ, FND, PER). We run discovery queries to enumerate the target tables, identify the active CRM module version (Collaborative Selling vs. Teleservice), enumerate custom table DDL, and count records across all CRM objects. We also extract FND_USER, FND_RESPONSIBILITY, and AS_TERRITORIES at this stage. The discovery output is a written schema map and record count summary used to build the migration scope.
Custom object schema design in Zoho CRM
We pre-create custom modules in Zoho CRM to match the EBS custom table DDL before any data extraction begins. For each custom table, we map column types to Zoho field types, create lookup fields to parent Account or Contact modules, and validate against Zoho's 300-field and 5-lookup-field limits. If limits are exceeded, we agree on a split strategy with the customer before proceeding. Schema is built in a Zoho sandbox or the production org (customer choice) and validated before the production migration window opens.
User provisioning reconciliation
We extract FND_USER and FND_RESPONSIBILITY to build a user matrix mapping EBS usernames and responsibility assignments to Zoho User records. The customer's Zoho admin provisions matching User accounts (active or inactive based on whether the EBS user is current). Owners without a matching Zoho User go to a reconciliation queue. Migration cannot proceed past record import until the Owner resolution is complete because OwnerId is a required field on most Zoho CRM records.
Sandbox migration and reconciliation
We run a full migration into a Zoho Sandbox or a parallel Zoho CRM org using production-like data volume. The customer's CRM lead reconciles record counts (Accounts in, Contacts in, Deals in, Activities in, custom module records in), spot-checks 25-50 random records against the EBS source, and validates the territory and custom object data. Any mapping corrections are made here before the production migration begins.
Production migration in dependency order
We run production migration in strict record-dependency order: Users (manually provisioned and validated), Accounts (parent records first), Contacts (with Account lookup resolved), Deals (with Account and Owner lookups resolved), Activities (after parent Contact and Deal exist), custom module records (with parent lookups resolved), Notes, Attachments, and Territory inventory. Each phase emits a row-count reconciliation report before the next phase begins. We use Zoho's Bulk API and import wizard for standard modules, with API-based inserts for custom objects with complex lookup dependencies.
Cutover, validation, and Workflow rebuild handoff
We freeze EBS CRM writes during cutover, run a final delta migration of any records modified during the migration window, then enable Zoho CRM as the system of record. We deliver the Oracle Workflow inventory document and the Territory hierarchy report to the customer's admin team. We support a one-week hypercare window to resolve reconciliation issues. We do not rebuild Oracle Workflows or Territory routing rules inside the migration scope — those are documented for the customer's admin to rebuild using Zoho Blueprint and workflow rules as a separate post-migration task.
Platform deep dives
Oracle EBS CRM
Source
Strengths
Weaknesses
Zoho CRM
Destination
Strengths
Weaknesses
Complexity grading
Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across Oracle EBS CRM and Zoho CRM.
Object compatibility
1 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
Oracle EBS CRM: Not applicable — direct database query, throttling depends on customer's DB server capacity and concurrent workload.
Data volume sensitivity
Oracle EBS CRM doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during Oracle EBS CRM to Zoho CRM migration scoping. Not seeing yours? Book a call.
Walk through your Oracle EBS CRM to Zoho CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave Oracle EBS CRM
Other ways to arrive at Zoho CRM
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.