Migrate from Avaza to Jira

Avaza Projects map directly to Jira Projects as the top-level container. Each Avaza Project name becomes the Jira Project name, and the Project Key (the prefix used for issue keys, e.g., PROJ) is derived from the first 2-3 characters of the Avaza Project name in uppercase. Avaza Project status (Active / Archived) maps to Jira Project state; Archived projects are migrated as Jira Projects with the Archived workflow state. Avaza Project billing method and budget fields have no Jira equivalent; we document these as reference fields in the project description or a linked Confluence page for admin review.

Avaza Sections (grouping containers inside a Project that organize Tasks) map to Jira Epic Issues within the corresponding Jira Project. The Avaza Section name becomes the Epic Summary, and the Epic Key is auto-generated from the parent Jira Project Key. If the Avaza account uses Sections to represent phase-level groupings (e.g., Discovery, Development, QA), these translate naturally to Jira Epics that can contain Stories and Tasks. Sections without any child Tasks are still migrated as Epics with zero issues to preserve the organizational structure visible in Avaza.

Avaza Tasks map to Jira Issues with the following type mapping convention: Tasks with a flat-rate amount and no assignee dependency become Jira Tasks; Tasks representing deliverables that belong to a sprint become Jira Stories; Tasks logged as bug or defect indicators in Avaza become Jira Bugs. Avaza task assignees map to Jira Assignee (resolved by email match against Jira User directory); unassigned Avaza tasks remain unassigned in Jira. Due dates, priorities, and task status map directly. Avaza task descriptions migrate as Jira Issue descriptions in plain-text format.

Avaza Timesheets have no native Jira equivalent because Jira does not have a timesheet object. We extract Avaza timesheet records as a structured CSV reference file (Project, Section, Task, User, Date, Hours, Billable Rate, Cost Rate, Category) and attach it as a pinned file to the corresponding Jira Project. Historical timesheet hours can also be logged as Jira Issue Work Logs at the task level, but this requires Jira Premium and is a manual post-migration step that we document in the Statement of Work. The frozen Billable Rate and Cost Rate values stored in each Avaza timesheet at entry time are preserved in the CSV reference file.

Avaza Expenses have no native Jira equivalent. We extract expenses as a structured CSV (Project, Task, User, Date, Amount, Currency, Category, Billable flag, Receipt URL) and attach it to the corresponding Jira Project as a pinned file. The Billable flag from Avaza is preserved as a Yes/No column in the CSV for downstream billing reconstruction. Receipt attachment URLs from Avaza are preserved in the CSV where they are reachable; files without a reachable URL are flagged in the reconciliation report.

Avaza Invoices have no Jira equivalent and cannot be migrated. Jira is a work-tracking platform with no invoicing, billing, or accounts-receivable model. We extract the full Invoice Detail report from Avaza as a structured CSV (Invoice ID, Customer, Date, Line Items, Amount, Status, Payment Terms) and deliver it alongside the migration for the customer's finance team to import into a billing tool of their choice (Stripe, QuickBooks, FreshBooks, or a custom ERP). The Avaza Invoice-to-Project linkage is preserved in the CSV so that invoiced amounts can be traced back to migrated Jira Projects.

Avaza Quotes and Estimates are distinct from Projects and have approval statuses and client-view links that have no Jira equivalent. Jira does not have a Quote or Estimate object. We extract the Quote Detail report from Avaza as a structured CSV (Quote ID, Customer, Date, Line Items, Amount, Approval Status) and deliver it separately. The customer's sales or finance team rebuilds quotes in their preferred billing tool. Avaza's one-click quote-to-project conversion is not replicated in Jira; the corresponding Jira Issues are migrated independently without a Quote linkage.

Avaza distinguishes between billable Customers (account-level contacts) and External Contacts and Project Collaborators. Jira's user model is simpler: a Jira User is a person with an Atlassian account who can be assigned to Issues. We map Avaza Customers and External Contacts who are active project assignees to Jira Users by email. Contacts who are billable entities but do not require Jira access (e.g., client billing contacts) are exported as a CSV reference file and not provisioned as Jira Users. The customer's admin confirms the access scope before user provisioning begins.

Avaza Users and Team Members map to Jira Users by email match. Avaza role types (Timesheet/Expense User, Admin/Finance, Project Collaborator, Resource Scheduler, Chat-access Team Member) have no Jira equivalent role model; Jira's permission model is project-scheme-based rather than user-type-based. We map Avaza active users to Jira users with Jira Standard access. Users with inactive Avaza accounts are held in a reconciliation queue for the admin to confirm whether they need Jira access. Jira Cloud Free tier is limited to 10 users; migrations exceeding 10 users require the customer to select a Jira Standard or higher plan before user provisioning.

Avaza Timesheet Categories define work types (e.g., Development, Design, Meetings, Admin) and carry default Billable and Cost Rates that cascade into timesheet entries. Jira has no native category or rate concept. We offer two options: (1) migrate category names as Jira Labels on Issues for work-type classification, or (2) create a Jira Project per category with the rate information stored in the project description. The customer selects the preferred strategy during scoping. The Billable and Cost Rate values per category are preserved in the Timesheet reference CSV delivered alongside the migration.

File attachments on Avaza Tasks, Expenses, and Invoices migrate as Jira Issue Attachments. We re-attach files where the Avaza export includes the blob or a reachable URL. Files without a reachable URL (attachments stored in Avaza's internal file layer without an exportable link) are flagged in the reconciliation report and documented for manual re-upload. Jira's attachment file size limit is 75 MB per file on Cloud plans; Avaza attachments exceeding this limit are flagged and excluded from the automated migration.

Avaza Project and Task custom fields are migrated to Jira Issue-level custom fields on the corresponding Issue Types. Avaza custom fields appear only in filtered report views, which means we must request a custom-field report export with the correct filter context applied. Jira custom field types (Text, Number, Date, Select, Multi-select, Checkbox, User Picker) are mapped from Avaza field types; fields without a direct Jira type equivalent (e.g., currency-specific rate fields) are migrated as Text fields with the original value preserved. Jira custom fields must be created in the target Jira Project before migration begins; we handle this via the Jira REST API as part of the pre-migration schema setup.