Migrate from Productive to Jira

Productive Projects map directly to Jira Projects. We preserve project name, description, status (active/archived), start and end dates, and assigned members. Jira projects require a project type (Team-managed or Company-managed) and a Lead user; we resolve the Productive project owner to a Jira project lead during import. Archived Productive projects can be migrated as archived Jira projects or excluded based on customer preference.

Productive Lists are project-level groupings of Tasks. Jira has no direct List equivalent. We map Lists to Jira Components (for structural grouping) or Labels (for tagging flexibility) depending on how the customer uses Lists. If Lists are used for workflow stages, we map them to Jira statuses or a Status Category. The customer chooses the strategy during scoping. Labels are preferred for flexibility; Components are preferred for assignment-based grouping.

Productive Tasks map to Jira Issues. Task name becomes Issue Summary. Task description maps to Jira Description (stored as wiki-markup or rich text depending on destination Jira version). Assignee, due date, estimated hours, and priority transfer directly. Subtasks in Productive map to Jira Subtask issues linked via the Parent Link field. Task status in Productive (todo, in progress, done) maps to Jira status values that we configure during Jira schema setup.

Productive Milestones (dated targets within a Project) map to Jira Fix Versions. Milestone name becomes Version name; Milestone due date becomes the Version release date. If the customer uses Milestones as deliverables rather than releases, we alternatively document them as Jira Labels with a milestone_tag prefix so they appear in filters and reports. Fix Version is the default because it ties directly to Jira release reports and burndown charts.

Productive time entries map to Jira Worklog entries on the corresponding Issue. We preserve the date, time spent (in hours), description, and billable flag. Jira Worklogs do not have a billable flag natively; we store the billable status as a Jira custom field (billable__c: checkbox or option) so that billing-capable apps or reports can reference it. User is resolved via email match to the Jira user account. Jira's rate limit for worklog creation (around 100 requests per minute per user) requires chunking for large time entry volumes.

Productive budgets (recurring and one-time, tied to projects or clients) have no Jira native equivalent. Jira Software does not include budget tracking. We extract budget amounts, types, and periods into a CSV inventory for the customer. If the customer uses a financial reporting tool alongside Jira (e.g., a BI dashboard or PSA), we map budget data to a custom field on the Jira Project for reference. Otherwise, budgets are documented as excluded data with a manual rebuild recommendation.

Productive expenses (amount, date, description, category, billable flag) map to Jira Issue custom fields or a linked custom object if the customer creates one. Jira does not have a native Expense object. We extract all expense records into a structured CSV with project and task linkage preserved, and either import as custom fields or hand off as a documented dataset for the customer's finance team to reconcile in their billing tool.

Productive Invoices are generated from recognized time entries and expenses. Jira has no invoice or billing object. We do not migrate invoices. Instead, we extract invoice headers, line items, totals, and payment status into a PDF inventory for the customer's records, and we flag any open invoices with unrecognized time entries that require resolution before cutover. The customer's billing team closes all Productive invoices or converts them to a separate accounting system before migration.

Productive rate cards define service rates by role or person tied to tracked time for billing. Jira has no rate card object. We extract rate card definitions (role, rate, currency) into a CSV inventory. If the customer moves billing to a third-party tool (e.g., NetSuite, FreshBooks, Harvest), the rate card data is handed off as structured data for that tool's setup. This is documented but not migrated into Jira.

Productive Members map to Jira Users resolved by email address. We extract name, email, role (internal role in Productive), and active/inactive status. Jira user provisioning is the customer's responsibility; we validate that a Jira User exists for every Productive Member referenced in the migration. Missing users go to a reconciliation queue. Productive member permissions do not migrate as Jira permission schemes; we document the permission structure as a reference for the customer's Jira admin to configure post-migration.

Productive Teams group Members for resource planning and capacity management. Jira Groups serve a similar organizational function for permissions and notifications. We map Productive team memberships to Jira Groups by team name, preserving the member-to-group relationships. Jira Groups do not include capacity or resource planning features; those require Jira Workforce Management (Premium+) or a third-party app. We document the team capacity data from Productive for reference.

Productive Skills tag Members with competencies for resource matching. Jira has no Skills object; we map Skills to Labels on the User record or to a custom multi-select field on User. Skills are extracted as a CSV (member, skill, proficiency) and either imported as Jira Labels or handed off for the customer's admin to assign. Resource matching requiring skill-based assignment requires Jira Talent or a third-party resource management app post-migration.