Migrate from Birdview to Jira

Birdview Spaces are the top-level organizational container and map directly to Jira Projects as the first-class destination equivalent. We preserve Space metadata (description, dates, status) in the Jira Project description and use Space hierarchy as the basis for Jira Project nesting or a Jira folder structure if the customer uses Jira Products (Jira Software + Jira Work Management in a shared org). Space-level custom fields map to Jira Project properties or a Jira custom field scoped to all Issue types within that Project.

Birdview Projects carry status, dates, budget, and owner assignment. They map to Jira Projects or Jira Components within a Project depending on the customer's hierarchy preference. The Birdview Project status (Active, On Hold, Completed) maps to Jira Project status or a Jira Project archived flag. Budget and date fields migrate to Jira Project description text or custom Jira Project-level fields if the Premium or Enterprise tier is in use.

Birdview Activities of type Task map to Jira Task or Story depending on whether the customer uses Jira Software's backlog hierarchy. We preserve the Activity type label (Task) as a custom Jira field bv_activity_type__c so that the team retains the original Birdview classification. Assignee, due date, priority, and status map directly. Description migrates as Jira Issue description in At markup or plain text depending on richness.

Birdview Issues are Activity subtypes distinguished by priority and resolution fields. They map to Jira Bug (preferred) or Jira Task depending on the customer's Issue type scheme configuration. Issue-specific priority levels and resolution values migrate to Jira Priority and Resolution fields. We preserve the Birdview Issue resolution as a custom field bv_resolution__c for audit trail.

Birdview Requests are intake-style Activities tied to custom forms with tenant-defined schema. Request form data requires field-by-field mapping because the form definition is Birdview-specific. We extract the form schema first during discovery, enumerate every custom field on the Request form, then map each to a Jira custom field. If the destination Jira instance uses the Jira Service Management Request Type model, Requests can map to Jira Service Management request types instead of Jira Software Issue types.

Birdview Portfolios group Projects for executive oversight. On Jira Software with Premium or Enterprise, Jira Advanced Roadmaps (formerly Structure) provides portfolio-level grouping. We map Portfolio membership to Jira Epic links or to a Jira folder/Project grouping structure depending on the customer's Jira tier. If the customer is on Jira Standard, Portfolio membership migrates as a custom multi-select field and the grouping is handled through Jira Labels or a manual Project structure.

Birdview Time entries link to Activities and Users. They map to Jira Worklogs on the migrated Jira Issue. Jira worklogs accept fractional hours without a minimum floor (unlike Birdview's 0:01 hour enforcement). We flag every Birdview time entry that has zero hours in the source — these will create Jira worklogs with zero duration unless the customer elects to skip zero-value entries. Non-zero entries migrate with the original duration, date, and billing note preserved in the Jira Worklog comment field or a custom worklog field.

Birdview Expenses are tied to Activities and Projects with cost center and approval status. Jira has no native expense object. We export expenses as a structured dataset and either create a Jira custom object (Jira Platform tier) to hold expense records linked to Jira Issues, or document the expense data in a CSV handoff for the customer to import into a third-party expense app (Expensify, Certify, etc.) post-migration. Approval status does not migrate as an automated workflow; we document the approval chain for the customer's admin to rebuild in Jira if needed.

Birdview Rate Cards define billing rates per user or role and apply to time tracking and project budgeting. Jira has no native rate card object. We export rate card definitions as a structured mapping table and either create Jira custom fields to hold rate values per project, or document the rate card schema in a CSV handoff. Role-based rate cards require user-to-role mapping that the customer provides during scoping.

Birdview custom fields are tenant-defined on Projects and Activities and require pre-migration enumeration during discovery. We extract all custom field definitions (name, type, applies-to object) before mapping begins. Each Birdview custom field type maps to the equivalent Jira custom field type: text fields to Jira Text Field, dates to Jira Date Picker, dropdowns to Jira Select List, multi-select to Jira Labels or Multi-select. Jira custom field context restrictions must be configured per Issue type in Jira before import; we document this as a configuration step in the migration runbook.

Birdview Full User, Collaborator, Executive, and Viewer roles gate access to financial data, rate cards, and administrative functions. Jira project roles (Admin, Member, Viewer, Contributor) govern access per project. We map the Birdview user type to the nearest Jira project role, noting that Collaborator access to financial data (hidden in Birdview) has no direct Jira analog — the customer must decide whether financial context is managed outside Jira or through a Jira custom field visibility model post-migration.