Migrate from Mission Control to Microsoft Project

Mission Control Projects map to Microsoft Project project files or Project Online PWA projects. We extract project name, description, status, start date, finish date, owner, and member list. Project-level custom fields map to Project Summary Tasks or custom fields in PWA. Sub-project hierarchies in Mission Control are flattened to a flat list with parent references; we reconstruct the top two levels as Summary Tasks in MS Project and attach any remaining sub-projects as standalone projects linked by a parent_reference custom field for post-migration reorganization.

Mission Control Tasks map to Microsoft Project Tasks with Task Name, description, status, priority, start date, finish date, and assignee preserved. Mission Control status values (Not Started, In Progress, Completed, On Hold, Cancelled) map to MS Project percent complete and status indicators. Priority maps to the Priority field. Due date maps to Finish date. Task ordering within a project is preserved by sequence number.

Mission Control Subtasks nest under Tasks with the same field set. The export flattens any hierarchy beyond three levels of nesting, so we reconstruct the hierarchy up to three levels as MS Project Summary Tasks with child tasks indented. Subtasks beyond level three attach as sibling tasks with a parent_reference field in the Name column or a custom column for manual reorganization. Customers with deeply nested task structures should be warned that the visual hierarchy may not map 1:1 and may require post-migration manual reorganization.

Mission Control Users map to Microsoft Project Resources. We resolve users by email address as the dedupe key. User name becomes Resource Name, email becomes Resource Notes. Mission Control role maps to the Resource Initials or Group field. Teams are mapped to Resource Groups. Any Mission Control User without a matching Microsoft account is held in a reconciliation queue for the customer's admin to provision before resource assignment migration resumes.

Mission Control Teams map to Microsoft Project Resource Groups. Team membership (users belonging to each team) does not migrate as a native MS Project concept; we create Resource Groups matching team names and document membership in a separate worksheet for admin reference. If the destination is Project Online PWA, team data maps to Enterprise Resource Pool groups.

Mission Control task Dependencies map to Microsoft Project Predecessor relationships. We extract the predecessor task ID, successor task ID, and dependency type (Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish) and write the corresponding MS Project predecessor formula in the Predecessor column. Lag time migrates as a positive or negative duration in the Predecessor field. Cross-project dependencies do not map directly and are flagged for manual rebuild in the destination.

Mission Control Comments (timestamped, authored entries attached to Tasks or Projects) migrate as MS Project Task Notes. We preserve full comment text, author name, and timestamp ordering. If the comment is attached to a specific task assignment, it attaches as an Assignment Note. Comment threads spanning multiple entries are concatenated in chronological order within a single Note field. MS Project does not have a native comment thread concept, so thread order is preserved as a prefixed sequence number in each Note.

Mission Control file attachments (name, size, mime type, URL) migrate as MS Project Hyperlink entries pointing to the original URL. Actual file content transfer depends on whether the source storage is publicly accessible; if the attachment URL requires authentication, we document the attachment reference in a separate worksheet for manual download and re-attach. If the destination is Project Online PWA, attachments may link to SharePoint document libraries via the PWA SharePoint integration.

Mission Control Tags (string labels applied to Tasks and Projects) migrate to MS Project Outline Codes if the destination is Project Online PWA, or to a custom text field if the destination is Project Desktop. We export the full tag vocabulary and apply tag values to matching destination records. Tags without a destination match attach as a comma-separated text string in a custom field for manual categorization post-migration.

Mission Control Workflow rules (triggers, conditions, and actions defined in Salesforce Flow) do not migrate as executable definitions. We export the full rule configuration as structured JSON documentation with trigger type, condition logic, and action sequence. This document serves as a setup guide for rebuilding equivalent logic in Microsoft Planner (task automation with triggers) or as a reference for Project Desktop administrators. We recommend scheduling a pre-migration review call to prioritize which workflows are business-critical and plan manual re-implementation in parallel with data migration.

Mission Control Time Tracking entries (hours logged against Tasks by Users) map to MS Project Assignment Actual Work. We extract the date, hours, user (mapped to Resource), and task (mapped to Assignment). If Mission Control tracks billable vs non-billable time, billable hours map to Assignment Billable Work. Note that standard Microsoft Project does not have a native timesheet interface; customers needing timesheet submission and approval require Microsoft Project Online PWA with Timesheet functionality or a third-party timesheet add-in.

Mission Control embeds project financials (costs, billable revenue, margins, revenue recognition) as a core PSA feature. Microsoft Project has no native financial tracking fields beyond resource cost rates and task cost fields. We do not migrate project financial records. We document the financial object schema (cost fields, billing rates, revenue recognition rules) in a separate data dictionary so the customer can plan external tracking in a PSA tool, Dynamics 365 Project Operations, or a spreadsheet-based reporting process.