Migrate from HelpDeskEddy to HubSpot Service Hub

HelpDeskEddy Tickets map directly to HubSpot Tickets. Status values (open, in-progress, resolved) map to HubSpot Ticket Status pipeline stages; priority maps to Ticket Priority. The ticket body (description, subject) migrates as Ticket description. We resolve the requester (HelpDeskEddy Customer) to a HubSpot Contact at migration time so the Ticket association is satisfied. Custom fields on each ticket are flattened by field name across the migration scope and mapped to typed HubSpot Ticket properties.

HelpDeskEddy Customers map to HubSpot Contacts with name, email, phone, and any associated custom properties preserved. We deduplicate by email during import to avoid creating duplicate Contact records. Contacts are created before Ticket import so that the Ticket-to-Contact association is satisfied at insert time. If HelpDeskEddy stores a customer as both a ticket requester and an agent, we map the agent-facing record separately as a HubSpot User and flag it for the customer's admin to verify permissions.

HelpDeskEddy Operators map to HubSpot Users. We resolve by email match against the destination HubSpot portal's user table. Any HelpDeskEddy operator without a matching HubSpot User is placed in a reconciliation queue for the customer's admin to provision before Ticket import resumes. Role and permission parity (HelpDeskEddy's operator access levels vs HubSpot's seat-based roles) is documented for the admin to configure post-migration.

HelpDeskEddy Departments map to HubSpot Teams. We preserve the department hierarchy and apply the membership assignments at the Team level in HubSpot. If HelpDeskEddy has nested departments (sub-departments within a parent), we map them to HubSpot Teams with the parent-child relationship documented for the admin to configure in HubSpot's Team settings. Department-level access controls require manual application in HubSpot post-migration.

HelpDeskEddy's per-ticket individual custom fields require explicit field-type mapping. We enumerate all observed custom field names across the migration scope, deduplicate by name, and map each to a typed HubSpot Ticket property (text, number, date, single-checkbox, dropdown). Tickets with no value for a mapped field receive an empty property at the destination, which is expected behavior. Unsupported field types (for example, HelpDeskEddy field types with no HubSpot equivalent) are flagged in the field inventory for the customer's admin to handle manually.

HelpDeskEddy Tags migrate to HubSpot Ticket Tags. We preserve tag names as-is and apply them to the corresponding Ticket records at the destination. HubSpot's tag taxonomy is flat (no hierarchy), so if HelpDeskEddy uses hierarchical tags (parent/child), we flatten to the most granular level and document the original structure for the admin to rebuild as labels if needed.

HelpDeskEddy time-tracking data attached to tickets migrates as a custom numeric property on the HubSpot Ticket (for example, time_spent_hours__c). HubSpot Service Hub does not have a native time-entry sub-object at the Ticket level, so we store time values as a custom number property. If the customer requires billable hours tracking at a granular level, we flag this as a post-migration configuration for a time-tracking integration (such as a HubSpot Marketplace app) or a custom object.

HelpDeskEddy CSAT ratings migrate to a custom numeric or rating property on the HubSpot Ticket (for example, csat_score__c). If HelpDeskEddy stores the rating as a scale (1-5) and HubSpot uses a different scale, we flag the mismatch and store the original numeric value with a note in the property description. CSAT ratings are not stored as a separate object in HubSpot Service Hub at the Starter tier; they require a custom property or an upgrade to Professional for the built-in CSAT tracking feature.

HelpDeskEddy Knowledge Base articles migrate as HubSpot Knowledge Base articles with body content, article status (published/draft), and associated tags preserved. We use HubSpot's Knowledge Base Importer for the article migration path, which handles article body and category assignment natively. Articles are migrated as independent records; article-to-ticket associations (HelpDeskEddy's KB linking) are documented in the migration inventory for the admin to re-establish in HubSpot's knowledge base linking settings. Public-facing KB URLs will differ at the destination.

HelpDeskEddy chat channel logs migrate as conversation entries (TicketComments) attached to the originating HubSpot Ticket. We map chat timestamps, agent name, and message body; the agent name resolves to the corresponding HubSpot User via the email match. Rich media embedded in chat messages (images, file attachments) may require separate handling; we flag unsupported content types during the discovery pass. Inline images within chat messages cannot migrate per HubSpot Service Hub data migration checklist limitations.

Ticket attachments from HelpDeskEddy migrate to Files attached to the corresponding HubSpot Ticket record. We use the HubSpot Files API to upload each attachment and associate it via the ticket-attachments relationship. Attachment file types are preserved. If the attachment count per ticket is large (exceeding HubSpot's per-record attachment limit of 10), we split across multiple attachment records and document the grouping for the admin.

HelpDeskEddy macros reference internal field IDs, UI elements, and dispatcher engine states that have no equivalent in HubSpot Service Hub. We do not migrate macro definitions as code. We audit every HelpDeskEddy macro, document its trigger conditions and actions, and deliver a macro inventory with recommended HubSpot workflow equivalents. The customer's admin rebuilds automation logic in HubSpot's workflow builder post-migration. This is standard scope for all help desk-to-HubSpot migrations.

HelpDeskEddy's Yandex Datalens dashboards are reporting artifacts built on top of ticket data with platform-specific metric definitions. We do not migrate analytics dashboards. We deliver a written inventory of every HelpDeskEddy report configuration (report type, filters, metrics) for the customer's admin to rebuild using HubSpot Service Hub's built-in reporting or a connected analytics tool. If the customer uses a BI tool like Yandex Datalens for cross-platform reporting, we document the HubSpot data export options for reconnection post-migration.

HelpDeskEddy's ticket status values (open, in-progress, resolved) and any custom status labels map to HubSpot Ticket Pipeline stages. We configure the destination pipeline in HubSpot before migration, matching the number of stages and their labels to the HelpDeskEddy configuration. If HelpDeskEddy uses multiple ticket queues with different status sets, we map each to a separate HubSpot Ticket pipeline and assign the appropriate Record Type. Stage ordering and probabilities are preserved based on the HelpDeskEddy status configuration.