Migrate from Nozbe to Jira

Nozbe Projects map directly to Jira Projects as the top-level container. Each Nozbe Project becomes a Jira Project with its own key prefix (e.g., PROJ-A), Issue Type Scheme, and workflow. We recommend creating Jira Projects during scoping so that keys are assigned before task import begins. If the customer has multiple Business Spaces in new Nozbe, each maps to a separate Jira Project with a distinct key prefix.

Nozbe Tasks map to Jira Issues. We default to Jira Issue Type = Story for product work items and Task for operational to-dos, consistent with Jira's Scrum and Kanban board conventions. The Nozbe Task title maps to Jira Summary. The Done/undone state maps to Jira Status (To Do, In Progress, Done) through the destination project's workflow scheme. Assignee, due date, and priority transfer directly. Nozbe Priority levels (1=Highest through 4=Lowest) map to Jira Priority levels (1=Highest through 4=Lowest) using the same integer mapping.

Nozbe Tasks with a recurrence rule (daily, weekly, monthly, custom) do not have a direct Jira equivalent because Jira Issues do not carry recurrence rules. We offer two strategies: (1) expand each recurring Nozbe Task into a series of individual Jira Issues, each with an explicit due date computed from the recurrence rule, or (2) store the original recurrence rule as plain text in the Jira Issue description field. Strategy 1 is recommended for teams that use Jira Sprints; Strategy 2 is recommended when the recurrence count is very high (e.g., biweekly for 3 years becomes 78 Jira issues). The customer chooses during scoping, and we flag the task-count impact either way.

Nozbe Comments on Tasks migrate to Jira Issue Comments. We preserve the full comment chronology under each Jira Issue, including author (mapped via User email lookup), timestamp (migrated as Jira Comment created date), and @mentions (stored as Jira mention syntax in comment body). Comment threading in Nozbe is flat; Jira comments are also flat, so the flat structure maps without transformation.

Nozbe Tags are a flat labelling system for Tasks across Projects. They map to Jira Labels, which are also flat and applied to Issues across Projects. The Nozbe Classic export does not include Tags in the JSON backup — we extract the tag list from the Nozbe web interface during scoping if the customer grants temporary read access, or we reconstruct tags from task data where tags appear in task metadata. Jira Labels have no hierarchy, which matches Nozbe's flat tag model.

Nozbe Categories (GTD-context labels such as @calls, @home, @computer) are distinct from Tags and appear in the Nozbe left sidebar. Jira has no native Categories. We map Categories to Jira Labels with a category: prefix (e.g., category:@calls) so that they are distinguishable from Tags in Jira's label filter. Alternatively, if the customer uses Jira Components per Project, we offer to map Nozbe Categories to Components as a Project-scoped alternative. The customer selects during scoping.

Nozbe file attachments on Tasks migrate to Jira Issue Attachments. We transfer attachment URLs from the Nozbe Classic JSON export and re-attach them to Jira Issues using the Jira REST API's attachment endpoint. File names, sizes, and upload dates are preserved. Jira's 256MB per-file limit is the only constraint; we flag any Nozbe attachments exceeding this before import and store them in a shared location referenced in the issue description.

Nozbe Team Members (workspace users with admin or member roles) map to Jira Users by email address. We extract the member list from Nozbe during scoping and match against the Jira destination's user directory. Members without a matching Jira User go to a reconciliation queue for the customer's Jira admin to provision before production migration. Jira's site-level user management is used to create the user in the destination org.

Nozbe Business Spaces (enterprise organisational units in new Nozbe) map to Jira Projects. Each Business Space contains Projects and Members; we map the Business Space to a Jira Project hierarchy or a Jira Project Group if the customer uses Jira's Project Groupings feature. The Business Space name becomes the Jira Project name, and Business Space Members are granted project-level Jira roles (Administrators, Members, Viewers) during import.

Nozbe Inbox items are a GTD capture zone for unsorted tasks and have no direct Jira equivalent. Jira has no Inbox concept — all work must belong to a Project. We do not migrate Inbox items as Inbox items. During scoping, we identify the Inbox item count and offer two strategies: (1) route Inbox items into a designated Jira Project (e.g., a Backlog project) as Jira Issues, or (2) deliver a written list of Inbox items for manual triage post-migration. We disclose this gap in the migration scope document.