Migrate from Project Nucleus to Jira

Project Nucleus projects map directly to Jira projects. Each becomes a Jira project with its Project Key assigned during migration. We preserve project description, dates, status, and ownership. Jira project keys must be uppercase alphanumeric (2-10 characters) and cannot be changed post-creation, so we validate key feasibility during scoping and flag any conflicts with existing Jira projects in the destination tenant.

Project Nucleus tasks map to Jira Stories or Tasks depending on the customer's preference and the task's position in the hierarchy. Tasks with no subtasks typically become Jira Tasks; tasks that function as containers for work items become Stories within an Epic. Assignee, due date, status label, and description migrate directly. Jira's summary field accepts up to 255 characters; we truncate Project Nucleus task names exceeding this and flag the truncation for review.

Project Nucleus subtasks map to Jira Subtasks. Subtask issue type must be enabled in the destination Jira project's issue type scheme; we verify this during scoping and configure the issue type scheme if subtasks are not included. Nesting depth beyond one level (Subtask of a Subtask) is not supported in standard Jira; we flatten additional nesting into flat subtasks and flag the flattening for admin review.

Project Nucleus custom field definitions vary per project. We extract the full custom field schema for each project during scoping, map each field to an equivalent Jira custom field type (text, number, date, select, multi-select, URL, user picker), and flag any fields with unsupported Jira types (complex formulas, cross-project calculations) for manual handling. Jira requires custom fields to be created at the instance level before they can be added to project contexts; we handle instance-level provisioning before record import.

Project Nucleus attachments are stored as linked references with URLs. We validate all attachment URLs post-migration to confirm they resolve. For attachments hosted within Project Nucleus's file storage, we download and re-upload to Jira's attachment storage so that links remain functional. Jira has a 256 MB per-file attachment limit and a 10 MB per-file limit for emails; we flag any attachments exceeding these limits before migration.

Project Nucleus team structures map to Jira Groups. Membership is preserved with each user's email as the dedupe key. Archived or inactive memberships are flagged for review. Jira Groups are used for project membership and permission schemes; we map Project Nucleus team assignments to Jira project roles (Members, Administrators, Viewers) based on the customer's role matrix during scoping.

Project Nucleus user records (name, email, role) map to Jira user accounts. We resolve users by email match against the destination Jira site's user directory. If Jira uses Atlassian account email login, we verify that each Project Nucleus user has an active Atlassian account before migration. Users without a match enter a reconciliation queue for manual provisioning before record import resumes.

Project Nucleus comments on tasks and projects migrate to Jira Comments on the corresponding Issue. Author attribution, timestamp, and full comment body transfer. Comment threading order is preserved by setting the Jira comment creation date to the original timestamp. Rich text formatting is converted to Jira's wiki-markup renderer where applicable.

Project Nucleus time entries (where present in the source configuration) map to Jira Work Logs. We preserve time spent, author, and date. Jira's Work Log visibility respects the project's permission scheme; we verify that the importing user's permission allows work log creation across all target projects. Time entries that exist as a flat numeric field rather than a structured entry are mapped to a custom field instead of a work log.

Project Nucleus status labels are per-project text values with no enforced workflow semantics. We map each distinct Project Nucleus status to an equivalent Jira Status within the destination project's workflow. Custom status labels that have no direct Jira workflow equivalent are mapped to the closest standard status (To Do, In Progress, Done) and flagged for the customer's admin to create a custom workflow if tighter matching is required.

Project Nucleus labels and tags migrate to Jira Labels as text annotations. Jira Labels are an instance-level tag system that can be applied across issue types. We convert Project Nucleus label strings to Jira Label format and apply them to the corresponding Issue. Labels that represent categorical data (e.g., product line, region) are noted for potential migration to Jira custom select fields if the customer prefers structured filtering over free-text labels.

Project Nucleus documents linked within projects require path re-validation. We confirm document accessibility post-migration and flag any that cannot be reached through original paths. Jira does not have a native document management object separate from attachments; documents that are primarily textual content migrate as Comments with a URL reference, while binary documents migrate as Attachments on the parent Issue.