Migrate from TeamGantt to monday Work Management

TeamGantt Projects map to monday.com Boards. The project's name, description, and dates migrate. TeamGantt derives project start/end dates from the earliest and latest task; we use those as the board's start/end anchor. Custom fields on the project level migrate to monday.com board-level custom columns. Note that monday.com boards have no inherent start/end dates at the board level—those live on the Timeline column of items—so we set the board's initial items with the derived date range.

TeamGantt Tasks map to monday.com Items within a Board. All core fields migrate: name, start date, end date, duration, percent complete, notes, assignee, and custom fields. The source Task ID is preserved in a custom column for reconciliation. TeamGantt's percent_complete becomes a Number column; we recommend a Status column with Done/Not Done or percentage-based labels as the monday.com-native progress indicator.

TeamGantt Groups (task subgroups with nested children) require a configuration decision during scoping: shallow hierarchies (1-2 levels) map to monday.com Subitems natively. Deep hierarchies (3+ levels) map to monday.com Groups within the same Board, with parent task names as group headers and child tasks as items. We flag hierarchy depth during discovery and present both options with the tradeoffs: Subitems offer richer per-child columns; Groups offer faster board loading at scale.

TeamGantt Finish-to-Start and Start-to-Start dependencies map to monday.com's Dependencies column. Lag-time relationships (expressed in days in TeamGantt) cannot be stored natively in monday.com's Dependencies column; we handle this by adding or subtracting the lag days from the successor item's start date as a manual adjustment. The migration spec documents every lag-time dependency so the customer's admin can validate or re-enter lag values in monday.com's dependency editor.

TeamGantt Milestones (zero-duration date markers) map to monday.com Items using the Milestone column type. The milestone name and date migrate as an Item with the Milestone column set to the target date. We also preserve the milestone's project and group associations by placing the milestone Item in the correct Group on the target Board. Note: monday.com's Milestone column is available on Pro and Enterprise plans.

TeamGantt Baselines are named snapshots of the original planned schedule. We export each saved baseline's task-level planned start, planned end, and duration values and store them in three custom columns on the destination board: Baseline_Planned_Start, Baseline_Planned_End, and Baseline_Planned_Duration. The current (actual) dates live in the standard Timeline column. This allows monday.com's Gantt view to display a baseline comparison, though the baseline is a static reference rather than a native live comparison tool. We migrate all named baselines per project as separate date sets if the account has multiple saved baselines.

TeamGantt time entries (hours logged against tasks) map to monday.com's native Time Tracking column if the destination board is on a Pro or Enterprise plan. If the destination is on Standard (which lacks native time tracking), we map hours to a Numeric column formatted as decimal hours and note the limitation. Time entries include the tracked date, hours, and user attribution; we map the user attribution to the monday.com Item assignee.

TeamGantt Workloads report data (user, task assignments, and allocated hours per user per day or week) maps to monday.com's Workload View, which uses the People column to assign Items to users and displays capacity across a time grid. We export the Workloads report CSV (available on Pro and Unlimited) or via API and map user-task assignments to monday.com People column values. Capacity thresholds (max hours per day) must be set manually in monday.com's Workload View settings.

TeamGantt Checklist items on tasks map to monday.com Subitems (one Item per checklist item with a Status column) or the native Checklist column depending on the customer's preference. Subitems preserve richer metadata per checklist item; the Checklist column is faster to review on mobile. We flag the preferred approach during scoping based on checklist item complexity.

TeamGantt discussion threads on tasks migrate to monday.com Item Updates. Each discussion comment becomes a separate Update on the target Item, preserving the comment body, author name, and timestamp. The updates are posted in chronological order. Note that monday.com Updates do not support threaded replies natively; flat comment threads from TeamGantt flatten into a single update stream.

TeamGantt project-level custom fields (text, number, date, dropdown) map to monday.com board-level columns of the equivalent type. Text fields map to Text columns, numbers to Numeric columns, dates to Date columns, and dropdowns to Dropdown or Tags columns. We discover all custom field definitions via TeamGantt API during discovery and pre-create matching columns in the monday.com board before item import.

TeamGantt task-level custom fields map to monday.com Item columns (custom columns at the board level that apply to all items). Type mapping follows the same rules as project-level custom fields. Multi-select or label fields from TeamGantt map to monday.com Tags columns. We flag any field type mismatches (e.g., TeamGantt formula fields) during discovery and document them as columns requiring manual population post-migration.

TeamGantt Labels (colored tags used to categorize tasks) map to monday.com Tags columns. The label name and color migrate as a Tag with the matching color if available in monday.com's tag palette; nearest-color mapping applies for custom TeamGantt label colors that have no direct monday.com equivalent.

TeamGantt Users referenced on task assignments map to monday.com Workspace Members. We resolve by email match. Guests (TeamGantt users with limited project access) map to monday.com Guests if the destination workspace uses guest access. The customer's monday.com admin provisions the workspace members before migration; we validate the lookup table before item import to avoid assignee nulls.