Migrate from Birdview to Asana

Birdview Spaces are top-level organizational containers that may contain Projects and nested sub-Spaces. We map each Space to an Asana Team within the destination Organization. If the Birdview tenant has more than 500 projects under a single Space, we split the Space into multiple Asana Teams using the first-level Project grouping as the Team boundary. Space hierarchy (parent-child) is preserved as Team naming conventions or in a custom field space_parent__c for audit.

Birdview Projects map directly to Asana Projects with status, start date, due date, owner (mapped to Asana Team member), and description preserved. Project budget fields in Birdview do not have a native Asana equivalent; we migrate budget as a custom number field project_budget__c and flag it as requiring manual entry if the destination Asana plan lacks the Budgets add-on (Premium and Business only).

Birdview Activities with type Task map to Asana Tasks. We preserve the Activity type label as a custom single-select field activity_type__c set to 'Task' during migration. All standard task fields (assignee, due date, priority, description) map directly. Subtasks in Birdview map to Asana Subtasks via the parent_task_gid reference. Task completion status maps to the Asana completed field.

Birdview Issues are Activity subtypes with priority, resolution status, and resolution notes fields. There is no native Issue object in Asana. We migrate Issues as Tasks, preserving the issue-specific fields as custom fields: issue_priority__c, issue_resolution_status__c, and issue_resolution_notes__c. The activity_type__c custom field is set to 'Issue' to maintain classification in the destination.

Birdview Requests are intake-style Activities tied to Custom Forms with tenant-defined field schemas. We extract the form definition during scoping before mapping any Request records. Each Request migrates as a Task with the custom form field values mapped one-by-one to custom fields in Asana. We flag any form field types that Asana does not support (e.g., file upload fields) as skipped fields with a note in the migration manifest.

Birdview Portfolios group Projects for executive oversight and are Enterprise-tier only. Asana does not have a native Portfolio object below Enterprise. We migrate Portfolio membership as a custom field portfolio_name__c on Projects and recommend the customer use Asana Portfolios on Business or Enterprise tier if available. If the customer is on Asana Starter or Premium, we document the Portfolio-to-Project groupings for manual rebuild in Asana's search and filter layer.

Birdview time entries are linked to Activities and Users with the 0:01 hour minimum enforced. We extract all time entry records including those below the 0:01 floor as a separate data set. We present the customer with three options: migrate zero-value entries as 0.01-hour entries in Asana Premium time tracking, drop zero-value entries entirely, or deliver time entry data as a structured CSV for billing reconciliation outside Asana. We do not create a shadow billing system inside Asana; time entry migration is a customer choice documented in the scoping sign-off.

Birdview Expenses are tied to Activities and Projects with cost center and approval status. Asana has no native expense object. We extract all expense records and deliver them as a structured CSV with project reference, cost center, amount, currency, approval status, and expense date. For teams that need expense tracking inside Asana, we recommend a third-party integration (expense management tool or custom build) and document the recommended configuration as part of the post-migration handoff.

Birdview custom fields are tenant-defined on Projects, Tasks, and Activities. We enumerate every custom field definition during discovery, map field types to Asana-supported types (text, number, date, dropdown, multi-select, checkbox, people), and flag unsupported types (e.g., formula fields, rollup fields) as skipped with a field-level note. Dropdown and multi-select option lists migrate with values preserved; we extend the options list if Asana already has conflicting values in the same field.

Birdview Full User, Collaborator, Executive, and Viewer roles govern data visibility. We map these to Asana Team membership by resolving each Birdview user email to an Asana user. Collaborators who cannot access financial data in Birdview are migrated as Asana Members on the relevant Teams; their access scope is scoped to the non-financial projects during migration. We flag any role that cannot be represented in Asana's permission model as an access gap in the migration report.

Birdview custom Workflows govern task routing and approval chains. Asana Rules (trigger-action) and Workflow Builder (Business tier) are different automation paradigms from Birdview's visual workflow configuration. We do not migrate Workflows as code. We audit every active Birdview Workflow, document its trigger conditions, routing logic, and actions in a written inventory, and deliver it to the customer's admin for rebuild in Asana Rules or Workflow Builder. We test the inventory against Asana's rule action coverage and flag any Birdview workflow actions that have no Asana equivalent.

Birdview Rate Cards define billing rates per user or role. Asana has no native rate card object. We extract rate card definitions (role, rate, currency, effective dates) and deliver them as a structured CSV alongside the time entry export. If the customer uses Asana for billing rate visibility, we recommend building a rate card reference inside Asana as a custom Project or as a document in the customer's connected Google Drive or SharePoint, documented in the handoff report.