Migrate from Swit to Microsoft Project

Swit Projects function as workspace containers, each with its own dashboard, workload chart, and configuration. Microsoft Project treats each .mppx or Project for the web project as a standalone scheduling container. We map Swit Projects to Microsoft Project plans directly, preserving the project name, description, start date (derived from earliest task due date if not explicitly set), and project-level custom fields. Multi-project portfolio reporting in Microsoft Project Plan 5 requires separate plan creation; we create each Swit project as its own plan and flag the portfolio grouping for the customer's PMO to configure in the destination.

Swit task cards map to Microsoft Project tasks with Name, Start/Finish dates (derived from Swit's due date and timeline fields), Duration (calculated from start to finish or set manually post-migration), and Notes (from Swit task description). Task priority maps from Swit's Low/Medium/High labels to Microsoft Project Priority field. We preserve the Swit task's unique identifier in a custom field swit_task_id__c for reconciliation. Swit task status values (team-configurable per project) are mapped to Microsoft Project Task Status values during migration, with any unmapped statuses flagged for the customer's admin to configure as custom status flags in the destination.

Swit subtasks are nested under parent task cards with their own completion state and assignee list. Microsoft Project supports sub-tasks through the task outline hierarchy (indenting a task under a summary task). We reconstruct the parent-child relationship by matching the Swit parent task ID, then set the sub-task as a child in the Microsoft Project WBS hierarchy with Outline Level incremented. Subtask assignees migrate as Resource Assignments on the sub-task record. The display order from Swit is preserved by setting the Outline Number in Microsoft Project to match the source sequence.

Swit checklists are embedded line items within task cards with a checked/unchecked state. We offer two migration strategies, chosen during scoping: (a) each checklist item becomes a bulleted sub-item in the Microsoft Project task's Notes field, preserving the completion state as a prefix symbol (e.g., [x] Item 1, [ ] Item 2); (b) each checklist item is created as a separate sub-task under the parent task with Duration=1 day and its own Resource Assignment. Strategy (b) is more accurate but increases task count significantly. We count checklist items during discovery and advise on the trade-off before migration begins.

Swit tasks and subtasks support multiple assignees stored as a list on each task. Microsoft Project Resources are named entities (Resources tab) with assignment Units on each task. We extract all distinct assignee names from Swit tasks, create corresponding Microsoft Project Resources (type: Material or Work depending on whether the assignee represents a person or a consumable), and create Assignment records for each assignee-to-task relationship. Multiple Swit assignees on a single task become multiple Assignment rows in Microsoft Project with their respective Units. If the customer uses Microsoft Project for the web with Microsoft 365, we link Resources to Entra ID users for accurate display names.

Swit task comments are threaded conversation entries with author, timestamp, and text body. Microsoft Project stores comments at the task level (via the Comments column in the grid view or the Task Details pane). We migrate comments as Microsoft Project task comments with the original author name and timestamp preserved. Threading structure from Swit (replies to comments) is flattened in Microsoft Project since the destination does not support threaded comment hierarchies; all replies are posted chronologically without parent-child threading.

Swit attachments (files, emails, channel messages linked to a task) carry filename, size, type, and URL metadata. We export attachment metadata and attempt to retrieve file content via the Swit storage API. If file content is retrievable, we upload to SharePoint or OneDrive and create a hyperlink in the Microsoft Project task's Notes field. If file content is not accessible, we export the attachment metadata (filename, Swit URL, size, type) to a reconciliation CSV and flag items requiring re-upload in the destination. Actual file migration is not guaranteed for locked or inaccessible attachment types.

Swit tags label tasks for filtering and categorization across projects. Microsoft Project supports enterprise custom fields (Text1-30, Flag1-20) that can be scoped per project or globally. We map Swit tag names to a Text-type enterprise custom field (e.g., Custom Text1 labeled 'Tags') on the Task entity. If a task carries multiple Swit tags, we comma-separate them in the destination field. The customer chooses whether tags migrate globally or per-project-type during scoping.

Swit records time logged per task with user, duration, and associated task reference. Microsoft Project Assignment fields (Assignment Work, Assignment Remaining Work) store effort per resource per task. We map Swit time entries to Microsoft Project Assignment rows on the corresponding task, setting Assignment Actual Work to the logged duration in hours. If the destination is Microsoft Project Plan 3 or Plan 5 with timesheet integration, we preserve the time entry in the Assignment table and the customer's admin enables timesheet approval workflows post-migration.

Swit custom fields are defined at the project level, meaning each of a customer's projects may have a different set of custom field definitions. We enumerate every distinct custom field across all Swit projects during discovery, deduplicate by field type (text, number, date, choice, person, link), and create corresponding Microsoft Project Enterprise Custom Fields of matching type before migration begins. For choice-type fields, we also create the picklist values in Microsoft Project. If a Swit project has a custom field not present in other projects, it still migrates as a valid enterprise field; tasks in projects that do not use that field receive no value for it. This per-project enumeration step adds planning time for accounts with more than 10 active Swit projects.

Swit task cards carry priority values (Low, Medium, High, or custom team-defined labels) stored on the priority field. Microsoft Project has a built-in Priority field (integer 0-1000, with common values 500=Normal, 600=High, 800=Critical). We map Swit priority labels to Microsoft Project Priority integers based on the customer's actual Swit priority label set. Custom Swit priority labels are preserved in a custom field swit_priority__c for reference and reporting clarity.

Swit task status values are configured by each team and vary by project (e.g., one team uses 'Backlog, In Progress, Review, Done' while another uses 'To Do, Doing, Blocked, Closed'). Microsoft Project uses built-in status types (Not Started, In Progress, Completed, Deferred, Cancelled) with customizable Status Flags. We extract the actual status values from each Swit project during discovery, then map them to Microsoft Project Status Flags on a per-project basis, with the mapping matrix documented in the migration deliverable. Any status values without a clear Microsoft Project equivalent are flagged for manual post-migration categorization.