Migrate from Planview Daptiv to Jira

Daptiv portfolios contain projects in a parent-child hierarchy. Jira has no native portfolio object above the project level. We map each Daptiv portfolio to a Jira project, use Jira project categories to group related projects that shared a Daptiv portfolio, and add a custom picklist field daptiv_portfolio__c to preserve the original portfolio name for filtering and reporting. If multiple Daptiv portfolios map to one Jira project, we create separate Jira projects and use the project category to represent the portfolio rollup conceptually.

Daptiv projects map 1:1 to Jira projects. We preserve project name, description, start and target dates (as custom date fields because Jira's native Project dates are admin-only and not user-editable), project status (mapped to Jira project status), and owner (mapped to the Jira project lead via custom field daptiv_project_owner__c). Daptiv workflow states translate to Jira status values in the project's default workflow configuration.

Daptiv tasks map to Jira issues with issue type determined by task characteristics. Standard tasks map to Jira Issue type Task, deliverables-bearing tasks map to Story, and tasks with specific completion criteria map to Jira subtasks as appropriate. We preserve assignment, dates, effort, and dependencies. Gantt dependencies between tasks map to Jira issue links of type Blocks or is Blocked to preserve the critical path sequence.

Daptiv milestones are first-class objects with target dates and deliverables. We map them to Jira Fix Versions (Releases) under each project, preserving the target date as the Fix Version release date. Deliverable descriptions migrate as version description. Jira does not natively support milestone-type records above versions; if the customer requires a milestone tracker across projects, we recommend creating a dedicated Jira project to act as a milestone register and cross-linking it to Fix Versions via issue links.

Daptiv resources carry billing rates, skill assignments, and allocation percentages. Jira has no native resource pool. We extract Daptiv resources as Jira users, map their billing rate to a custom number field daptiv_billing_rate__c, and map allocation percentage to daptiv_allocation_pct__c. The customer's Jira admin provisions matching user accounts before migration. Jira's capacity model is sprint-based rather than percentage-based; if the customer needs resource load views, we document the custom Jira configuration or Jira Portfolio add-on needed to surface daptiv_allocation_pct__c data in a load-chart format.

Daptiv resource allocation records (percentage assigned, demand-vs-availability) have no native Jira equivalent. We store allocation percentage as daptiv_allocation_pct__c on the Jira issue (mapped from the Daptiv resource assignment record) and map availability data to a project-level custom field. Jira's sprint capacity view does not display allocation percentages; the customer must rebuild this view in Jira Portfolio for Jira or a third-party resource management app if ongoing load tracking is required.

Daptiv time entries record actual work against tasks with hours, dates, and resource. Jira natively supports worklogging via the Worklog object with time spent and date. We map Daptiv time entries to Jira worklog records, preserving hours as time spent and the entry date as the worklog date. Billing rate information from the Daptiv resource record transfers to the daptiv_billing_rate__c custom field on the issue so cost reporting can be calculated post-migration as hours multiplied by rate.

Daptiv calculates planned cost from per-user billing rates and actual cost from time entries. Jira has no native cost accounting. We preserve the Daptiv budget figures as custom number fields on the Jira project: daptiv_planned_cost__c, daptiv_actual_cost__c, daptiv_budget_variance__c. Cost calculations in Jira require the customer's admin to configure Jira Dashboard gadgets or an Atlassian Marketplace reporting app (like Tempo for cost tracking) to display the migrated financial data against current worklogs.

Daptiv custom fields on projects and tasks vary by tenant. We inventory all active custom fields during discovery, map each to a Jira custom field of matching or nearest type (text, number, date, picklist, checkbox), and deploy the schema into the target Jira projects before record migration. Jira requires custom field context to be scoped to the relevant projects and issue types; we configure this during setup to avoid the known Jira import error where a custom field is not available to the migrated issue types.

Daptiv stores files in DeskDocs, a document management layer separate from task records. We extract files as binary blobs using Daptiv's export tooling, match them to the correct Daptiv task by file naming conventions or metadata, and upload them as native Jira issue attachments. This requires per-file metadata parsing and additional processing time. We store the original DeskDocs file path in a custom field daptiv_deskdocs_path__c for audit. Jira's recommended attachment storage limits apply (100 MB per file in Cloud; configurable in Data Center).