Migrate from TeamGantt to Microsoft Project

TeamGantt Projects map directly to Microsoft Project .mpp files. TeamGantt derives project start and end dates from the earliest and latest task dates respectively; Microsoft Project has explicit ProjectStartDate and ProjectFinishDate fields. We use the earliest task start date as the project anchor date in Microsoft Project, set the ProjectStartDate accordingly, and note the inferred-date behavior in the mapping spec so the project manager can verify the schedule alignment in Microsoft Project before finalizing.

TeamGantt Tasks map to Microsoft Project Tasks with Name, Start, Finish, Duration, PercentComplete, Notes, and custom fields preserved. Task hierarchy (subgroups and subtasks) maps to Microsoft Project outline levels using the ID and OutlineLevel fields; parent-child date dependencies are maintained by setting the parent task's constraints based on the earliest child start and latest child finish. TeamGantt's percent-complete rolls up automatically through the outline hierarchy in Microsoft Project.

TeamGantt task dependencies map to Microsoft Project PredecessorLink records. We translate the dependency type (Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish) to the Microsoft Project PredecessorType field (FF, FS, SF, SS) and carry lag or lead time as the Delay field on the PredecessorLink. Circular dependency detection runs during the transform phase; any circular references are flagged in the mapping spec for the customer to resolve before the successor records import.

TeamGantt Milestones (zero-duration markers with a name and date) map to Microsoft Project Tasks with the IsMilestone field set to Yes and Duration set to 0. The milestone date maps to both Start and Finish fields on the Microsoft Project task row. Milestone names and parent project associations are preserved in the Name and Summary fields.

TeamGantt baseline snapshots (Pro/Unlimited only) map to Microsoft Project's multi-baseline slots. We read each named baseline from TeamGantt, match it to an available BaselineN field in Microsoft Project, and write the Start, Finish, and Work values for each task under that baseline. If the source TeamGantt account is on Basic or Standard and baselines are absent, we skip this mapping and flag it in the scope document. We preserve up to 10 named baselines; additional TeamGantt baselines beyond this require customer review to decide which are the highest priority for import.

TeamGantt task assignees (Users) map to Microsoft Project Resource records. Each user is created as a Resource with the Name from TeamGantt and Email as the ID or material label. Resources are created before task imports so that the assignment lookups are satisfied. TeamGantt Guest users without full account status are mapped as material Resources with zero Max Units to distinguish them from billable human Resources.

TeamGantt Workloads report data (per-user task assignments and hours, Pro/Unlimited only) maps to Microsoft Project Assignment records on each Task. The AssignmentUnits field represents the allocation percentage; AssignmentWork represents total hours. If the source TeamGantt account is on Basic or Standard and the API returns 403 on the Workloads endpoint, we fall back to CSV export data and reconstruct assignment records from the task-assignee mapping in the CSV. We note this fallback in the mapping spec and reconcile the assignment row counts against the total task count during validation.

TeamGantt time entries (tracked hours on tasks, accessible via API and CSV) map to Microsoft Project AssignmentActualWork on the corresponding Task-Resource assignment pair. Actual work is set in hours aligned to the project's calendar. Planned hours from TeamGantt's time tracking map to AssignmentWork; actual tracked hours map to AssignmentActualWork. If TeamGantt uses hourly estimation without actual time tracking, AssignmentWork carries the estimate and ActualWork remains blank.

TeamGantt checklist items on tasks are serialized as a structured Note in Microsoft Project with a checklist-header prefix and checkbox markers. Completion status is represented as [x] or [ ] prefixes. We preserve the full checklist structure, item order, and completion flag. If the customer uses Microsoft Project's native Checklist field (Project Plan 3+), we map directly to that field instead of Note.

TeamGantt discussion threads attached to tasks (comment text, author name, timestamp) map to Microsoft Project Task Notes prefixed with the author name and timestamp. We preserve the full comment history in chronological order. Microsoft Project does not have a threaded discussion model, so multi-comment threads are collapsed into a single Note record with each comment on its own line. The customer's project manager reviews note formatting after migration.

TeamGantt project-level custom fields map to Microsoft Project project summary task custom fields. We discover each custom field's data type (text, number, date, dropdown) from the TeamGantt API and map to the equivalent Microsoft Project field type. Project-level custom fields in Microsoft Project display on the Project Information dialog and are accessible in reporting views. We configure the custom field definitions in the .mpp file before task data imports.

TeamGantt task-level custom fields map to Microsoft Project task custom fields (Text1-30, Number1-20, Date1-10, Flag1-20). We assign each TeamGantt custom field to an available Microsoft Project custom field slot, preserving data type fidelity. If a TeamGantt custom field is a multi-select label, we map it to a Text field; if it is a date, we map it to a Date field. We document the full custom field assignment map for the customer's admin to rename the field aliases to match their internal naming convention in Microsoft Project.

TeamGantt Labels (categorization tags on tasks) map to a Microsoft Project Text custom field. If the customer has fewer than 20 unique labels, we map to a dedicated Text field; if labels are used for status flags (e.g., 'At Risk', 'Blocked'), we map to a Flag field instead. Label assignment is per-task and preserved in the custom field value on each task row. We note the full label-to-value mapping in the mapping spec for the customer to verify and rename post-migration.