Project Management migration
Field-level mapping, validation, and rollback between BigTime and Asana. We move data and schema; workflows are rebuilt natively in Asana.
BigTime
Source
Asana
Destination
Compatibility
10 of 12
objects map 1:1 between BigTime and Asana.
Complexity
BStandard
Timeline
2-3 weeks
Overview
Moving from BigTime to Asana is a platform shift from a professional services automation (PSA) system purpose-built for billing and resource management to a work management tool centered on task tracking and team collaboration. BigTime organizes work around Projects, Clients, and Time Entries with invoice generation and expense coding; Asana uses Workspaces, Teams, Projects, and Tasks with no native billing or client management module. We map BigTime Projects to Asana Projects, BigTime Team Members to Asana Users, and BigTime Time Entries to Asana Tasks with billable hours stored in custom numeric fields. We flag the absence of Invoice, Expense Code, and Resource Allocation objects in Asana and provide written recommendations for how to handle them post-migration. Workflows, approval chains, invoice templates, and QuickBooks sync configuration do not migrate; we deliver a written inventory for your admin to rebuild in Asana Rules or a connected billing tool.
Every standard and custom field arrives verified.
AI proposes the map; you confirm before any record moves.
Parent–child, lookups, and ownership stay linked.
Calls, emails, meetings — with original timestamps.
Documents, uploads, and inline notes move with the record.
Why teams make this switch
Leaving
What's pushing teams away
Choosing
What's pulling them in
Object mapping
Each row shows how a BigTime object lands in Asana, including any object-level transformations, lookup resolution, or schema-design dependencies.
Typical mapping — final map is confirmed during the sample migration step.
BigTime
Project
Asana
Project
1:1BigTime Projects map directly to Asana Projects. All standard fields (Project name, status, start/end dates, budget, client assignment) migrate. Active and Archived status from BigTime maps to Asana's Archived project state. Custom Fields on Projects in BigTime migrate as Asana custom fields on the Project, preserving field labels and all populated values. Asana's Project is the central organizing entity on both platforms, making this the most straightforward 1:1 mapping.
BigTime
Team Member
Asana
User
1:1BigTime Staff records (name, email, role, department, billable rate, cost rate) map to Asana Users. We match by email address for deduplication. BigTime role-based permissions (Admin, Manager, Staff) do not map directly to Asana's Member and Guest roles; we document the original BigTime role in a custom text field on the Asana User profile for reference. Active staff in BigTime become active Asana Users; archived staff are imported as inactive Users at the customer's discretion.
BigTime
Client
Asana
Project (labeling convention) or custom field
lossyBigTime Clients (the billing entity with contact details, billing address, and payment terms) have no native equivalent in Asana because Asana is not a CRM. We discuss three options during scoping: (1) represent each Client as an Asana Team with the client name, (2) store Client name and contact details in Project-level custom fields, or (3) use an external CRM alongside Asana for client management. The customer chooses the convention, and we apply it consistently across all migrated Projects.
BigTime
Time Entry
Asana
Task (with custom fields)
1:1BigTime Time Entries (project association, staff member, date, hours, billable/non-billable flag, task-level detail) map to Asana Tasks with custom numeric fields for hours and billable status. We create Asana custom fields (number type) for Billable Hours and Non-Billable Hours on each Project, and populate them from the corresponding BigTime time entry records. Already-invoiced time entries are flagged with a custom single-select field Invoice Status set to Invoiced to prevent double-billing.
BigTime
Expense
Asana
Task (with custom fields)
1:1BigTime Expense records (project association, expense code, amount, date, vendor, receipt reference) map to Asana Tasks with a custom currency field for Amount, a text field for Vendor, and a text field for Expense Code. Receipt attachment references from BigTime migrate as attachment links on the corresponding Asana Task if the customer has an Asana Premium or Business plan supporting attachments. Expense codes become a custom dropdown field in Asana that the customer populates post-migration.
BigTime
Invoice / Invoice Draft
Asana
Not migratable (flagged for manual rebuild)
1:1BigTime Invoices and Invoice Drafts do not have a native equivalent in Asana. We extract all invoice records (draft, sent, paid, voided) as a structured CSV export during migration, tagging each with its BigTime status and associated time entries and expenses. The CSV is delivered to the customer as a billing handoff document. For customers using QuickBooks alongside BigTime, we recommend migrating invoice records directly into QuickBooks rather than Asana, since Asana has no native invoicing module. Unsent drafts require explicit confirmation from the customer before we close them out, to avoid premature billing.
BigTime
Resource Allocation
Asana
Task Assignee / Workload view (reconstruction required)
1:1BigTime Resource Allocations (staff assignments to projects with scheduled hours and capacity) map to Asana as Task Assignees with estimated hours stored in a custom number field. BigTime's capacity planning and utilization reporting (available on Advanced and Premier tiers) cannot be natively reproduced in Asana without the Timesheets add-on and Workload view on Business tier. We document every BigTime resource allocation as a structured data record in the migration deliverable so the customer's admin can manually assign or rebuild in Asana's Workload view post-migration.
BigTime
Budget vs Actual (Scheduled vs Actual Report)
Asana
Project custom fields (reconstruction)
lossyBigTime's Scheduled vs Actual report captures planned hours, costs, and revenue against tracked values on a per-project basis. We extract these as a linked dataset during migration rather than a native object. On the Asana side, we create custom number fields on each Project for Budgeted Hours and Actual Hours, populated from the BigTime report where available. Actual vs budget variance calculations are documented as a reporting recommendation (Asana Business-tier dashboards or a BI tool connection) rather than migrated as a live report.
BigTime
Custom Field (Project level)
Asana
Custom field (Project)
1:1BigTime Custom Fields on Projects migrate to Asana Project-level custom fields of equivalent type: text, number, currency, checkbox, dropdown, and URL are all supported. We preserve the field label and all populated values; empty values are left blank. Dropdown options in BigTime migrate as Asana dropdown field values. If a BigTime custom field name conflicts with an existing Asana field name in the destination workspace, we append a suffix (e.g., _bt) to differentiate.
BigTime
Attachment
Asana
Attachment
1:1File attachments on BigTime Projects, Expenses, and Time Entries migrate as Asana attachments on the corresponding Task or Project. We preserve filename, file type, file size, and uploader metadata. The attachment content (the actual file blob) is downloaded from BigTime and re-uploaded to Asana via the Asana REST API. Large files exceeding Asana's 100MB per-file limit are flagged and delivered as a downloadable ZIP with a reference link on the Asana record.
BigTime
Tag / Label
Asana
Tag
1:1Tags applied to BigTime Projects or Expenses migrate as Asana Tags (previously Labels) on the corresponding record. Tag metadata migrates as-is. Asana Tags are not hierarchical; if BigTime tags use a hierarchical taxonomy, we flatten them into a comma-separated tag string and flag the flattening for manual reorganization in Asana if the customer requires a nested taxonomy.
BigTime
Workflow / Approval Chain
Asana
Not migratable (inventory delivered for manual rebuild)
1:1BigTime's configurable Workflows and Approval Chains (available on Advanced tier) represent process automation specific to BigTime's PSA model. These do not migrate to Asana because the trigger conditions, action types, and approval routing logic differ fundamentally between platforms. We deliver a written inventory of every active BigTime Workflow and Approval Chain: trigger event, conditions, assigned approvers, and downstream actions. The customer's Asana admin rebuilds these as Asana Rules (automations) or, for complex multi-step approval chains, documents them for implementation via an Asana certified partner.
| BigTime | Asana | Compatibility | |
|---|---|---|---|
| Project | Project1:1 | Fully supported | |
| Team Member | User1:1 | Fully supported | |
| Client | Project (labeling convention) or custom fieldlossy | Fully supported | |
| Time Entry | Task (with custom fields)1:1 | Fully supported | |
| Expense | Task (with custom fields)1:1 | Fully supported | |
| Invoice / Invoice Draft | Not migratable (flagged for manual rebuild)1:1 | Fully supported | |
| Resource Allocation | Task Assignee / Workload view (reconstruction required)1:1 | Fully supported | |
| Budget vs Actual (Scheduled vs Actual Report) | Project custom fields (reconstruction)lossy | Fully supported | |
| Custom Field (Project level) | Custom field (Project)1:1 | Fully supported | |
| Attachment | Attachment1:1 | Fully supported | |
| Tag / Label | Tag1:1 | Fully supported | |
| Workflow / Approval Chain | Not migratable (inventory delivered for manual rebuild)1:1 | Fully supported |
Gotchas + challenges
Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.
BigTime gotchas
No trial period before purchase
Mobile app time entries are unreliable
Task hierarchy limited to two levels
Invoice drafts require explicit closed-status migration
Data Warehouse Delta Sharing is a one-time credential download
Asana gotchas
Automation rules have no export representation
API rate limits cap bulk migration throughput
Portfolios are view-only objects that do not hold data
Custom field enum options cannot be updated via API
Subtasks do not appear in project views by default
Pair-specific challenges
Migration approach
Discovery and scope definition
We audit the source BigTime account across tier (Essentials/Advanced/Premier), active projects, team member count, time entry volume, expense records, invoice drafts, custom fields on Projects, and resource allocation records. We assess which BigTime data is genuinely migratable (Projects, Tasks, Team Members, Time Entries, Expenses, Custom Fields, Attachments) versus what requires a workaround or manual rebuild (Invoices, Budget vs Actual reports, Workflows, Approval Chains, QuickBooks sync configuration). The discovery output is a written migration scope document confirming object counts, a proposed Asana workspace structure (Teams, Projects, custom field schema), and a migration tier recommendation based on record volume.
Asana workspace setup and custom field schema
We configure the destination Asana workspace before any data moves. This includes creating Teams (mapped from BigTime departments or client groupings), provisioning Projects with the same structure as BigTime Projects, and creating custom fields on Projects and Tasks for Billable Hours, Non-Billable Hours, Expense Amount, Vendor, Expense Code, and Budget Hours. We confirm the custom field types match BigTime value types (currency fields for amounts, dropdowns for expense codes, checkboxes for billable flags). We also disable Asana notifications workspace-wide during the migration window to prevent unwanted notifications from bulk task creation.
Sandbox migration and reconciliation
We run a full migration into the customer's Asana workspace using a representative data subset or a dry-run phase if the workspace is empty. The customer reconciles record counts (Projects in, Tasks in, Team Members in, Time Entry custom fields populated), spot-checks 20-30 random records against the BigTime source, and signs off the mapping before production migration begins. Any field type mismatches, missing custom field values, or hierarchy flattening issues surface here. We correct them in the migration script before touching live data.
Team Member and User provisioning
We extract every distinct BigTime Team Member referenced on Projects, Time Entries, and Expenses and match by email address against the Asana workspace's user list. Any BigTime staff member without a matching Asana User goes to a reconciliation queue. The customer's Asana admin provisions missing Users (active or inactive depending on whether the staff member remains active). Migration cannot proceed past task creation because task assignees require a valid Asana User ID. We also document each staff member's original BigTime role (Admin, Manager, Staff) as a custom text field on the Asana User for reference.
Production migration in dependency order
We run production migration in record-dependency order: Team Members (validated against Asana User list), Projects (with status, dates, and client assignment), Tasks (with time entry data mapped to custom fields and assignees resolved), Expenses (as Tasks with custom expense fields), and Attachments (as linked files on the corresponding records). Each phase emits a row-count reconciliation report before the next phase begins. Time entries that were already invoiced in BigTime are flagged with Invoice Status = Invoiced to prevent re-billing.
Cutover, validation, and workflow handoff
We freeze BigTime writes during the cutover window, run a final delta migration of any records modified since the last full export, then set BigTime to read-only or archive the account at the customer's direction. We deliver the migration summary (record counts, any unmigrated or partially migrated records, and the invoice CSV handoff document). We deliver the Workflow and Approval Chain inventory document to the customer's admin team for rebuild in Asana Rules. We offer a one-week hypercare window to resolve any reconciliation issues raised during user acceptance testing. We do not rebuild BigTime Workflows as Asana Rules inside the migration scope; that is a separate engagement or an internal admin task.
Platform deep dives
BigTime
Source
Strengths
Weaknesses
Asana
Destination
Strengths
Weaknesses
Complexity grading
Standard Project Management migration. 2 of 8 objects need a mapping; the rest are 1:1.
Overall complexity
Standard migration
Derived from compatibility, mapping clarity, API constraints, and data volume across BigTime and Asana.
Object compatibility
2 of 8 objects need a mapping; the rest are 1:1.
Field mapping clarity
Field mapping is derived from defaults — final spec confirmed during the sample migration.
Timeline complexity
8-object category — typical timelines run 2–7 days end-to-end.
API constraints
BigTime: Not publicly documented in the help center or public API docs.
Data volume sensitivity
BigTime doesn't expose a bulk API — REST + parallelization used for high-volume runs.
Estimator
Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.
Step 1
Pick a category, then your source and destination platforms.
Category
FAQ
Answers to the questions buyers ask most during BigTime to Asana migration scoping. Not seeing yours? Book a call.
Walk through your BigTime to Asana migration with a real engineer — 30 minutes, free, written quote within 24 hours.
Book a free 30 minute consultationAdjacent paths
Other ways to leave BigTime
Other ways to arrive at Asana
Same-Project Management migrations
Ready when you are
Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.