Migrate from TeamDynamix IT Service Management to HubSpot Service Hub

TeamDynamix Tickets map to HubSpot Tickets with all standard fields (subject, status, priority, assignee, created date, last modified). Custom Attributes from TeamDynamix (typed fields including text, number, choice, date, and user reference) migrate as HubSpot custom properties. We resolve assignee as a HubSpot user by email match. Priority maps to HubSpot Priority (LOW, MEDIUM, HIGH, URGENT). The TeamDynamix Ticket UID is preserved in a custom property tdx_ticket_id__c for audit and cross-reference.

TeamDynamix Service Catalog entries map to HubSpot Service objects. We transfer the service name, description, category, and published status. TeamDynamix services can link to a Ticket Form, Request Workflow, and associated KB articles; we document these associations and recreate them in HubSpot by linking the service to the migrated KB articles. TeamDynamix service-level SLA settings require manual recreation in HubSpot.

TeamDynamix KB articles (HTML content with category assignment) migrate to HubSpot Knowledge Base articles. We extract article content, title, author, publish status, and article metadata. The category hierarchy requires flattening: TeamDynamix supports multi-level nested KB categories, but HubSpot categorizes articles at the article level rather than maintaining a tree structure. We map top-level categories to HubSpot article categories and document deeper nesting for the customer's admin to reorganize post-migration.

TeamDynamix User and Agent accounts map to HubSpot Contacts. We map email, name, phone, department, and role. Group memberships from TeamDynamix (which support role-based access control) are preserved as a custom property team_group__c holding the group name. HubSpot does not have a native groups model for ticket assignment; teams are managed via the HubSpot user list and shared inbox permissions, which the admin configures post-migration.

TeamDynamix Assets and Configuration Items (hardware, software, CI relationships, and dependency mappings) have no direct HubSpot native equivalent. We create a HubSpot custom object named Asset with custom properties for serial number, asset type, status, purchase date, and vendor. CI relationship records migrate as entries in a second custom object (CI Relationship) with lookup fields to the source and target Asset records. Post-migration linkage between Tickets and Assets requires manual configuration in HubSpot using native associations or a Marketplace app.

Custom Attributes in TeamDynamix (text, number, choice, date, user reference types attached to Tickets and Services) map field-by-field to HubSpot custom properties. Choice-type attributes require explicit option list recreation in HubSpot. We extract the full attribute schema from TeamDynamix, map each to a typed HubSpot property, and provide a configuration script to pre-create all properties before data import. Choice option values migrate as-is; the customer reviews whether any options are retired or renamed.

TeamDynamix Ticket Workflows define the state machine for ticket lifecycle stages with routing rules and escalation triggers. These map to HubSpot Ticket Pipelines and Status values. Each TeamDynamix workflow stage becomes a HubSpot pipeline stage. Escalation triggers and routing rules (for example, auto-assign by category) are documented in the automation inventory as a recommended HubSpot Automation equivalent. We do not rebuild TeamDynamix Workflows as HubSpot Automations; the admin uses the inventory to rebuild them post-migration.

TeamDynamix Ticket Forms control which fields are visible to users and agents during ticket creation and editing. The field list (standard fields plus Custom Attribute references) maps to the set of HubSpot custom properties we create. Form-specific field visibility rules have no HubSpot equivalent and are documented as part of the form configuration inventory for the admin to apply using HubSpot's property display settings per pipeline or ticket type.

TeamDynamix Tags (flat label fields attachable to Tickets and other objects) migrate as HubSpot Tags. We extract all distinct tag values from TeamDynamix and recreate the tag vocabulary in HubSpot. Tags do not conflict with HubSpot Topics; if the customer uses TeamDynamix tags for content classification, we discuss with them whether to use HubSpot Tags or Topics and apply the chosen strategy during migration.

TeamDynamix Service Request Forms control intake for service requests and are separate from Ticket Forms. HubSpot Service Hub has a Forms object for request intake but no equivalent to service-request-specific form logic. We migrate the form field structure and map available fields to HubSpot Form fields, then document the mapping. Advanced form logic (conditional fields, branching) is recreated by the admin in HubSpot Forms using the inventory document we deliver.

TeamDynamix KB Categories organize articles in a hierarchical tree. HubSpot does not support nested KB category hierarchies; articles are categorized individually. We map top-level TeamDynamix KB categories to HubSpot article categories, and we document sub-category hierarchy as an article metadata field that the customer's admin can use to reorganize articles into HubSpot Groups or tags post-migration. Deep nesting beyond two levels requires flattening.

TeamDynamix Project Portfolio Management records (project name, time tracking, governance status, dashboards) have no direct HubSpot Service Hub equivalent. We extract project metadata as a structured inventory and migrate project records to a HubSpot custom object (Project) if the customer has Professional or Enterprise HubSpot tiers. The customer's admin rebuilds project timelines and dashboards using HubSpot tasks, custom reports, or a third-party project management integration. PPM handoff is delivered as a written project inventory document.