Migrate from zeno.pm to Jira

zeno.pm Portfolios aggregate Programs and Projects by investment, region, or business unit. Jira has no native portfolio object above Project level. We map each Portfolio to a Jira Project and use Jira Labels or a custom Portfolio__c field to carry the grouping name. If the customer requires multi-project roll-up reporting, we configure the Structure for Jira app (Atlassian Verified) or document the JQL-based filter set for manual portfolio dashboards. Financial KPIs at the portfolio level migrate as custom fields on each child Project rather than as a roll-up object.

zeno.pm Programs aggregate multiple child Projects under a single program umbrella. In Jira, we map Programs to Epic issue type. The Epic Link custom field connects child Stories and Tasks to the Epic. We preserve program-level status, description, and program manager as custom fields on the Epic record. The program-to-project parent-child relationship is preserved as Epic-to-Issue linkage rather than a separate hierarchy object.

zeno.pm Projects map directly to Jira Projects as the top-level container. Project name, description, start date, target end date, and status migrate to Jira Project metadata. Jira Project key, project lead, and default issue type scheme are configured during Jira setup. zeno.pm project-level custom fields (configured via form-builder) map to Jira custom fields created before import.

zeno.pm Risks are structured records with title, likelihood, impact, status, owner, and mitigation notes. We map these to Jira Issues using a custom Risk issue type. Likelihood and impact map to Jira Priority (Critical, High, Medium, Low) or to custom single-select fields. Mitigation notes map to the Issue Description or a custom Mitigation__c field. Risk owner maps to Jira Assignee. We attach risk registers as structured child records of the parent Project issue or as linked issues using Jira issue links.

zeno.pm Issues (separate from Risks) track project-level problems, blockers, and action items. We map these to Jira Issue types based on their zeno.pm category: bugs map to Bug, general problems map to Task, and stakeholder requests map to Story. Priority, status, and owner transfer directly. The zeno.pm issue description and any linked files (attachments, which cannot be migrated via API) are documented for manual re-upload.

zeno.pm resource records track team member names, roles, allocation percentages, and availability. We extract all resource records and map them to Jira User accounts by email address. Allocation percentages migrate to Jira custom fields (Allocation__c) on the User record or to project-level capacity views if the Structure app is deployed. Jira requires that users are provisioned before issues referencing them can be imported, so we run user reconciliation before project data migration.

zeno.pm stores milestones as project-level date properties and project metadata rather than as independent schedule objects. We map milestones to Jira Fix Version (Releases) for delivery milestones and to Jira Issues with a Milestone__c custom field for programme-level milestones. Start dates migrate as Start Date on Jira Issues where the Jira project has that field enabled. Dependency relationships between milestones map to Jira issue links (Blocks / is blocked by) or to Structure app dependency views.

zeno.pm stores budget, actual spend, and forecast as project-level financial properties. Jira has no native financial fields. We create Jira custom number fields (Budget__c, ActualCost__c, ForecastCost__c) on the Project-level issue or on a dedicated Financial Summary issue. Currency values migrate as-is; Jira does not enforce currency conversion so the customer's admin sets the reporting currency. If Jira has Service Management enabled, Financial fields may alternatively be tracked in Jira Service Management Customer Portal assets linked to the project.

zeno.pm allows organisations to define custom fields on Projects, Programs, and Portfolios via its form-builder. These are not documented in a public API reference. During discovery, we request the full form schema from zeno.pm support or extract it from the admin console, then map each custom field to an equivalent Jira custom field by type: text to Jira Text Field, picklist to Jira Select List, date to Jira Date Picker, number to Jira Number Field, user reference to Jira User Picker. Picklist dependencies and conditional visibility rules are documented in the field mapping notes and flagged as manual configuration items in Jira.

zeno.pm embeds AI features that generate or enrich project data such as summaries or risk flags. We identify records with AI-generated content during profiling, preserve the output as plain text in the Jira Issue Description or a custom AI_Content__c field, and flag the record with an AI_Generated__c checkbox so the customer's team can review and verify before treating it as authoritative data in the new system.