Migrate from awork to Microsoft Project

awork Projects map directly to Microsoft Project projects. Project name, description, start and end dates, assigned users, and budget fields transfer 1:1. awork's workspace scoping maps to the SharePoint site collection or Project Web App (PWA) site that hosts the destination project. We preserve awork's project-level budget as a custom number field in Microsoft Project since native budget tracking requires PWA and Enterprise Project Type configuration. Project status from awork (per-workspace vocabulary) requires explicit mapping to Microsoft Project custom status fields or Project Task Status values.

awork Tasks map to Microsoft Project Task records. Assignee, due date, description, and priority transfer. awork has no predecessor-successor dependency model; task ordering in awork's list or board view is implicit but not structurally defined as dependencies. We reconstruct dependencies during migration by analyzing task start/end date proximity, checklist-style ordering in awork's subtask hierarchy, and any date-based handoff logic the customer documents during scoping. Milestone tasks in awork (tasks with no duration) map to Microsoft Project milestones (Duration = 0). A customer-provided or reconstructed dependency map is required input for this step.

awork Subtasks are structured children of tasks. In Microsoft Project, the parent task becomes a Summary Task with the child rows collapsed beneath it in the WBS hierarchy. We preserve the parent-child relationship and transfer any subtask-level assignee, due date, and description. If the destination Microsoft Project instance uses outline numbering or WBS codes, we regenerate the WBS hierarchy post-migration. Subtask ordering is preserved by sequence within the parent task.

awork Users map to Microsoft Project Resources. awork stores name, email, and avatar. Microsoft Project Resources carry name, email (for Project Online), type (Work vs Material), and Max Units. We map awork project assignees to Resource Assignments in Microsoft Project. If awork user roles differentiate between project managers and generic team members, we map those to the Resource's Max Units and possibly a custom Resource Type field. Users without a corresponding destination resource go to a reconciliation queue.

awork Time Entries are a core native object with start/end timestamps, user attribution, billable/non-billable flags, and task association. Microsoft Project Online has no native timesheet or billable time object; time entry data must be mapped to the Assignment Work field on Task, or stored in a custom PWA enterprise custom field if the destination is Project Online and the PWA timesheet feature is active. We map hours from awork time entries to Assignment Actual Work on the corresponding task-resource assignment. The billable flag becomes a custom yes/no field on the assignment or a separate custom timesheet entry object. PWA timesheet configuration is required before this mapping if the customer wants a native timesheet experience post-migration.

awork Project Statuses are defined per workspace with custom names, colors, and ordering. Microsoft Project does not have a native project-level status field; status is typically communicated via the project schedule health (on track, at risk, delayed) or a custom field. We collect the full awork status vocabulary during scoping and build a mapping table to either a PWA custom enterprise field or a SharePoint list column that feeds a Power BI status dashboard. This mapping is customer-specific and must be validated during sandbox migration.

awork custom fields are created at the workspace level but require per-project activation before they appear at the task level. We audit every awork custom field during scoping and check its activation status per project. Only fields with activation confirmed across the relevant projects migrate. Microsoft Project Online requires custom fields to be defined as PWA Enterprise Custom Fields before they accept data; we configure the destination field definition (type, lookup table, formula) before loading any records. Text, number, date, and choice field types map to their Microsoft Project equivalents.

awork Tags are key-value labels applied to tasks for cross-project categorization. Microsoft Project does not have a native tag object; tags are typically implemented as Outline Codes, custom text fields, or Enterprise Custom Fields. We map tag names 1:1 to a destination custom field of the customer's choosing. If the destination is Project Online, we recommend an Enterprise Outline Code with the same structure as the source tag taxonomy. Tag normalization (removing spaces, enforcing lowercase) happens during the transform step if the destination enforces format restrictions.

awork Project Templates define reusable project structures including default tasks, statuses, and custom field configurations. Microsoft Project has no direct template sharing between awork and Project. We extract the template definition as structured data (task list, default durations, custom field defaults, status assignments) and document it in a written template reconstruction guide. The customer's project manager uses this guide to recreate the template in Microsoft Project using the desktop client or Project Online's template save feature. Template migration is a documentation handoff, not an automated data load.

awork Clients are top-level entities that Projects are associated with but time cannot be logged directly against. Microsoft Project Online has no native client object. We map awork Client records to a SharePoint list (if using PWA on SharePoint) or to a custom Project Online enterprise custom field on the Project entity. The customer chooses whether to manage client data as a dropdown custom field or as a linked SharePoint list with lookup.