Migrate from WeTrack to Microsoft Project

WeTrack Projects (top-level programme containers) map 1:1 to Microsoft Project project files. In Project Desktop (.mpp) destinations, each WeTrack Project becomes a separate .mpp file. In Project for the web, each maps to a Project for the web project in the customer's SharePoint-backed tenant. We preserve Project name, description, start date, end date, status, and any Programme-level custom fields. Multi-project programmes in WeTrack require a scoping decision during discovery: either import as separate .mpp files with consistent resource naming and cross-file dependency notes, or consolidate into a master project using subproject linking in Project Desktop.

WeTrack Tasks map to Microsoft Project Tasks with Start Date, Finish Date, Duration, and Predecessors preserved. WeTrack's parent-child hierarchy maps so that a WeTrack Task with child Subtasks becomes a Microsoft Project Summary Task (with the summary checkbox enabled) and its Subtasks become the child tasks below it. This preserves the rollup of dates and durations from child to parent that WeTrack handles through its auto-sync date cascade.

WeTrack Subtasks are flat child records under a parent Task. In Microsoft Project, they become child tasks under the parent Summary Task. We resolve the parent reference during the transform phase and set the Outline Level and ID hierarchy so that the WBS numbering and indentation match the WeTrack structure. Any Subtask that has its own child records in WeTrack creates an additional nested Summary Task level in Microsoft Project.

WeTrack Attachments of all types are accessed via a three-dot menu in the UI. We extract the file name, file type, uploaded date, and uploaded-by user from WeTrack. In Project Desktop destinations, we store a text reference (URL or local path) in the Notes field or a custom Attachment Link field on the task. In Project for the web, we create SharePoint document library entries linked to the task via the Planner or Project connector. We flag any attachments that cannot be extracted from WeTrack's UI during the data-pull phase so the customer can export them manually before cutover.

WeTrack Risk Registers use Inherent Likelihood and Impact ratings (industry-standard 1-5 scale) and RAG status. Microsoft Project has no native risk object. We map each risk record to a Task with three custom numeric fields: Inherent Likelihood (1-5), Inherent Impact (1-5), and Risk RAG (text: R, A, G). Risk Owner from WeTrack maps to the Task's Resource Assignment. The customer receives a written risk register inventory at cutover with a recommendation to migrate to a SharePoint risk log or Power Apps-based risk tracker for long-term risk management, since task-based risk tracking is a workaround and not a native risk management solution.

WeTrack Job Categories restrict valid options on Tasks to prevent data entry errors. We extract the Job Category values and create a custom picklist (in Project for the web via SharePoint column) or a custom text field (in Project Desktop) on the Task object. Valid values are seeded from the WeTrack Job Category list. We flag any categories that have no equivalent value in the destination picklist for manual reassignment during reconciliation.

WeTrack RAG status updates run on predictable schedules and cascade from parent tasks to subtasks. WeTrack stores RAG as a colour value (Red, Amber, Green). Microsoft Project does not have a native RAG field. We create a custom text field (Task.Number1 or a custom field mapped at import) and populate it with the WeTrack RAG value. The cascade behaviour (parent RAG inherited by subtasks) is preserved at migration time by re-applying the parent RAG to child tasks during the transform. The customer can optionally configure a conditional formatting rule in Project Desktop to colour-code the Indicator field based on the RAG value.

WeTrack's Sustainability module tracks ESG indicators and metric values per project or task. Microsoft Project has no native ESG tracking capability. We map these records to custom numeric fields on the relevant Task (e.g., Carbon Reduction %, Waste Diverted kg, Water Saved L) and flag that destination systems may require a separate SharePoint ESG tracking list or a third-party ESG reporting tool for comprehensive ESG programme management. The ESG record parent (Project or Task) is resolved during transform. If no equivalent task exists for an ESG record, it is mapped to the Programme-level custom fields or flagged for manual entry.

WeTrack Incident Reports are operational records that may have no direct equivalent in Microsoft Project. We map them to Tasks with a custom text field (Incident Type or Incident Status) or to SharePoint Issue Tracker list items if the customer uses a Project for the web SharePoint-backed environment. Incident metadata (date, owner, status, description) migrates as task fields. We flag any Incident Report records with attachment dependencies that could not be extracted from WeTrack for manual handoff.

WeTrack User accounts and Task Owners are referenced by ID. We extract all distinct user IDs and names and map them to Microsoft Project Resources in the Resource Sheet (Project Desktop) or to Microsoft 365 users in Project for the web. Resource names, email addresses, and active/inactive status migrate. We flag any WeTrack users who do not have a matching Microsoft 365 account for admin provisioning before record import resumes, and any orphaned task assignments where the owner has been deactivated.