Migrate from ONES.com to Jira

ONES Projects map directly to Jira Projects. Each Jira Project is created with a matching key structure (we reserve the project key during scoping to avoid conflicts). Project templates in ONES (Scrum, Kanban, general task management) inform the Jira project template selection. ONES Project on-premises or cloud variants map to Jira Cloud, Data Center, or Server depending on the destination environment the customer selects.

ONES Tasks map to Jira Issues with the issue type determined by the task classification in ONES. Standard tasks map to Jira Tasks; tasks linked to Requirements map to Stories or sub-tasks depending on the customer's chosen issue type scheme. We preserve the parent-child task hierarchy by mapping ONES subtasks to Jira sub-tasks with the same parent Issue key. Assignee, priority, status, due date, and time tracking fields map to their Jira equivalents (assignee, priority, status, duedate, timetracking).

ONES Requirements are distinct work items for capturing product specifications. They map to Jira Epics if they contain child tasks or stories, or to Stories if they are standalone specification items. The linkage semantics (how Requirements relate to downstream tasks and test cases) translate to the Epic-Story-Task hierarchy in Jira. We preserve the Requirement description and acceptance criteria as the Issue description field, and link child tasks via the Jira Epic Link custom field or parent-link field depending on the project configuration.

ONES Bugs map directly to Jira Bug issue type. Bug severity, steps to reproduce, and environment fields from ONES map to custom fields or standard Jira fields as appropriate. Bugs linked to Tasks or Requirements in ONES maintain their linkage as parent-child relationships in Jira. We verify that the destination Jira project has a Bug issue type configured before migration begins.

ONES Sprints map to Jira Sprints within the corresponding Jira Project. Sprint start and end dates, goal descriptions, and status (Active, Completed, Closed) transfer to the Jira Sprint record. We map sprint-task assignments by creating the Jira Sprint before task import and resolving sprint references during the task phase. Active sprints are created in Jira before migration begins; completed sprints are created with the correct date ranges so the historical sprint board reflects the original ONES timeline.

ONES TestCases contain test steps, expected results, and pass/fail history linked to Requirements and Builds. Jira does not have native test case management without Jira Test Management (a separate add-on). We migrate TestCases as Jira Issues with a custom Test Case issue type if Jira Test Management is not present, preserving test steps in the description field and test status in a custom field. If Jira Test Management is available, we map to Test Execution records. The customer chooses the strategy during scoping. Build associations do not migrate as CI/CD systems are separate.

ONES Wiki pages map to Confluence pages within the project's associated Confluence space. We export the ONES Wiki page tree structure and recreate it as a Confluence page hierarchy. Wide-table pages (exceeding approximately 720px width) are exported as Word (.docx) rather than PDF because ONES PDF export silently truncates wide tables. Rich-text content, headings, code blocks, and images transfer; complex table formatting may require manual adjustment post-migration. Page metadata (author, created date, last modified) migrate as page properties.

ONES Project members map to Jira Users by email address match. User profiles (name, email, avatar) transfer to Jira. We resolve all task assignees, bug assignees, and test case owners by matching the ONES user email to the Jira user account. Any ONES user without a matching Jira account goes to a reconciliation queue for the customer's Jira admin to provision before record import resumes.

ONES custom fields on Tasks, Bugs, Requirements, and Wiki pages map to Jira custom fields of the equivalent type (text, number, date, dropdown, user reference). Jira requires custom fields to be scoped to specific issue types and projects before data import. We pre-create the Jira custom fields during the schema design phase and verify that the field context includes the issue types receiving ONES data. Custom field values transfer as-is where the field type matches; dropdown values require a value-mapping table if the options differ between platforms.

Attachments on Tasks, Bugs, and Wiki pages in ONES are downloaded from ONES storage and re-uploaded to the corresponding Jira Issue or Confluence page during migration. File names, sizes, and upload timestamps are preserved. The migration user account must have attachment creation permissions in Jira and Confluence. Large attachments (exceeding Jira's size limit per the destination tier) are flagged during the audit for customer review.

ONES Project automation rules (triggers for task status changes, assignee updates, notifications) are not exposed via any documented migration API and cannot be exported or transferred to Jira. We identify all active automation rules during discovery and deliver a written inventory documenting each rule's trigger, conditions, and actions with a recommended Jira Automation for Cloud or Jira Automation (Server) equivalent. The customer's admin rebuilds these rules post-migration. This is not a FlitStack AI deliverable as part of the standard migration scope.

CI/CD pipeline definitions in ONES Build and ONES Pipeline are tightly coupled to the ONES execution environment and connected repositories. These configurations are not portable across platforms and must be rebuilt in the destination CI/CD system (Bitbucket Pipelines, GitHub Actions, GitLab CI, or Jenkins). We do not migrate pipeline data. We migrate the associated Build and TestCase records, noting that pipeline definitions require manual rebuild. The customer should plan CI/CD rebuild as a parallel workstream alongside the Jira migration.