Migrating from Jira
A recommended approach for moving active Jira projects into the Software Factory knowledge graph.
This document outlines 8090's recommended approach for transitioning an active project from Jira into Software Factory.
Committing to a Single Source of Truth
Software Factory maintains a knowledge graph that connects requirements, blueprints, and work orders that evolve together. When requirements change, constraints emerge, or code drifts, the system propagates updates to keep the knowledge graph in-sync and truthful.
The depth of context within the knowledge graph determines the quality of agent output. Realizing this value requires that Software Factory serve as the authoritative source of truth. Distributing requirements and work orders across multiple systems (e.g. Jira, Notion, etc.) severs the connections that agents and teams rely on, and the overhead of maintaining consistency between tools displaces time that would otherwise be spent delivering software.
Organizations adopting 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 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 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-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 Software Factory
Export from Jira. Export the relevant epics, stories, and acceptance criteria as a CSV or document artifact.
Upload to the Requirements agent. 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. Software Factory applies its own criteria for what constitutes a well-scoped feature and presents its recommendations for confirmation.
Review and approve. The agent edits requirements documents directly. 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 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 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 Work Order Agent. Export Jira issues as a CSV from any filtered issue list, upload to the Work Order 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 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 (/rest/api/3/search) 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 Software Factory via its MCP tools or API.
Use a Marketplace Export App. When richer data is required (full change history, state transitions, attachments, threaded comments), third-party Jira applications such as Exporter for Jira can produce more comprehensive exports. Particularly relevant in regulated environments where audit trails are a requirement.
Recommended Approach
Audit the Jira backlog. Identify which work is active, which is upcoming, and which can remain archived.
Migrate requirements first. Export epics and stories to the Requirements 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 Software Factory and use Jira exclusively as a read-only archive.
The objective is not to replicate Jira inside 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.