Migrate from PROAD to Jira

PROAD Projects map directly to Jira Projects. The project name, description, status (active/archived), start date, and target end date migrate as Project Name, Description, Project Category, and Start Date fields in Jira. PROAD project-level custom fields map to Jira Project Properties or custom fields on the project's default issue type. We preserve the project key as a Jira project prefix (2-5 uppercase characters) derived from the original PROAD project code if available.

PROAD Subprojects map to Jira Epics within the target Jira Project. Each subproject becomes an Epic with its own summary, description, target dates, and assignee. The subproject's task hierarchy (child Tasks) becomes Stories and Subtasks under the Epic. We flag whether the customer prefers Epic-level reporting in Jira or whether Subprojects should map to Jira Projects with a shared Jira Project parent, which is the alternate structure for organizations that use Jira Projects as the top-level container for multi-team work.

PROAD Tasks map to Jira Issues using a configurable default issue type (typically Story for deliverable work items and Task for action items). PROAD Task fields including summary, description, due date, priority, status, and assignee assignment migrate to the equivalent Jira Issue fields. Subtask relationships map to Jira Subtasks linked via the Parent Issue key. We preserve PROAD task-level custom fields as Jira custom fields on the mapped issue type.

PROAD Milestones map to Jira Fix Versions (release versions) associated with the target Jira Project. Milestone name becomes the Fix Version name, and the target date migrates as the Fix Version release date. Milestone completion status is preserved as a Jira custom field linked to the Fix Version so that customers can report on milestone completion without relying solely on Fix Version release tracking. If PROAD milestones are scoped to subprojects, the corresponding Fix Version is scoped to the Jira Epic that represents the subproject.

PROAD Client records map to Jira Organizations (available in Jira Premium and Standard; requires Jira Service Management for full contact management). Client name becomes Organization name, and client contact details (email, phone, address) populate the Organization's attributes. We flag that Jira Organizations do not store individual contact person records by default; if the customer requires per-contact data (billing contacts, project managers), we recommend either Jira Service Management for contact-level management or a parallel CRM migration to a tool like HubSpot or Salesforce.

PROAD Contacts map to Jira Users by email address match where the contact is an active Jira user, or to Organization attributes if the contact is a client-side stakeholder without a Jira license. Contact-level fields (email, phone, title, custom properties) are mapped to Jira User profile fields for internal team members, or to a Jira custom Contact record object if the customer licenses Jira Service Management. External contacts without Jira access are stored as Organization-linked attributes.

PROAD Time Entries map to Jira Issue Worklog records. Each time entry's hours, date, user attribution, and billable flag migrate to the corresponding Jira Issue. We preserve the PROAD billable flag as a Jira custom field on Worklog if the customer needs billable hour reporting in Jira, noting that Jira's native Worklog does not include a billable flag. If PROAD time entries are linked to billing rates (per-user or per-project), we document these as a separate billing rate mapping table for the customer's finance team to configure in Jira or a connected billing tool.

PROAD Tickets map to Jira Issues using a configurable default issue type (typically Task for service requests, Bug for defect tracking). Ticket status, priority, description, and conversation history migrate to the equivalent Jira Issue fields. PROAD's ticket-to-project or ticket-to-client linkage is preserved as a Jira custom field (original_ticket_project__c or original_ticket_client__c) since Jira does not natively support cross-project ticket routing without Jira Service Management. We advise customers on whether to use Jira Service Management for formal ticket management post-migration or consolidate all work into Jira Software projects.

PROAD Users and Assignees map to Jira User accounts by email address match. We extract every distinct user referenced on Projects, Tasks, Time Entries, and Tickets and match against the destination Jira site's user table. Users without a Jira account are held in a reconciliation queue for the customer's admin to provision. Role and permission data (PROAD's internal access levels) does not map to Jira's permission scheme and is delivered as a written inventory for manual configuration.

PROAD custom fields on Projects, Tasks, Subprojects, and Contacts are inventoried during discovery and mapped to Jira custom fields of equivalent data type (text, number, date, select, multi-select, user picker). Jira field type constraints (required fields, field-level security, field context by project or issue type) require pre-migration configuration. We flag any PROAD custom field that has no Jira equivalent and document it as a custom field requiring either a Jira Marketplace app or a post-migration manual entry strategy.

File attachments on PROAD Tasks, Projects, and Tickets migrate as Jira Issue Attachments linked to the corresponding Jira Issue. We audit attachment sizes during discovery and flag any files exceeding Jira's 10 MB per-file limit (or higher limits on paid tiers) for separate handling. Attachment metadata (upload date, uploader) is preserved as Jira attachment attributes. Links to external files in PROAD (URL-based attachments) are preserved as Jira remote object links.

Tags applied to PROAD Projects, Tasks, and Contacts normalize to Jira Labels. We apply a lowercase normalization rule to avoid label duplication from inconsistent casing in PROAD. Jira Labels are project-scoped and issue-type-agnostic, so the customer should review whether tags represent project categorization (better suited for Jira Project Categories or Fix Versions) or issue-level flags (correctly suited for Labels) during scoping.