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

TeamBoard Portfolio records represent the highest organizational level, grouping multiple Work Boards. Each Portfolio maps to a Jira Project (or a set of Jira Projects if the customer wants separate projects per Work Board). We use the Portfolio name as the Jira Project key prefix and description, and preserve the portfolio-to-project linkage in a custom Jira field teamboard_portfolio__c for reporting across the project group. If the customer has fewer than 3-5 portfolios, we recommend one Jira Project per Portfolio; larger portfolios may warrant one Project per Work Board within the Jira structure.

TeamBoard WorkZone and Folder entities are organizational layers above Work Boards. Jira has no direct WorkZone equivalent, so we map these to Jira Project components (if the Jira project uses components for team separation) or to Jira labels applied to issues for filtering. The customer chooses the preferred organizational metaphor during scoping based on their Jira project structure.

Each TeamBoard Work Board maps to a Jira Project with a Kanban board configured for the board's column states. We extract the Work Board's column configuration (e.g., To Do, In Progress, Review, Done) and create corresponding Jira status categories on the target project. The Work Board's active/inactive state maps to the Jira Project's archived status.

TeamBoard Work Items are the core tracking entity and map directly to Jira Issues. We use Jira's issue type scheme to represent Work Item types: top-level Work Items become Jira Epics or Stories depending on the customer's sizing convention; sub-items become Jira Tasks or Sub-tasks. The Work Item's status, priority, assignee, start date, and due date migrate to the corresponding Jira Issue fields. Custom fields on the Work Item (TB_CustomField__c values) map to Jira custom fields created during schema setup.

TeamBoard Sub-items (child Work Items with no lower nesting) map to Jira Sub-task issue type. The parent Work Item becomes the Jira parent Issue. We preserve the sub-item order as a custom field sequence number because Jira does not natively enforce sub-item ordering beyond the parent-child relationship.

TeamBoard Resources (team members assigned to tasks) map to Jira Users by email match. Resource allocation percentage and date range (allocation start and end dates) transfer to a Jira custom field pair: allocation_pct__c and allocation_end_date__c. Jira does not have a native resource allocation percentage field, so we store this data in custom fields for use by any Jira resource management app the customer installs post-migration.

TeamBoard time entries linked to Work Items migrate as Jira Worklog records on the corresponding Jira Issue. Each worklog captures the hours logged, the date, and the Jira User (resolved by email from the TeamBoard Resource). Jira's worklog format (started timestamp, time spent in seconds) is generated from the TeamBoard entry date and hours. The original TeamBoard time entry reference ID is preserved in a custom Jira field teamboard_time_entry_id__c for audit purposes.

TeamBoard Timesheets aggregate time entries into period-based views (weekly or custom periods) and carry an approval status (Pending, Approved, Rejected). Jira does not have a native timesheet approval model. We export the timesheet records with their status and date range as a separate JSON artifact. Post-migration, the customer configures a Jira Marketplace timesheet app (Tempo, BigGantt, or Structure) to recreate the period-based aggregation, and the approval workflow is rebuilt using Jira Automation. The historical approval status is stored in a custom Jira field timesheet_approval_status__c for reference.

TeamBoard vacation approval records map to Jira custom fields (vacation_start__c, vacation_end__c, vacation_status__c) on the User record. Jira's native calendar view can display these if the customer enables it, or a Jira Marketplace calendar app (Team Calendar) can surface them. The approval workflow state is not transferred to Jira's system because Jira does not have an equivalent vacation approval model.

TeamBoard extends Salesforce objects with custom fields that are not publicly documented in a schema reference. We run a schema discovery step against the source Salesforce org during migration scoping to enumerate all TB_ custom fields, their API names, data types, and picklist values. Each discovered custom field is created in Jira as a custom field of the equivalent type (text, number, date, picklist, checkbox) before any data import begins. This is a required step that prevents silent data loss on fields not known to exist at migration design time.