Migrate from Z-Stream to Jira

Z-Stream Projects map directly to Jira Projects as the top-level container. Project name, description, start date, end date, and status migrate to Jira Project name, description, and associated Project Category. Owner from Z-Stream becomes the Jira Project Lead. We create Jira Projects before any Issues are imported so that the Project key is available as a reference during issue creation. If Z-Stream uses a hybrid cloud-on-prem deployment, we coordinate with the customer to ensure the source data export comes from the correct environment.

Z-Stream Tasks map to Jira Issues within the target Project. Title maps to Summary, description maps to Description, assignee maps to Assignee (resolved by email), due date maps to Due Date, priority maps to Priority (Low/Medium/High/Critical matched to Jira's Priority values), and estimated hours map to Original Estimate in the Time Tracking field. Status in Z-Stream maps to a Jira Status value that we configure per project during migration setup. Parent Project reference is required before task import begins.

Z-Stream Subtasks map to Jira Issue objects with Issue Type = Subtask. The Parent task reference from Z-Stream becomes the Jira Parent Issue key. Subtasks are imported after all parent Issues have been seeded to guarantee the Parent Issue key exists. Summary, description, assignee, due date, priority, and status carry over using the same field mapping as the parent Task object. If Jira does not have Subtask Issue Types enabled in the target project, we configure the Issue Type scheme before migration or map Subtasks to linked Issues instead.

Z-Stream Milestones are standalone date-bound markers tied to Projects. Jira Software does not have a native Milestone object; we represent milestones as a custom Labels field (prefixed milestone:) or a custom text field milestone_flag__c carrying the milestone name and target date. During Gantt reconstruction, Jira issues with matching milestone_flag values are grouped visually. If the destination Jira project uses a milestone-tracking app (BigGantt, Structure, or Roadmaps), we preserve the full milestone schema for the admin to configure the native app after migration.

Z-Stream Users map to Jira Cloud users by email address. Display name, email, and active/inactive status carry over. Role and permission levels from Z-Stream are stored as a custom field zstream_role__c on the user record post-migration since Jira uses its own permission scheme (Project Roles, Groups, and Account Functions). Inactive or archived Z-Stream users are imported as inactive Jira users to preserve historical assignment data without consuming a paid seat until the account is reactivated.

Z-Stream Time Entries (hours, date, optional notes, linked Task and User) map to Jira Worklog records attached to the corresponding Jira Issue. We resolve the Jira Issue key from the Z-Stream Task reference, then create Worklog entries with timeSpentSeconds, started (ISO 8601 timestamp), and comment. Time entries without a resolvable parent Task are held in a reconciliation queue. If Z-Stream uses billable vs non-billable time flags, we carry these as a custom Worklog field or as a Jira Issue label.

Z-Stream attachments stored as file references are downloaded from the Z-Stream web interface and re-uploaded to the corresponding Jira Issue via the Jira REST API (POST /rest/api/3/issue/{issueIdOrKey}/attachments). Attachments with null filenames are flagged and skipped; we document the issue key and original filename in the migration report for manual resolution. Large binaries are chunked by project to avoid API timeout during the upload phase. Content-type metadata is preserved to ensure correct MIME type assignment in Jira.

Z-Stream custom fields on Projects and Tasks are discovered during scoping and mapped to Jira custom fields by type: text properties map to Jira Text Field (single line), long text to Jira Text Field (multi-line), dates to Jira Date Picker, numbers to Jira Number field, and dropdowns to Jira Select List (single choice) or Multi-Select List. Jira's custom field name is derived from the Z-Stream field label. Dropdown option values are migrated verbatim as Jira options. If a Z-Stream custom field uses a type not supported by Jira (e.g., a complex structured object), we flag it during scoping and map to a Jira Text Area as a fallback.

Gantt layout in Z-Stream is derived from task start dates, end dates, and dependency relationships (finish-to-start, start-to-start, finish-to-finish). We extract these as structured rows and rebuild them in Jira as Issue Links of type Blocks or Blocked, with the link direction preserved to represent the original dependency direction. Start date and end date migrate to Jira Custom Date Fields (gantt_start__c, gantt_end__c) if Jira's native Due Date is already assigned to a different semantic purpose. We document the original dependency graph as a CSV appendix for manual Gantt reconstruction if a Jira Marketplace app is installed post-migration.

Z-Stream Kanban columns correspond to custom status values on Tasks. We extract the full column list including column name, column order, and any column-specific color labels, then configure these as Jira Status values within the target project's Status scheme. Color labels are stored as Jira Labels (prefixed kanban_color:). Column order is preserved through Jira's status ordering configuration. If Z-Stream uses WIP limits per column, we document these in the migration inventory for the customer to reconfigure in Jira's column configuration post-migration.

Z-Stream budget amounts and budget categories are structured fields within Projects that do not have a native Jira equivalent. We map these to Jira custom fields budget_amount__c (Number) and budget_category__c (Select List) on the Jira Project's default Issue Type scheme, making the data available as project-level metadata. If Jira Service Management is present in the destination environment with an Asset or Value Stream module, budget entries can alternatively be modeled as Assets; we document the option for the customer during scoping.

Z-Stream risk entries stored as separate list objects within Projects map to a set of custom fields on the parent Project's issues: risk_description__c (Text Area), risk_impact__c (Select List: Low/Medium/High/Critical), and risk_probability__c (Number as percentage). Alternatively, if the destination Jira environment uses a third-party risk management app (Exalate Risk or Structure), we map risks as linked Issues with Issue Type = Epic or a custom Risk Issue Type configured during migration. The chosen strategy is confirmed during scoping based on the destination's installed apps.

Z-Stream Comments attached to Tasks carry author, timestamp, and body text. These map to Jira Issue Comments via the Jira REST API (POST /rest/api/3/issue/{issueIdOrKey}/comment). Author is resolved by email match against Jira users; comments from unresolved authors are attributed to the migration service account with the original author name preserved in the comment body. Comment timestamps are set to the original Z-Stream timestamp. Rich text formatting from Z-Stream is converted to Jira's wiki-markup-compatible format where possible.