Migrate from TeamBoard - Work Management & Project Management for Salesforce to monday Work Management

TeamBoard Portfolios group multiple Work Boards for executive oversight and reporting. The portfolio-to-project linkage is stored in a Salesforce junction object. We map Portfolios to monday.com Folders (for grouping boards) or, if the customer uses monday.com Workspaces for business-unit separation, to Workspace-level organization. The junction relationship (which projects belong to which portfolio) is preserved as a multi-select mapping at migration time.

The Work Board is TeamBoard's core UI concept and the primary organizing entity for migration sequencing. We treat each Work Board as a monday.com board. The board's folder assignment, description, and status (Active/Archived) map to the monday.com board name, description, and workspace. We preserve the board-to-task linkage so that all tasks assigned to the board in TeamBoard land in the corresponding monday.com board on migration day.

TeamBoard Projects are the project-level containers inside a Work Board, with their own start dates, end dates, status, and portfolio associations. We map each Project to a monday.com Group within the target board. The Project's status field (Active, On Hold, Completed) maps to a monday.com Status column. Start and End dates migrate to Date columns. If a TeamBoard Project is standalone (not inside a Work Board), we create a dedicated monday.com board for it and map the Project to the board's first Group.

TeamBoard Work Items map to monday.com Items. Each Work Item carries TB_Task__c fields for name, description, assignee, status, start date, end date, and priority. We map these to monday.com Text, Person, Status, Date, and Priority columns. Parent-child relationships between Work Items are preserved as monday.com Sub-items (using the Items relationships feature). We resolve the parent reference by matching the child task's TB_ParentTask__c lookup to the parent's TB_Task__c ID at migration time.

TeamBoard Sub-items are work items nested inside a parent Work Item with their own assignees, dates, and status. monday.com supports Sub-items natively. We map each Sub-item record to a monday.com Sub-item attached to the corresponding parent Item, preserving the TB_Task__c status and dates. Note that TeamBoard supports converting a Sub-item to a standalone Work Item; we do not migrate this conversion history.

TeamBoard Resources represent team members or equipment assigned to tasks, with allocation percentage and date ranges stored in assignment records. monday.com does not have a native resource scheduler; we map resource assignments to Person columns on Items (showing who is assigned) and store the allocation percentage in a Number column. If the customer uses monday.com's workload view for capacity planning, we document how to configure it post-migration from the migrated assignment data.

Time entries are logged against Work Items with hours, dates, and user references stored in TB_TimeEntry__c. We map each time entry to a monday.com Item update or, if the customer is on monday.com Pro ($24/user), to the native time tracking column on the item. The date of the time entry, the hours logged, and the user who logged it are preserved. Task association is maintained by resolving the TB_Task__c reference to the migrated monday.com Item ID.

TeamBoard Timesheets aggregate time entries into weekly or period-based views with approval workflow status (Pending, Approved, Rejected). monday.com does not have a native timesheet approval object. We export the timesheet records with their approval status and total hours. We map timesheets to a dedicated monday.com board or to a Group structure within the project board, with the approval status preserved as a read-only Status column. We flag to the customer that the approval workflow itself must be rebuilt as monday.com automations or treated as a manual re-approval step.

TeamBoard Vacation Approval Workflow creates calendar entries and approval records linked to Resources. We extract vacation records with dates, approver, and status. These do not have a direct monday.com equivalent. We map them to a monday.com board with a calendar view, or to the resource's calendar integration if the customer uses monday.com's Calendar integration. Approval status (Pending/Approved/Rejected) resets at migration; the customer's admin decides whether to re-trigger approvals post-migration.

TeamBoard extends its Salesforce custom objects with custom fields for project metadata, risk flags, budget tracking, and client billing information. We perform field-level discovery during schema enumeration, then map each Salesforce custom field to the closest monday.com column type (Text, Number, Date, Dropdown, Toggle, etc.). Complex picklist values from Salesforce become monday.com Dropdown or Status columns. Custom fields with no monday.com equivalent are flagged for the customer to decide whether to carry forward as a Text column or drop.

TeamBoard Task-level custom fields include requirement tracking metadata, effort estimates, story points, and custom status labels. We map these to monday.com column types: numbers to Number columns, text to Text columns, dates to Date columns, and multi-value selections to Dropdown or Tags columns. We flag any formula fields from TeamBoard (computed at read-time in Salesforce) as requiring a monday.com formula column or manual population post-migration.

TeamBoard Reports are configured as Salesforce report types against TB_Project__c, TB_Task__c, and related objects. Report definitions cannot be exported as structured data. We export the underlying data (projects, tasks, time entries, resources) so equivalent monday.com dashboards can be configured post-migration. The customer receives a data export in monday.com-compatible format plus a written report inventory describing what each TeamBoard report shows so their monday.com admin can rebuild equivalent dashboard widgets.