Migrating from Jira
A recommended approach for moving active Jira projects into the 8090 Software Factory knowledge graph.
This document outlines 8090's recommended approach for transitioning an active project from Jira into 8090 Software Factory.
Committing to a Single Source of Truth
8090 Software Factory maintains a knowledge graph that connects requirements, blueprints, and work orders that evolve together. When requirements change, constraints emerge, or code drifts, you can turn on recommended automations and Drift Bot to point out what no longer matches, which keeps the knowledge graph in sync and truthful.
The more context the knowledge graph holds, the better agents perform. That only works when 8090 Software Factory is the authoritative source of truth. Spreading requirements and work orders across tools such as Jira or Notion breaks the connections that agents and teams rely on, and keeping those tools consistent takes time away from delivering software.
Organizations adopting 8090 Software Factory should commit to the knowledge graph as the single source of truth. The recommended path is to migrate active project context out of Jira and into 8090 Software Factory so that teams and agents can work from a shared, connected source of truth.
Choose one system for active work
After cutover, create and update active requirements and work orders only in 8090 Software Factory. Keep Jira read-only for historical context so teams and agents do not work from conflicting sources.
What a Migration Looks Like
A Jira-to-8090 Software Factory migration addresses two distinct objectives, pursued sequentially.
Establish requirements
Extract the product intent fragmented across Jira epics, user stories, and acceptance criteria, then formalize it as structured requirements. Requirements form the foundation of the knowledge graph and must exist before downstream artifacts can build on them.
Migrate active tickets into work orders
Bring the Jira issues your team is executing or planning into work orders and link them to the established requirements. This provides a traceable, live view of in-flight delivery from day one.
Completed and obsolete Jira issues do not need to migrate. Retain them in Jira as a read-only archive and set each migrated project to read-only immediately to eliminate ambiguity about where the source of truth resides.
Objective 1: Migrating Requirements into 8090 Software Factory
Export from Jira. Export the relevant epics, stories, and acceptance criteria as a CSV or document artifact.
Give the export to the Agent. Attach the file to a message in the agent panel. The Agent analyzes the exported content and proposes a set of Feature Requirements documents. This is not a one-to-one mapping of Jira epics to features. 8090 Software Factory applies its own criteria for what constitutes a well-scoped feature and presents its recommendations for confirmation.
Review and approve. The Agent's edits to existing requirements documents arrive as tracked suggestions for you to accept or reject. Treat the Jira export as raw input while the Agent restructures it into properly scoped requirements with clear intent, defined boundaries, and testable criteria.
Build downstream. With requirements in place, author blueprints against them and link work orders to them.
You can also edit requirements through the 8090 Software Factory MCP server, which enables agent-driven migration directly from a connected development environment. Edits made over MCP arrive as tracked suggestions to review in 8090 Software Factory.
Objective 2: Migrating Active Tickets into Work Orders
With requirements established, convert active and upcoming Jira issues into work orders and link them to the corresponding requirements. Several paths are available depending on team size and technical preference.
Upload a CSV to the Agent. Export Jira issues as a CSV from any filtered issue list, attach it to a message to the Agent, and have it generate work orders. Best suited for a curated set of active issues (Jira's native CSV export is limited to approximately 1,000 issues and excludes comments and history).
Use a Dual-MCP Agent Bridge. Connect a coding agent (Cursor, Claude Code, or equivalent) to both the Jira MCP server and the 8090 Software Factory MCP server, then instruct it to read issues from Jira and create corresponding work orders. This provides control over field mapping, hierarchy handling, and filtering.
Script with the Jira REST API. For thousands of issues, Jira's REST API returns complete issue data in JSON, including comments, custom fields, and parent-child relationships. A Python or Node.js script can paginate, transform, and push issues into 8090 Software Factory through its MCP tools or REST API.
Use a Marketplace Export App. When you need richer data (full change history, state transitions, attachments, threaded comments), third-party Jira apps such as Exporter for Jira can produce more complete exports. This matters most in regulated environments that require audit trails.
Recommended Approach
Audit the Jira backlog. Identify which work is active, which is upcoming, and which can remain archived.
Migrate requirements first. Give the exported epics and stories to the Agent, review the proposed feature structure, and approve the resulting requirements documents.
Migrate active tickets into work orders. Bring in-flight and upcoming issues into work orders and link them to the requirements established in the previous step.
Commit to the knowledge graph. Create all new work in 8090 Software Factory and use Jira exclusively as a read-only archive.
The objective is not to replicate Jira inside 8090 Software Factory. It is to move from a fragmented ticket model into a system where every task is connected to the reasoning that produced it.