Migrate from actiTIME to Jira

actiTIME Customers map to Jira Projects as the top-level organizational unit. The actiTIME customer name becomes the Jira Project name, and customer description becomes the Jira Project description. If the Customer contains archived projects, we skip those unless the customer requests inclusion. Jira's project category can be used to group multiple migrated Customers if the Jira instance serves multiple business units under one site.

actiTIME Projects map to Jira Projects when the source hierarchy has no Customer above them, or to Jira sub-projects when they belong to a Customer that maps to a parent Jira Project. Jira sub-projects share a JQL filter or Project Category with the parent for cross-project reporting. We check the /info endpoint's taskWorkflow and taskEstimates flags to confirm Projects have the expected task structure before migration.

actiTIME Tasks map to Jira Issues. The mapping uses Issue Type to distinguish task types: Tasks with no sub-tasks become Jira Tasks or Stories; Tasks with sub-tasks become Jira Epics with child Stories. The actiTIME task status (workflow-controlled) maps to a Jira Status, and the actiTIME deadline becomes the Jira Due Date. Custom field values on actiTIME Tasks (if any exist) map to Jira custom fields, which we pre-create in the destination project before migration.

actiTIME time-track records map to Jira Issue worklogs. Time-tracking must be enabled in the destination Jira project before migration. We map hours, date, billability flag, type of work, and comments to Jira worklog fields. The actiTIME user (by email) resolves to the Jira User account. Locked timesheet entries from actiTIME (timesheet lock status) have no Jira equivalent; we restore them as standard worklogs and document the loss of lock status in the migration report. Jira stores worklogs against Issues rather than as standalone records, so we resolve the parent Issue reference before inserting.

actiTIME Users map to Jira Users by email address. We export the full user roster including first/last name, email, active/inactive status, and timezone group assignment. Active actiTIME users must have a Jira account provisioned before migration; inactive users migrate as inactive Jira users or are excluded per the customer's scoping decision. We flag any actiTIME user referenced in time-track entries who has no Jira account for admin provisioning.

actiTIME Departments are a feature-gated object controlled by the Departments flag in the /info endpoint. Not all instances have this enabled. Where departments exist, we export the department roster and user assignments. Jira does not have a native department object; we map departments to Jira Project Roles (if the department structure maps cleanly to project-level roles) or to a multi-select Label field on Issues. The customer chooses the strategy during scoping.

actiTIME Time Zone Groups group users by timezone for reporting. Jira stores timezone at the user account level (Jira user profile). We export the TZG roster and user assignments, then set the timezone on each migrated Jira User account. Jira's reporting tools respect user timezone settings for date grouping.

actiTIME Types of Work (e.g., Development, Meeting, Research) categorise time-track entries. Jira has no native type-of-work taxonomy on worklogs. We export the type-of-work taxonomy and map it either to a Jira custom field on Issues (Work Type: single-select picklist) or to Jira Issue Types if the customer wants work type reflected at the issue level. The choice is made during scoping based on reporting requirements.

actiTIME Workflow Statuses are a feature-gated capability (taskWorkflow flag). Custom workflow stages vary by instance. We export the current status definitions and apply them to Jira Statuses in the destination project. Jira statuses are defined per project (or shared via Statuses.com shared configuration), so we create matching status values in the destination project. Note: this migrates the status vocabulary, not the workflow automation rules; Jira Automation rules must be rebuilt by the admin post-migration.

actiTIME Leave Time is controlled by the leavetimeRegistration feature flag and may not exist on all instances. Jira has no leave-time, PTO, or absence tracking object in standard Jira Software. We export leave-time records for audit and reconciliation purposes, then map them to a CSV export and Jira custom field(s) if the customer wants historical leave data accessible within Jira. Alternatively, we recommend the customer implement a dedicated HR tool (BambooHR, Rippling, or a Jira Marketplace app like Time Off Tracker) post-migration. The leave-time data is preserved in the migration report even if it cannot be placed inside Jira natively.

actiTIME Task Estimates (planned hours per task) are an optional feature controlled by the taskEstimates flag. Where enabled, we map these to Jira Story Points (if the destination project uses story point estimation) or to the Jira Original Estimate field (if the project uses time-based estimation). The mapping choice is made during scoping based on the customer's existing Jira estimation practice.

actiTIME Users with inactive status map to deactivated Jira Users. Deactivated Jira users retain historical associations (worklog author, issue assignee) even after deactivation, preserving audit trails for migrated time-track data. We do not delete or skip inactive users from migration; their records are preserved to maintain data integrity in the historical worklog history.