Migrate from Twproject to monday Work Management

Each Twproject Project maps to a monday.com Board. We extract project details via the Twproject JSON export (project name, description, dates, status) and use the monday.com API to create the board. For multi-project portfolios, we can also create a monday.com Workspace and nest boards within it, preserving the portfolio grouping logic from Twproject.

Twproject's WBS stores Phases and Sub-phases within a Project as hierarchical nodes. monday.com Groups correspond to horizontal sections within a board but do not natively support multi-level nesting. We flatten the WBS to two levels: the top-level phase becomes a monday.com Group, and its direct child tasks become Items. Deeper nesting (sub-phases with child tasks) is represented as either a Group within a Group or as Items with a parent-Item link, depending on the customer's preferred structure. We agree on the flattening strategy during scoping.

Twproject Tasks map directly to monday.com Items. We transfer task name, description (rich text), start date, due date, assignee (via resource mapping), status, priority, and estimated hours. Custom fields on Twproject tasks map to monday.com column types — text fields to Text columns, date fields to Date columns, numeric fields to Numbers columns, and picklist-style fields to Status columns. Subtasks in Twproject map to Subitems in monday.com.

Twproject Resources (user accounts with allocation rates, cost rates, and department metadata) map to monday.com team members. We extract user email, name, department, and cost rate. Cost rates transfer as a custom number field in monday.com because the platform does not have a native cost-rate field on users. The customer provisions the monday.com account before migration, and we match resources by email during the user import phase.

Twproject worklogs (hours logged against tasks, with date, description, and billable flag) are not included in the JSON export. We pull them via direct Twproject API calls using the task ID association. On monday.com Pro and Enterprise plans, time tracking is a native column type — we create the column on the relevant board and log each worklog entry against the corresponding Item. On Standard plans, worklogs migrate as a structured custom number column with a separate mapping note explaining that the customer must upgrade to Pro for native time tracking UI.

Twproject's project-level costs, additional expenses, and budget-vs-actual forecasts are fetched via separate API calls (they are excluded from the JSON export). monday.com has no native cost-tracking columns. We create custom Number columns per budget dimension (budget, actual, variance) on the relevant board. If the customer requires native budget tracking, we recommend the monday.com Portfolio solution (Enterprise) or a third-party integration like Heinsohn's budget tracking apps on the monday.com marketplace.

Twproject custom fields on tasks and projects are enumerated during discovery via API. We map each to an equivalent monday.com column type: text fields become Text columns, numeric fields become Number columns, date fields become Date columns, and multi-value fields become Status or Dropdown columns. Twproject's custom field definitions (field type, required flag, validation rules) are documented in a custom field inventory that the customer uses to configure monday.com column settings before data load.

Twproject tags on tasks and projects map to monday.com Labels (colored tags attached to Items) or to a Status column, depending on the customer's preference. We extract tag assignments via API and create the corresponding Labels in monday.com. If Twproject tags are used for classification rather than workflow status, Labels are the preferred target. If tags represent a workflow stage, a Status column is more idiomatic in monday.com.

Twproject task dependencies (finish-to-start, start-to-start, etc.) are expressed in the Gantt WBS. monday.com's Dependencies column (available on Pro and Enterprise) supports finish-to-start item-level dependencies. We map Twproject dependency pairs to monday.com Dependency column entries, creating an item in monday.com for each dependent Twproject task. Start-to-start and finish-to-finish dependencies have no native monday.com equivalent and are documented in the dependency inventory for manual recreation.

Twproject's Gantt view is driven by the WBS with start/end dates and durations stored at the task level. monday.com's Timeline column (Standard and above) renders a Gantt-style view automatically. We map Twproject task start and end dates to the monday.com Timeline column. The hierarchical WBS representation is preserved via the parent-item or group structure established in the Project-to-Board mapping. Milestones in Twproject (zero-duration markers) map to Items with a dedicated milestone Status or label.

Twproject's Kanban view is a daily planning view rather than a top-level object. Task assignments and statuses from Twproject drive the monday.com board display. We migrate task status values to monday.com Status column options. The Kanban column configuration (columns, swimlanes, WIP limits) is not exported from Twproject and must be reconfigured in monday.com's board settings; we document the Twproject Kanban columns during discovery as a reference for the customer.

Twproject attachments are not included in the JSON export and cannot be retrieved via the standard API path for all deployment types. We flag this gap during scoping. For cloud-hosted Twproject instances, attachments can sometimes be retrieved via direct API calls with user credentials. For on-premise instances, attachment retrieval depends on the customer's server configuration and may require filesystem access. We assess attachment viability per deployment type during discovery and document findings in the migration scope.