Migrate from Dart to Microsoft Project

Dart Workspaces are the top-level organizational container and map to Microsoft Project as either standalone Project plans (Project Plan 1 or Plan 5) or as projects within Project Online's Project Web App (PWA). We migrate workspace metadata, team membership, and the workspace's root-level project list. Workspace permission roles are not a native Project construct; we document the role-to-resource mapping as a written deliverable for the customer's admin to configure in PWA resource engagement sheets.

Dart Projects are the work container within a Workspace and map directly to a Microsoft Project file (MPP or cloud Project plan). Project metadata including name, description, start date, and target end date migrate to the Project Summary fields. The full task list nested under the Dart Project is loaded into the Project as outline rows. We preserve the project-level custom fields from Dart as Project-level custom fields in Microsoft Project.

Dart Tasks map to Microsoft Project Task rows. Standard fields (name, description, due date, start date, status, priority, assignee) migrate to their Microsoft Project equivalents (Name, Notes, Deadline, Start, Status, Priority, Resource Names). Microsoft Project uses an outline hierarchy for subtasks; we reconstruct the parent-child relationships from Dart's parent_task_id by creating outline indent levels during task import.

Dart subtasks do not have a separate object — they are Tasks with a parent_task_id reference to a parent Task. We resolve this by reading the full task tree, sorting by depth level, and creating outline indent levels in Microsoft Project that reflect the nesting. Outline Number and WBS fields in Microsoft Project preserve the hierarchical path for reporting. Subtask notes, dates, and custom field values map independently per row.

Dart Assignees reference user IDs by email. We cross-reference Dart assignee emails against the Microsoft Project resource list. If the resource does not exist in the destination Project or PWA resource pool, we create a placeholder resource with the name and flag it for the customer's admin to resolve before the final assignment pass. Assignment hours are estimated from Dart's task workload estimate if available.

Custom fields in Dart are defined at the Workspace level and applied per-task within a Project. We extract all field definitions (field name, type, options) separately from the field values, then recreate the destination custom fields in Microsoft Project before any task record import. This sequencing is required because Microsoft Project ignores custom field values on tasks if the field definition has not been created at the project level. Field type mapping: Dart text, number, date, and dropdown map to Microsoft Project Text, Number, Date, and Flag or Dropdown custom fields respectively.

After the field definitions are created in the destination Project, we load task custom field values from Dart. Values are matched to tasks by the Dart task ID preserved as a Project-level custom field (Dart_ID__c) on every task row. If a task value references a custom field option that does not exist in Microsoft Project (for example, a dropdown value created after scoping), we set the value to blank and flag it in the reconciliation report for the customer's admin to map.

Dart time entries are linked resources with duration, billable flag, and user reference. Microsoft Project standard does not have a native time tracking object. For Project Plan 5 or Project Online, we map time entry duration to a custom Number field (Time_Logged_hrs__c) on the task and note that full time-tracking requires Project Online's timesheet module, which requires PWA configuration. We deliver a written recommendation on whether to use custom fields or PWA timesheets based on the customer's billing and reporting needs.

Dart stores attachments as separate linked resources per task or project. We download each attachment to temporary storage, upload to the destination SharePoint site (for Project Online) or embed in the .mpp file (for Project Desktop), then create a link from the migrated task row to the file location. SharePoint URL preservation is not guaranteed because the SharePoint site structure may change; we document the final URL mapping in the migration deliverable. For large attachment sets (over 2,000 files), this adds a meaningful parallel pass to the migration timeline.

Dart's sprint cycle rollover feature, cited positively in Capterra reviews, maps to Microsoft Project as either a custom Text field (Sprint_Name__c) on task rows or as Project Phases (available in Project Online). If the customer uses Dart's sprint model, we ask during scoping whether they prefer sprint names as a custom task field or as Phase values in PWA. We do not migrate sprint archiving rules as these are Dart-specific behavioral settings.