This document outlines 8090's recommended approach for transitioning an active project from Jira into Software Factory.

Software Factory maintains a knowledge graph that connects requirements, blueprints, work orders and tests 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.

A Jira-to-Software Factory migration addresses two distinct objectives, pursued sequentially.

Objective 1: Establish requirements. Most Jira projects encode product intent across epics, user stories, and acceptance criteria, but that intent is fragmented and implicit. The first objective is to extract and formalize it as structured requirements. Requirements form the foundation of the knowledge graph, so they must be in place before downstream artifacts can build on them.

Objective 2: Migrate active tickets into work orders. With requirements established, the next objective is to bring the Jira issues your team is currently executing or planning to execute into work orders. These work orders are linked to the requirements created in the first objective, providing a traceable, live view of in-flight delivery within Software Factory 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.

1. Export from Jira. Export the relevant epics, stories, and acceptance criteria as a CSV or document artifact.
2. 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.
3. Review and approve. The agent edits requirements documents directly. Treat the Jira export as raw input. The agent restructures it into properly scoped requirements with clear intent, defined boundaries, and testable criteria.
4. Build downstream. With requirements in place, blueprints can be authored against them and work orders can be linked to them.

Support for editing requirements via the MCP server is coming soon, which will enable agent-driven migration directly from a connected development environment.

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.

1. Audit the Jira backlog. Identify which work is active, which is upcoming, and which can remain archived.
2. Migrate requirements first. Export epics and stories to the Requirements agent, review the proposed feature structure, and approve the resulting requirements documents.
3. Migrate active tickets into work order. Bring in-flight and upcoming issues into work orders and link them to the requirements established in the previous step.
4. Commit to the knowledge graph. All new work is created in Software Factory. Jira serves exclusively as a read-only archive of historical context.

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.