Migrate from AceProject to Jira

AceProject Projects map directly to Jira Projects. We export project metadata (name, description, status, start date, end date) via the admin Export Data tool. In Jira, we pre-create the destination Project with the appropriate Project Type (Software for engineering teams, Business for operations teams) and set the Default Scheme to match the imported issue types. If AceProject uses custom project-level fields, we map these to Jira Project Properties or custom fields scoped to the project.

AceProject Tasks are the core work unit and map to Jira Issues (Story, Task, or Bug depending on the type discriminator in the export). The AceProject task Name becomes Jira Summary, Description maps to Description, Estimated Hours maps to the Jira custom field Original Estimate (or the native Time Tracking estimate field if enabled), and Assignee resolves via User email lookup. Task status (New, In Progress, Closed) maps to Jira Status (To Do, In Progress, Done) with workflow transitions configured before migration.

AceProject Subtasks nest under Tasks and map to Jira Sub-task issue type. We flatten the parent-child relationship during export and reconstruct it in Jira by resolving the parent Issue key at migration time. Jira Sub-tasks inherit the parent Project context and can have their own Assignee, Status, and due date. The AceProject subtask name becomes the Jira Summary, and the parent Task reference becomes the Jira Parent Link.

AceProject Users map to Jira Users. We export all User records including custom User fields. AceProject does not auto-assign imported users to the destination Project, so we flag every User referenced in tasks and generate a Jira project membership add-list for the customer's admin to provision before or after migration. Custom User fields from AceProject map to Jira User Properties or custom fields on the User entity.

AceProject Time Entries (hours, date, billing rate, task association) map to Jira Issue Worklog records. We resolve the parent Issue reference by matching AceProject task ID to the Jira Issue key assigned during the Task-to-Issue migration phase. Hours map to Time Spent, date maps to Started, and billing rate from AceProject is stored in a custom worklog field. If Jira Time Tracking is not enabled in the destination, we create a custom Worklog custom field to hold billable hours data.

AceProject Expenses have no native Jira equivalent. We handle this through a two-track approach: for teams with Jira Service Management or a companion financial tool, we map Expenses to a custom Issue type or linked records. For teams using Jira Software alone, we create custom fields on the relevant Issue type (Expense Amount, Expense Category, Expense Date, Expense Currency) and flag this as a configuration item in the handoff document. We also flag that normal AceProject users without the 'Can see expense data no matter what' role may have restricted expense visibility — we run export under an administrator account to capture all expense records.

AceProject Documents (file metadata and commenting) map to Jira Issue Attachments. We export document metadata (filename, upload date, associated project or task) and generate a file reference list. Actual file content transfer depends on whether the files are accessible via URL or require separate download-and-upload. Jira's Attachment API accepts files up to 64MB per attachment. Comment threads from document commenting are flattened into Jira Issue comments with author attribution preserved.

AceProject Task Dependencies (dependency type and linked Task ID) map to Jira Issue Links. We export the dependency type (Finish-to-Start, Start-to-Start, or custom) and the referenced Task ID, then resolve the target Issue key during migration. Jira Issue Link types (Blocks, Is Blocked By, Relates To) are configured in the destination before migration. Finish-to-Start dependencies map to Blocks; other dependency types map to Relates To with a custom link type note.

AceProject Task Custom Fields (Boolean, Date, List, Numeric, Text, User types) map to Jira Custom Fields. We detect the AceProject interface version during scoping — if the account uses the classic interface, custom field values may not be exported completely, and we recommend switching to the new interface before export. Custom field context in Jira (which projects and issue types a custom field applies to) is configured before migration. We map Boolean to Jira Checkbox, Date to Jira Date Picker, Numeric to Jira Number Field, and List to Jira Select or Radio Button.

AceProject User-level custom fields export as key-value pairs per user. These map to Jira User Properties if the values are system-level, or to custom fields on a dedicated User configuration object if the destination Jira instance supports it. Many Jira configurations store user-level metadata as project membership attributes or Issue-level custom fields referencing the Assignee rather than as native user properties.

AceProject document and task comments migrate to Jira Issue Comments. Threaded comment structures are flattened during migration — each comment becomes a standalone Jira comment with author and timestamp preserved. The chronological order of comments is maintained by setting the Jira comment creation date to the original AceProject timestamp. Nested replies are appended as separate comments with a prefix referencing the parent thread.