Migrate from TimeLog to Jira

TimeLog Projects map directly to Jira Projects. Each Jira Project is created with the same name, description, start date, and end date as the TimeLog Project. The Jira Project key is derived from the TimeLog project code or a customer-provided prefix. Project status (Active, On Hold, Closed) maps to Jira Project archived state; we preserve the original TimeLog status as a custom field for reporting continuity.

TimeLog Activities map to Jira Issues using the following rules: Activities with a planned scope and deliverables become Jira Stories; Activities that represent discrete one-off work items become Tasks; Activities flagged as bugs in a custom field become Jira Bug issue types. Each Jira Issue is created under the Jira Project that corresponds to its parent TimeLog Project, preserving the Project-Activity hierarchy. Activity billing method (fixed-price, time-and-material) is stored in a custom Issue field for any downstream billing tool integration.

TimeLog Time Entries migrate to Jira Issue Worklogs. Each Worklog records the date, duration (in hours), billable/non-billable flag, and description from the TimeLog entry, linked to the Jira User corresponding to the TimeLog Employee and the Jira Issue corresponding to the TimeLog Activity. Activity timestamp ordering is preserved. We use the Jira Bulk API with chunking and exponential backoff to handle large time entry volumes. Billable hours are summed in a custom field for billing tool intake if a third-party invoicing add-on is deployed post-migration.

TimeLog Employees map to Jira Users by email address as the dedupe key. We resolve each Employee's department, role, and billing rate from TimeLog and store these as Jira User profile fields or custom fields for resource reporting. Inactive TimeLog Employees without corresponding Jira Users are held in a reconciliation queue for the customer's admin to provision or deactivate.

TimeLog Customers present a tier-dependent mapping decision. In Jira Free and Standard, there is no native Organization object, so Customers map to Jira Project-level labels or a custom field on Issues. In Jira Premium and Enterprise with Jira Product Discovery or Data Center with Organization add-ons, Customers map to Jira Organizations. We confirm the customer's Jira edition and preferred mapping during scoping. Customer currency and billing address are stored as custom fields if the customer intends to connect a billing add-on post-migration.

TimeLog Invoices have no direct Jira equivalent. Jira Software does not include invoicing or billing. We extract Invoice headers, line items, amounts, and payment status from TimeLog and deliver them as a structured CSV and JSON export for import into a billing tool such as Jira Tempo Financials, a third-party ERP, or a standalone accounting platform. Invoice-to-Activity associations are preserved in the export so that billing records can be reconciled against migrated time entries.

TimeLog Expenses (non-labor costs logged against Projects and Activities) have no native Jira equivalent. We export Expenses as a structured record set including amount, date, category, billable flag, and associated Activity. The customer provisions a third-party expense tracking add-on or standalone tool post-migration and imports the Expense export. Expense-to-Activity associations are preserved in the export for reconciliation.

TimeLog maintains employee rates, Activity rates, and customer-specific pricing. Rate structures do not map to any native Jira field. We export the complete rate table (Employee, Activity type, Customer tier, hourly rate, fixed rate) as a structured JSON file. The customer's admin uses this to configure a billing add-on (Tempo, Jira Financials, or third-party) with the correct rate cards post-migration.

TimeLog Resource Allocations (employee hours or percentage assignments to Projects) have no native Jira equivalent. We export allocation records with Employee, Project, percentage, and effective date. For Jira environments with the Structure or BigPicture add-on, allocations map to those tools' allocation fields. For Jira without an allocation add-on, we deliver the allocation data as a CSV for manual entry or a custom script to populate custom Issue fields.

TimeLog custom fields on Projects and Activities require field-level discovery during scoping because they are not always included in standard API exports. We query extended field definitions from TimeLog, map each to the closest Jira custom field type (text, number, date, select, multiselect, URL), and flag any schema mismatches for post-migration validation. Jira enforces custom field context rules (custom fields are scoped to specific issue types and projects), which we configure in the destination schema before import.