Migrate from Deltek WorkBook to Asana

WorkBook Projects map 1:1 to Asana Projects. Project name, status (active/on-hold/closed), start date, end date, and description transfer directly. WorkBook project budgets map to a custom currency field in Asana because Asana does not have native budget tracking. WorkBook Project custom fields (excluding the 21 Dimensions) map to Asana custom fields. Project templates in WorkBook do not migrate as templates; we deliver a written inventory of templates for the admin to recreate in Asana.

WorkBook Tasks map 1:1 to Asana Tasks with task hierarchy preserved as parent-child relationships via the parent Task gid reference. Task assignees, due dates, start dates, status, and description transfer directly. WorkBook subtasks map as Asana subtasks (which are Tasks with a parent field set). Task-level custom fields map to Asana custom fields. WorkBook's task Kanban statuses map to Asana Section names within each project.

WorkBook subtasks (tasks nested under a parent task) map as Asana subtasks. We preserve the parent-child relationship by resolving the parent WorkBook Task ID and setting the Asana Task's parent field to the corresponding migrated Asana Task gid. Subtask hierarchy deeper than two levels maps as a flat subtask list in Asana because Asana does not natively support three-level subtask nesting.

WorkBook Time Entries link to a Project and Task with hours logged, date, billing status (billable/non-billable), and hourly rate. Multiple time entries for the same task merge into Asana's built-in time tracking log on that task. Billable flag maps to a custom field billable_status__c on the task. Hourly rate from WorkBook does not have a native Asana equivalent and maps to a custom field billable_rate__c for reference. Historical time entry timestamps preserve the original WorkBook date for audit.

WorkBook Workers store skills, availability calendars, and utilisation data. Asana does not have a native resource management module. We migrate worker profiles as a custom Asana Portfolio named 'Resources' with each worker as a Portfolio item, and store skills as multi-select custom fields, availability notes as text fields, and utilisation percentage as a number field. Active vs archived status in WorkBook maps to a custom field worker_status__c.

WorkBook CRM Contacts (distinct from project stakeholders) do not have a direct Asana equivalent because Asana is not a CRM. We present two options during scoping: Option A stores contacts as rows in a dedicated 'Contacts' Asana project using custom fields (name, email, phone, company, lifecycle_stage); Option B stores contact references as custom fields on the relevant Asana Project. The customer chooses. WorkBook contact-to-company linkage is preserved via a company custom field on the contact record.

WorkBook Companies/Accounts represent client organisations and store industry, size, and address. Asana does not have a native Accounts object. We migrate companies as a 'Clients' project with each company as a section containing the relevant project sub-items, or as rows in a 'Client Directory' project with custom fields for company details. The choice depends on the customer's Asana tier and the volume of client records.

WorkBook Pipeline stages represent a sales pipeline with stage names, order, and win/loss probability. Asana has no native pipeline object. We reconstruct the pipeline as an Asana Project per WorkBook pipeline, with sections representing stages, and opportunities stored as tasks with a custom field pipeline_stage__c. Win/loss probability maps to a custom field probability__c. The customer admin rebuilds pipeline visualisation using Asana Portfolios grouped by stage section after migration.

WorkBook Expenses (mileage, material, personal) with receipt attachments and reimbursement status do not have a native Asana equivalent. We migrate expense records as Asana Tasks in a dedicated 'Expense Log' project, with expense amount, category, date, and reimbursement status as custom fields. Receipt attachments migrate as file attachments on the task. The reimbursement approval workflow does not migrate; we flag this for the customer's admin to rebuild using Asana Forms and Rules if needed.

Files attached to WorkBook Projects, Tasks, or Companies export via WorkBook's file storage API. We extract file metadata (name, type, size, upload date) and binary content, then re-attach to the corresponding migrated Asana Project or Task via the Asana Attachments API. Large file volumes (over 5 GB total) require chunked extraction and may extend the migration timeline. We flag any file that exceeds Asana's 100 MB per-attachment limit for manual handling.

WorkBook's 21 built-in Dimensions and 10 custom Dimensions tag every transaction with multi-dimensional cost attribution. Asana has no dimensional accounting model. We present a Dimension Mapping Matrix to the customer: each WorkBook Dimension becomes an Asana custom field on the Project or Task. Dimensional cost attribution from WorkBook journal entries cannot be replicated in Asana because Asana does not have a ledger. We document the dimension values for each project and store them as custom fields; financial reporting based on dimensions is outside Asana's scope.

WorkBook System Variables and Company Variables control numbering sequences, workflow flags, and integration settings. These are configuration objects with no Asana equivalent. We export them as a structured JSON bundle and flag any that reference IDs that will not exist post-migration. We deliver the bundle as a written settings inventory for the customer's admin to review and manually configure in Asana. Numbering sequences for Projects and Tasks map to Asana's project numbering prefix if the customer's Asana tier supports it.