Migrate from Work as Team to Microsoft Project

Work as Team Projects map directly to Microsoft Project files (MPP) or Project Online Project entities. Project name, description, start date, and deadline migrate as project-level metadata. We resolve the project status (active vs archived) and carry archived projects as separate inactive MPP files or Project Online projects with an Archived flag custom field.

Work as Team Lists do not have a direct Microsoft Project equivalent because Lists are a Work as Team-specific organizational container. We map each List to a Microsoft Project Summary Task row with the List name as the task name and indent all tasks from that List beneath it. If a Work as Team project has multiple Lists, this produces multiple Summary Task groupings in the destination project. List-level permissions do not migrate because Microsoft Project does not have a native per-task-group permission model.

Work as Team Tasks map to Microsoft Project Task rows. Task name, description, due date, start date, and assignment migrate. We handle the indent level based on the parent List mapping (tasks inherit the Summary Task grouping from their source List). Task status (open, resolved, completed) maps to Microsoft Project PercentComplete or Status fields. Subtasks within a List become child tasks under the Summary Task with appropriate outline level.

Work as Team Milestones map to Microsoft Project Task rows with Duration = 0 and Milestone = Yes. Milestone name, deadline date, and any associated description migrate. We verify that the milestone date lands on a working day or adjust per the project calendar during migration.

Work as Team time entries link a team member to a task with hours logged and a date. In Microsoft Project, we create or link a Resource record for the team member, then add an Assignment to the related Task with the Work field set to the logged hours. We preserve the original date as an Assignment Start and Finish date. If multiple time entries exist for the same task-resource pair, we aggregate them into a single assignment record. Per-hour billing rates stored in Work as Team do not migrate because Microsoft Project does not support a native billing rate field on task assignments.

Work as Team team members map to Microsoft Project Resources. The resource name, email, and role migrate. We classify each resource as Material (for agency staff with hourly rates) or Work (for full-time contributors) based on the Work as Team billing configuration. Resource rates from Work as Team are stored as a custom field because Microsoft Project does not have a native billing rate field for material resources.

Work as Team task assignments (person assigned to a task) map to Microsoft Project Task Assignments with the assigned resource linked and the assignment percent set to 100 if a single person or divided if multiple. The Work as Team estimated hours vs actual hours distinction maps to Task field Assignment Units vs actual work logged.

Work as Team custom fields on tasks and projects migrate to Microsoft Project Custom Fields created via the Project Organizer. Text, number, date, and flag field types map directly. Dropdown or multi-select custom fields in Work as Team require a lookup table in Microsoft Project. We pre-create the destination custom fields before migration and flag any custom fields with no direct Microsoft Project type for customer decision during scoping.

Work as Team file attachments linked to tasks do not migrate as embedded objects in Microsoft Project MPP files. We extract the file URLs or download attachments during extraction, upload them to a SharePoint Document Library (or OneDrive if no SharePoint exists), and add a Hyperlink on the related Microsoft Project Task pointing to the document location. File version history does not migrate.

Work as Team client portal data (client-facing project updates, client comments, client-only tasks) has no Microsoft Project equivalent. We extract client portal content during extraction and deliver it as a written inventory with file attachments so the customer's admin can configure a SharePoint site or Microsoft Teams channel as a replacement client communication space. This is not a data migration; it is a content handoff for manual rebuild.