Migrate from QuickStart Admin to Jira

QuickStart Admin Projects map to Jira Projects as the top-level container. We infer Projects as the highest-level organizational unit based on QuickStart Admin's G2 PM software placement, but without a confirmed data model we validate this during pre-flight audit by querying the customer's live instance for unique project records. Jira Project key (e.g., PROJ) is generated from the source project name, and the project name maps directly to the Jira Project name field.

QuickStart Admin Tasks map to Jira Issues. We configure the Jira Issue Type Scheme before migration to include the types the customer uses in QuickStart Admin (Task, Story, Bug, Epic depending on what the pre-flight audit reveals). The source task title maps to Jira Summary, task status maps to Jira Status through a status mapping table, and task description (if rich text) migrates as Jira Description with formatting simplified to Jira-supported markup.

QuickStart Admin Subtasks map to Jira Sub-task Issue Type linked to a parent Issue. We probe for parent-child task relationships during the pre-flight audit. If QuickStart Admin stores subtasks as a flat list with a parent reference field, we reconstruct the hierarchy at migration time by setting the Jira parent Issue key on each Sub-task record. If Jira's Sub-task Issue Type is not enabled in the destination project, we fall back to linked Issues with a 'is sub-task of' Issue Link type.

QuickStart Admin assignee references map to Jira User records by email address match. We extract every distinct assignee value from the source task records and cross-reference against the Jira destination site's user directory. Any assignee without a matching Jira User goes to an orphan queue for the customer's admin to provision before the record import phase. Jira plan matters here: Jira Cloud Free is capped at 10 users, so migration may trigger an upgrade requirement to Standard if the QuickStart Admin instance has more than 10 active assignees.

QuickStart Admin custom fields (inferred from PM tool conventions) map to Jira custom fields. Without a published schema, we probe the customer's instance during pre-flight audit to enumerate actual custom field names, data types, and picklist values. We create typed Jira custom fields (text, number, date, picker, multi-select) in the destination project before migration and map source values during the transform pass. Jira Cloud Standard and Premium allow up to 200 and 900 custom fields respectively; we verify the count against the destination plan.

QuickStart Admin task-level comments map to Jira Issue Comments. Each Comment record includes author (resolved via email to Jira User), comment body text, and timestamp. Rich-text formatting from QuickStart Admin is simplified to plain text or Jira-compatible wiki markup during transform. Comment ordering in Jira is preserved by setting created to the original QuickStart Admin timestamp. If QuickStart Admin stores threaded comments, we flatten to a flat comment list in Jira.

File attachments on QuickStart Admin tasks cannot be guaranteed without a confirmed export mechanism. We probe for this during pre-flight audit by attempting a file export or checking whether an API endpoint returns binary data. If no export path exists, we document the limitation and recommend the customer manually download attachments per task before migration, then re-upload post-import to Jira. If an export path is confirmed, we migrate attachments via Jira's Attachment API with the 10 MB per-file limit enforced.

QuickStart Admin user accounts required for assignee resolution map to Jira Users by email. We extract the user directory (name, email, role) from QuickStart Admin during pre-flight audit. Inactive users in QuickStart Admin who still have assigned tasks are migrated as Jira inactive users so that the Owner field does not resolve to null. Jira Cloud Free user limit (10) is verified against the total user count during scoping; Standard plan is recommended if the source has more than 10 active users.

QuickStart Admin task status values map to Jira Status values through a configuration table we build during pre-flight audit. Since QuickStart Admin's status values are not publicly documented, we enumerate them from the customer's live instance and map each to an appropriate Jira Status category (To Do, In Progress, Done). We create custom Status values in Jira if the standard set does not cover the source statuses.

If QuickStart Admin has a priority or severity field on tasks, it maps to Jira Priority. Jira's standard Priority values (Highest, High, Medium, Low, Lowest) are used unless the customer has configured custom Priority values. We include a custom priority score field on the Jira Issue if the source priority scale is finer-grained than Jira's five-level model.