Migrate from BigTime to Jira

BigTime Projects map to Jira Projects as the top-level organizing entity. Project name, status (Active/Archived), start and finish dates, budget amounts, and client assignment all transfer. We map BigTime's Active/Archived status to Jira Project's archived flag and preserve the client assignment in the Jira Project description or a custom Project field. Jira Project Key (the prefix for issue numbers) is auto-generated or customer-specified during provisioning. Note: Jira has no native billing or WIP fields on Projects—budget and financial fields are migrated as custom number fields.

BigTime Clients map to Jira Organizations (available on Jira Premium and Standard). Client name, primary contact, phone, email, billing address, and payment terms transfer as Organization fields. Jira Organizations support linking to multiple Projects, which mirrors BigTime's ability to assign a Client to multiple Projects. Where the destination Jira plan does not include Organizations, we embed client contact details in a custom field on the linked Project.

BigTime Tasks at the parent level can map to Jira Epic or Jira Story depending on the customer's intended agile structure. During scoping, we determine whether the BigTime project uses a flat task list or a hierarchical WBS. If the customer plans to use Jira Scrum, parent tasks become Epics and child tasks become Stories. If they use Jira Kanban, all tasks become Issues in a single board. BigTime's task-level budget allocation maps to Jira Story points or a custom field.

BigTime child Tasks map to Jira Stories, Tasks, or Subtasks based on the target project template selected during scoping. Because BigTime enforces only two hierarchy levels, every BigTime task that has a parent is a direct child with no further nesting. Jira supports unlimited nesting, but the source data has no depth to preserve. We flag any tasks with no parent for review—they may be orphaned records that should attach to a project-level Epic.

BigTime Staff records (name, email, role, department, billable rate, cost rate) map to Jira User accounts. We match by email as the dedupe key. Any BigTime Staff record without a matching Jira User goes to a reconciliation queue for the customer's Jira admin to provision before record migration. Billable rate and cost rate are stored as custom number fields on the Jira User profile since Jira has no native labor rate concept.

BigTime Time Entries (project, task, staff, date, hours, billable/non-billable flag) migrate as Jira Worklog entries linked to the corresponding Jira Issue. The billable/non-billable flag transfers as a custom Jira field since worklogs have no native billing-status attribute. We set Worklog started and time spent directly from the BigTime time entry timestamp and duration. Already-invoiced time entries are flagged with a custom status field indicating they were billed in BigTime.

BigTime Expense records (project association, expense code, amount, date, vendor, receipt reference) migrate as Jira Issue attachments (receipt metadata) and Jira Labels (expense code mapping). The expense amount and vendor transfer as custom fields on the Jira Issue. Expense codes from BigTime become Jira Labels so teams can filter and report on expense categories across projects. Receipt files migrate as Jira attachments on the linked Issue.

BigTime staff assignments to projects with scheduled hours map to Jira Components (team-level) or Assignee fields on Issues. Where BigTime uses role-based scheduling (assigning a role like 'Developer' to a project), we map to Jira Component with a role label, and the customer's admin assigns specific users to the Component after migration. We do not map BigTime capacity planning to Jira Sprint capacity without additional scoping for sprint-based resource management.

BigTime Project Custom Fields (text, dropdown, checkbox, monetary, URL) migrate to Jira Custom Fields of equivalent type. We pre-create the Jira custom field schema before migration, including context assignment to the relevant Jira Project and Issue Type. Jira Cloud enforces required-field constraints that may differ from BigTime's custom field validation—we flag any null values in required Jira fields for manual resolution before migration.

BigTime's Scheduled vs. Actual report captures planned hours, cost, and revenue against tracked values. We migrate these as a linked dataset: the planned values become Jira Project-level custom number fields (budget_hours, budget_cost, budget_revenue), and the actual values come from migrated time entries and expenses. Variance calculations are stored as computed custom fields or delivered as a CSV companion file. Jira has no native budget tracking—these fields require a Jira reporting app or BI tool for variance dashboards.

Sent and paid invoices in BigTime cannot migrate to Jira because Jira has no invoice, billing, or accounts receivable object. We export all sent and paid invoice records (invoice number, client, date, line items, amounts, status) as a structured CSV and JSON data package with a field mapping to any destination billing tool the customer selects post-migration. The customer or their accounting team performs the final import into QuickBooks, FreshBooks, or another billing platform.

Unsent invoice drafts in BigTime carry a risk of premature billing if imported as open records in a new system. We tag all migrated draft invoices with a source-status flag (draft) in the data map, set the status as Closed on any temporary staging import, and explicitly note in the handoff document that these records require billing-cycle confirmation before activation in any replacement tool.