Migrate from Nifty to Jira

Nifty Projects map directly to Jira Projects. We extract project metadata (name, description, start date, end date, status) via GET /operation/projects and preserve the project hierarchy if Portfolios were used in Nifty. Jira Projects require a Project Type (Team-managed or Company-managed) and an Issue Type Scheme; we configure these before migration based on the customer's workflow preference.

Nifty Tasks map to Jira Issues with the Issue Type determined by a pre-migration classification rule. Tasks marked as bugs or defects in Nifty map to Jira Bug. Tasks with sub-items map to Jira Story or Task with linked Subtask Issues. Task description (markdown) converts to Jira Description (Atlassian Document Format or plain text). Assignee resolution happens via email match against Jira Users.

Nifty Subtasks map to Jira Sub-Task Issues linked to their parent Jira Issue. The parent-child relationship is preserved via the Parent Link field. Subtask title, status, assignee, and due date migrate directly. Jira Sub-Tasks inherit the parent project's Issue Type Scheme; if the destination project does not allow Sub-Tasks, we flatten them to linked Issues instead.

Nifty Milestones have no direct Jira equivalent. Milestones are standalone objects that link tasks to a target date. We map Nifty Milestones to Jira Fix Versions (Release field) on the migrated Issues, with the milestone name stored in the Fix Version name and the due date mapped to the release date. Milestones without linked tasks are created as unreleased Fix Versions for documentation. If the customer uses milestones as goal-trackers rather than deadline markers, we map them to Labels instead and document the alternative during scoping.

Nifty custom field definitions are per-project. We deduplicate across all projects during scoping, consolidating same-named fields (e.g., 'Client Name' appearing in multiple projects) into a single Jira global custom field to avoid schema drift. Field types map: Nifty text to Jira Text Field, Nifty number to Jira Number Field, Nifty date to Jira Date Picker, Nifty choice to Jira Select List (single) or Radio Button. Custom fields are created in Jira before any Issues are imported to avoid type errors.

Nifty Discussions (project-level comment threads on tasks or standalone) map to Jira Issue Comments. We extract the full thread, author email, timestamp, and any embedded file references. Comments are imported after the parent Issue exists in Jira to maintain the correct association. Jira Comments support Atlassian Document Format; we convert Nifty markdown to the equivalent format.

Nifty Docs are rich-text documents stored per project. We export document content as formatted HTML or plain text with embedded images resolved as URLs. Jira Issues have a Description field but not a native document store. For project documentation that exceeds the Issue Description length or needs cross-reference structure, we recommend creating Confluence pages in the associated Jira project space post-migration. Nifty Docs without a clear Jira home are flagged as scope decisions before migration.

Nifty time tracking entries (duration, date, user attribution) map to Jira Worklog on the corresponding Issue. We extract time via GET /operation/timelogs and link each entry to the migrated Task or Subtask by Nifty task ID. Jira requires the Worklog user to be an active Jira user; if the Nifty user does not have a Jira account, the worklog is recorded under the migration service account with the original user noted in a custom field.

Nifty file attachments on tasks and discussions are downloaded and re-uploaded to Jira Issues as native Attachments. We extract file URLs and metadata via the Nifty API, download each file, and upload to Jira using the Attachments API. Large media files (over the Jira attachment size limit) are flagged for the customer to store externally and link via URL. File name, upload date, and uploader are preserved.

Nifty Members (Admin, Member, Guest) are exported with email, name, and role. Jira Users are resolved by email match. Guest accounts in Nifty are flagged during discovery because guests cannot be assigned tasks in Nifty; if any task records have Guest assignees, we document these gaps for the customer to resolve before migration. Any Nifty user without a matching Jira account is held in a reconciliation queue for the admin to provision.

Nifty Goals are high-level objectives linking milestones or tasks to a strategic outcome. Jira has no native Goal object. We map Goals to Labels on the relevant Issues (e.g., label: Q4-growth-goal) or to Jira Components with a description capturing the goal metadata. The customer's admin chooses the strategy during scoping based on how they track objectives in Jira.

Nifty if/then automation rules are not exposed through the public API and cannot be extracted programmatically. We do not migrate automations as code. During scoping, we ask the customer to walk through their automation rules and we document each rule's trigger, conditions, and actions in a written inventory. That document is delivered alongside the data migration for the customer's admin to rebuild using Jira Automation for Jira (available on Standard and Premium plans) or Jira Workflow with validators and post-functions (available on all plans).