Migrate from Nostromo to Jira

Nostromo Projects map to Jira Projects. We infer the project name from whatever field the export uses (project_name, projectTitle, or similar) and create a corresponding Jira Project with the customer-chosen project type (Scrum, Kanban, or Bug Tracking). If the export contains multiple Nostromo workspaces or boards, each becomes a separate Jira Project. We configure the project's default issue type scheme and permission scheme during provisioning.

Nostromo Tasks map to Jira Issues. The mapping from Nostromo task type to Jira issue type is driven by whatever type field the export contains; we default Tasks to Jira Story and any item marked as a bug to Jira Bug. Parent-child task relationships migrate as Jira subtasks (if the destination project allows subtasks) or as linked issues with a 'blocks' or 'is blocked by' link type, depending on the depth of the hierarchy. We parse the export's nesting structure (flat list with parent_id, or nested JSON) and reconstruct the relationship in Jira during the load phase.

Nostromo User accounts map to Jira Users. We use email address as the dedupe and match key. Jira requires that users exist in the destination instance before they can be assigned; we extract the full user list from the export and resolve each against the Jira instance. Users without an existing Jira account go to a reconciliation queue for the customer's admin to provision before the Issue import phase begins. Display name and any role or department data from the export migrate as Jira user properties or as custom fields on the Issue.

If the Nostromo export includes explicit Sprint records with start and end dates, name, and linked tasks, we map them directly to Jira Sprints within the target Jira Project's Scrum board. We resolve Sprint membership by matching task IDs in the export against the Jira Issue IDs created during the Task import phase. If the export does not contain Sprint records but does include date fields on tasks, we fall back to creating Jira Sprints based on task due dates grouped by month or week, with the customer confirming the grouping strategy during scoping.

Nostromo custom field definitions and values migrate as Jira custom fields. We infer the field type from the data (string values become Free Text Fields, numeric values become Number Fields, dates become Date Picker, enumerated values become Select Lists). Jira Premium is required for certain advanced custom field types; if the destination is on Standard tier, we use the closest equivalent and note the limitation. We pre-create the custom field in Jira with the appropriate context (project or global) before the Issue import phase so that values load in a single pass.

Nostromo labels and tags migrate as Jira Labels. We deduplicate the label set from the export, create the label in Jira if it does not exist, and associate it with each Issue during the Task import phase. Jira Labels are global across the instance, so no per-project configuration is required.

Nostromo comments migrate as Jira Comments on the corresponding Issue. We preserve the comment body, author (resolved to Jira User by email), and timestamp. If the export stores comments as a separate table or nested array, we join them to tasks by task_id before loading. Jira's comment character limit applies to very long comments; we truncate at 32,767 characters and note the overflow in the migration report.

Nostromo did not expose attachments through any documented export mechanism. Binary files (images, documents, uploaded assets) associated with tasks or projects are not recoverable from the archived backup format. We flag this gap in the scope document and recommend that customers manually re-attach any critical files if local copies exist. Jira Attachments are not created during migration because there is nothing to migrate.

If the Nostromo export contains version or milestone data (release names, release dates, associated tasks), we map these to Jira Versions within the target project. Version name and release date migrate; description migrates to the Version description field. If no version data is present in the export, we skip this object and note its absence in the migration report.

Nostromo task statuses map to Jira Status values through the target project's workflow. We identify the distinct status values in the export (e.g., Open, In Progress, Done, Blocked) and map them to the closest Jira Status option in the chosen workflow scheme. If the export uses statuses that have no direct Jira equivalent, we map to the nearest Jira status and document the mapping in the scope. Jira Workflow transitions do not migrate as configuration; we document the status mapping and the customer's admin configures the workflow scheme in Jira before or after migration.