Migrate from Oracle EBS CRM to HubSpot

Oracle's HZ_PARTIES table stores party records for both organizations and people. Person parties map to HubSpot contacts. We extract party_name, party_number, and party_type from HZ_PARTIES and create one HubSpot contact per person party record, preserving the original Oracle party_id as Source_System_ID__c for traceability.

Organization parties from HZ_PARTIES map directly to HubSpot companies. Organization name, DUNS number (if present), and primary site information populate HubSpot company properties. Oracle's party-level custom attributes migrate as HubSpot company properties if they map to HubSpot's supported data types.

Oracle stores contact roles in HZ_CONTACTS and HZ_ORG_CONTACTS with relationship-type codes. HubSpot uses the primary company association on contacts plus contact properties for role information. We map the Oracle relationship type code to a HubSpot contact property (e.g., contact_role) and set the primary company association by the most-recently-modified link.

Oracle's HZ_LOCATIONS stores address records linked to parties via HZ_PARTY_SITES. Each address record contains street address, city, state, postal code, and country code, which migrate to corresponding HubSpot company address properties. When an Oracle party has multiple locations representing different sites or purposes, we consolidate them into address fields on the same HubSpot company record, storing additional locations in custom multi-line properties for reference.

Oracle's order management tables (OOE_ORDER_HEADERS and OE_ORDER_LINES) contain opportunity-like records with amounts, statuses, and customer references. We map order amount to HubSpot deal amount, order status to HubSpot deal stage, and order creation date to the HubSpot deal create date, creating one HubSpot deal per order header.

Oracle EBS implementations frequently have custom tables built for industry-specific attributes or CRM extensions. These map to HubSpot custom CRM objects (Enterprise tier) or custom properties on standard objects. N:N relationship tables in Oracle become association properties or junction objects in HubSpot's model.

Oracle stores document attachments in FND_ATTACHMENTS linked to entities. We extract the document blob or URL reference, download files, and re-upload them to HubSpot's file storage associated with the relevant contact, company, or deal record. File size limits per HubSpot's 25MB per file apply.

Oracle EBS owner information lives in PER_ALL_PEOPLE_F or custom owner tables with email addresses. We resolve Oracle owners to HubSpot users by matching email. Records for Oracle owners who do not have HubSpot user accounts are flagged before migration; your team creates the HubSpot user or assigns to a fallback owner.

Oracle's activity history encompasses a broad range of interaction records beyond simple logging, including call logs, meeting records, email correspondence, and note attachments that are tied to specific business entities. These activity types map to corresponding HubSpot engagement types, with original timestamps, assigned owners, and related contact or company associations all preserved during the migration process to maintain complete historical context.

Oracle stores customer attributes and extended data points across profile options and custom flexfield structures, including descriptive flexfields and key flexfields with segment columns. These custom attributes map to HubSpot custom contact or company properties based on data type. Date fields, numeric fields, and pick-list values from Oracle undergo type-aware transformation to ensure they match HubSpot property types and value constraints.

Oracle sales territories defined in JTF_TERRITORIES and associated assignment rules determine how records are allocated to sales teams. Territory names and hierarchies become HubSpot team names, while individual assignment rules require manual reconstruction in HubSpot's team-based record assignment configuration to replicate the original Oracle territory logic.

HubSpot's native Createdate and LastModifiedDate fields are automatically set at migration time and reflect when records enter the system. To preserve the original timeline from Oracle, we extract and store the original creation and last modification timestamps as custom datetime properties on each migrated record, ensuring continuity for deal history analysis and contact aging reports.