Migrate from Oracle Project Management Cloud to Jira

Oracle Projects (the root entity in Fusion PM, carrying ProjectNumber, ProjectName, ProjectType, and status) map directly to Jira projects. Every child object in Oracle carries a Project identifier as a foreign key, so Projects migrate first to establish the parent reference. We use ProjectNumber or a customer-assigned identifier as the Jira project key prefix to preserve traceability between systems.

Oracle's task hierarchy (Work Breakdown Structure with parent-child WBS relationships via ProjectTasks endpoint /fscmRestApi/resources/{version}/projects/{projectId}/child/ProjectTasks) maps to Jira's epic-story-task structure. Parent Oracle tasks become Jira Epics or Stories depending on whether they carry child tasks; leaf-level Oracle tasks become Jira Stories or Subtasks. We preserve WBS numbering as a custom field (wbs_code__c) so the original WBS path remains visible in Jira.

Oracle Project Resources (linking persons or equipment to Tasks with allocation percentages, assignment dates, and roles) map to Jira by resolving each Oracle resource person to a Jira User by email or employee ID. Allocation percentage and assignment dates migrate as Jira worklog entries (started, time spent) with the allocation percentage noted in a custom field resource_allocation_pct__c. Oracle role assignments map to Jira project role names (Developers, Project Managers, Stakeholders). Note that Oracle's capacity planning and leveling features have no native Jira equivalent; these require manual rebuild or a capacity planning app from the Atlassian Marketplace.

Oracle Task Followers (subscription-style notifications on specific tasks via /child/TaskFollowers) map to Jira Watchers on the equivalent issue. We extract the follower email list for each Oracle task and add those users as Jira watchers on the corresponding migrated issue. Note that Jira watchers are additive and cannot be selectively removed if the destination project already has watchers configured.

Oracle Expenditure Batches (cost transactions imported from subledgers and third-party systems) have no native Jira equivalent. We extract batch-level cost data (total amount, cost type, expenditure category, period) and store it in Jira custom fields on the equivalent project or issue record. Individual expenditure line items with vendor, cost code, and GL account details require a custom issue-level field set or a supplemental cost tracking integration (Confluence page, third-party app) if the customer requires granular cost visibility post-migration.

Oracle Project Budgets (versioned financial plans with baseline and forecast variants stored in a planning cube) do not have a Jira equivalent. We extract budget headers (total budget amount, version, currency, baseline vs forecast flag) and map them to Jira project-level custom fields (budget_amount__c, budget_version__c, budget_type__c). If the customer requires multi-period budget tracking against actuals, we document the gap and recommend a Jira-compatible financial reporting integration or a supplemental spreadsheet maintained alongside Jira.

Oracle Project Contracts (defining billing terms, milestones, and revenue recognition rules) have no Jira equivalent. Contract header fields (contract number, customer, contract value, billing schedule) migrate to Jira project-level or epic-level custom fields (contract_number__c, contract_value__c, billing_terms__c). Milestone data migrates to Jira issues with a milestone flag custom field (is_milestone__c) and due dates set to the Oracle milestone dates. Complex billing schedules and revenue recognition rules cannot be reproduced in Jira and require manual reference to Oracle or a contract management tool.

Oracle Project Billings (AR invoices linked to Projects with invoiced amounts against contracts) have no native Jira equivalent. We extract billing header data (invoice number, invoice date, amount, status) and store it in Jira custom fields on the equivalent project or as a dedicated set of billing-issues with a custom field mapping (invoice_number__c, invoice_date__c, invoice_amount__c). Line-level invoice details migrate separately as attachments or as a custom issue field set. Post-migration billing tracking requires the customer's finance team to reference Oracle or a replacement billing system.

Oracle extends standard objects with Descriptive Flexfields (DFFs), which store key-value segments as setup data. We extract DFF values during export and map them to Jira custom fields of the equivalent type (text, number, date, select). Jira field configuration schemes must be created per project before data import; we pre-create the schema in the destination Jira site before loading any record data. DFF segments that represent lookup values require corresponding Jira custom field options pre-populated.

Oracle attachments stored in Oracle Content and Experience (OCEC) or as FBL entries are downloaded to a local staging location and re-uploaded to Jira as issue attachments during migration. We preserve the original file name, content type, and upload date. Attachments exceeding Jira's size limits (10 MB on Free tier, configurable on paid tiers) are flagged and either linked as external URLs or split into multiple files per the customer's preference. Deduplication by file hash prevents duplicate uploads.

Oracle Configuration Packages (ZIP archives of setup XML for lookups, profile options, flexfields, and workflow rules) do not have a direct Jira equivalent. We extract and inventory every configuration artifact in the package: lookup codes, DFF segment definitions, workflow rule definitions, and approval hierarchies. We deliver a written configuration inventory document that maps each Oracle artifact to a Jira equivalent (custom fields, workflow schemes, project roles, notification schemes) so the customer's Jira admin can rebuild the setup in Jira. This is a documentation deliverable, not a data migration.

Oracle Fusion PM approval and notification workflows built on BPM Worklist (workflow rules, approval hierarchies, assignment configurations stored as workflow definitions) do not migrate to Jira. Jira's workflow model (status-based transitions with validators and post-functions) is structurally different from Oracle BPM. We inventory every active BPM workflow, its trigger conditions, approval steps, assignment rules, and escalation path, and deliver a written workflow map recommending Jira workflow scheme equivalents. The customer's Jira admin rebuilds the workflows using Jira's workflow editor or a third-party workflow app. This is a documentation deliverable, not an automation migration.