Migrate from Forecast to Jira

Forecast Projects map directly to Jira Projects. The Forecast project name, description, status, start date, and end date migrate to the Jira Project with equivalent fields. Jira Projects require a Project Type (Team-managed or Company-managed) and a Lead; we set the Project Lead to the Forecast project owner during scoping. Jira project keys are derived from the Forecast project name truncated to the Jira maximum of 10 characters.

Forecast Phases map to Jira Epics within the target Jira Project. The Phase name becomes the Epic name, Phase description becomes Epic description, and Phase start/end dates map to Epic start and due dates. Jira Epics allow Stories and Tasks to be linked as child issues, which mirrors how Phases contain Tasks in Forecast. If the customer uses Sprints, we discuss whether Phases should map to Sprints instead; Epic is the default for hierarchical mapping.

Forecast Tasks map to Jira Stories (for user-facing deliverables) or Tasks (for internal work items). We preserve the Forecast Task name as the Jira Summary, the description as the Jira Description, the assignee as the Jira Assignee, and the due date as the Jira Due Date. Status mapping follows the status value map defined during scoping: Forecast's status values (Active, On Hold, Completed, etc.) map to Jira status categories (In Progress, To Do, Done).

If a Forecast Task has child tasks, those child tasks migrate as Jira Subtasks linked to the parent Story or Task. Jira Subtasks inherit the parent issue type context and share the same workflow. We use the parent task reference from Forecast to establish the Jira subtask relationship during import.

Forecast Milestones carry a name and a target date tied to a Project. Jira has no native Milestone object in the standard issue model. We map Milestones to either the Jira Due Date on the parent Epic or Story, or to a custom Milestone field if the customer requires a dedicated Milestone tracker. During scoping we confirm the preferred approach based on how the customer uses Milestones for delivery reporting.

Forecast Custom Fields (text, numeric, choice types) applied to Projects, Phases, Tasks, and Time Registrations require field-level mapping to Jira equivalent fields. We identify every non-standard field during scoping, verify type compatibility (text to Jira Text Field, number to Jira Number Field, choice to Jira Select List), and confirm that choice options are reproduced in Jira. Jira Software Premium includes custom fields at no additional cost; standard plans have limits on custom field count per issue type.

Forecast Time Registrations carry hours, date, billable flag, and optionally a rate, linked to a Task or Project. We map these to Jira Work Logs on the equivalent migrated issue. The billable flag becomes a Jira custom field or a Work Log comment. The rate value migrates to a custom field on the issue since Jira Work Logs do not store a rate by default; we flag this during scoping and create the custom rate field before migration.

Forecast Rate Cards define hourly billing rates per role or person. Jira has no native Rate Card object. We extract the rate card structure during discovery, then discuss with the customer whether to store rates as custom fields on Jira User profiles (for role-based rates) or as a separate configuration document for manual lookup. If the customer requires time-and-materials billing in Jira, we recommend Jira Software Premium with a time-tracking configuration or a third-party billing app from the Atlassian Marketplace.

Forecast Resource Assignments link a team member to a task with an allocated percentage or hours. We extract the assignment records and map the Forecast user reference to the Jira Assignee field on the migrated issue. Jira Assignee is a standard User field. We resolve Forecast users to Jira users by email match and flag any orphaned assignments (Forecast user without a matching Jira user) for the customer admin to provision before the final import run.

Forecast Users (project managers, team members, time trackers) migrate as Jira Users. We match by email address. Jira requires the migration user to have the necessary project permissions. Any Forecast user without a Jira account goes to a reconciliation queue; the customer's Jira admin provisions the missing account before migration resumes.