Migrate from Servicetonic Helpdesk Tool to HubSpot Service Hub

Servicetonic Incidents map to HubSpot Tickets as the primary ticket record. We map incident status (Open, In Progress, On Hold, Resolved, Closed), priority (Critical, High, Medium, Low), category, and the linked requester profile directly to the corresponding HubSpot Ticket properties. Conversation threads (internal and external) migrate as HubSpot Conversation records attached to the Ticket. The original incident ID is preserved in a custom field st_incident_id__c for cross-reference during the warranty period. Incidents linked to Configuration Items are flagged for CI custom object creation; the CI relationship itself is noted for rebuild in HubSpot custom objects or a linked custom entity.

Servicetonic Service Requests map to HubSpot Tickets with request type preserved as a tag or custom dropdown property. Approval status from Servicetonic (Pending Approval, Approved, Rejected) migrates as a read-only custom field st_approval_status__c; the actual approval workflow must be rebuilt in HubSpot using Salesforce Flow or a third-party approval app. Service Requests linked to Catalog Items are flagged with the catalog item name in a custom field for the admin to rebuild the offering structure.

Servicetonic Knowledge Base articles migrate to HubSpot Knowledge Base articles. We map article title, body content (with HTML preserved where possible), author, visibility settings (internal vs. public), and category hierarchy. Article position and sort order migrate as a manual ordering field since HubSpot Knowledge Base does not have a native position field. Articles with attached files migrate with the attachment preserved as a file link in the article body; the admin reviews post-migration for formatting consistency. The HubSpot native Knowledge Base import tool (knowledge.hubspot.com/knowledge-base/import-knowledge-base-articles) may be used as a supplementary path depending on article volume.

Servicetonic Service Catalog entries (description, price, fulfillment process, linked forms) have no direct HubSpot Service Hub equivalent. We migrate catalog item metadata as a custom object named Service_Offering__c with fields for name, description, price, and fulfillment_process_notes. The actual request fulfillment workflow (multi-step forms, approval routing, automated actions) does not migrate and must be rebuilt in HubSpot using Salesforce Flow or Operations Hub Starter. We deliver a written catalog item inventory with each item's linked Service Request types and recommended Flow design for the admin to implement.

Servicetonic requester profiles (name, email, organization, location, contact preferences) map to HubSpot Contact records. Email address is the dedupe key; duplicate resolution uses HubSpot's default merge rules during import. Organizational affiliation migrates as a lookup to the Company (Account) record. Contact preferences and notification settings do not have a direct HubSpot equivalent and are flagged for manual reconfiguration in HubSpot's Contact property settings. Multi-language contact preferences are preserved as a custom text field st_locale__c.

Servicetonic agent profiles (name, email, team, role, permission level) map to HubSpot User records. We resolve agents by email match against the HubSpot destination portal. Role and permission level mapping depends on whether the destination HubSpot plan includes granular permission sets (Professional and above support team-based roles). Servicetonic agent permissions referencing specific ITIL queues or CI groups are flagged for mapping to HubSpot Teams and individual User permission roles. Agents without a matching HubSpot User are held in a reconciliation queue; the customer's HubSpot admin provisions the account before import resumes.

Servicetonic Configuration Items (CI type, name, location, relationship to other CIs) map to a HubSpot custom object named CI_Record__c. CI type maps to a picklist field, name to a text field, and location to an address field. CI-to-CI relationships (parent-child, dependency, impact) are not natively supported in HubSpot custom objects and are stored as text notes in a relationships__c field; we deliver a written CI relationship diagram for the admin to rebuild using a graph-style custom object or a third-party CMDB app from AppExchange. We do not migrate geolocation data attached to CIs as coordinates unless the destination organization has enabled HubSpot's property-level geo fields.

Servicetonic SLA definitions (response target, resolution target, tied to priority level and time plans) migrate as custom fields on the HubSpot Ticket object: st_sla_response_hours__c and st_sla_resolution_hours__c. The actual SLA policy enforcement (timer display, breach notification, calendar-aware deadlines) is a HubSpot Operations Hub Starter feature ($15/month per seat) and is not natively available in Service Hub alone. We flag every non-standard Servicetonic SLA calendar (time-zone-specific, per-contract business-hour definitions) during the mapping phase and document each one in a written SLA calendar discrepancy report for customer approval before import. The admin rebuilds SLA enforcement using Operations Hub Starter timers or a third-party SLA app post-migration.

Servicetonic Change Records (standard, normal, emergency changes with approval workflows, risk ratings, and implementation plans) have no native HubSpot equivalent. We migrate Change Record metadata (title, type, risk level, status, description) as a custom object named Change_Request__c with custom fields for each attribute. The approval workflow, rollback procedure, and implementation timeline are not portable; we deliver a written change management inventory with recommended Salesforce Flow equivalents for the admin to rebuild. Emergency Change Record escalation chains do not migrate.

Servicetonic Problem Records (linked root cause, known error, workaround, and related Incidents) map to a custom object named Problem__c in HubSpot. We migrate problem title, description, root cause notes, known error status, and workaround text as custom fields. Related Incidents are linked via a text field st_related_incident_ids__c containing the original Servicetonic incident IDs, which the admin can cross-reference using the st_incident_id__c field migrated on the Ticket. Problem-to-Known Error linking does not have a native HubSpot equivalent and requires a third-party ITSM app or a custom relationship design in HubSpot custom objects.

Servicetonic Incident and Service Request conversation threads migrate to HubSpot Conversation records attached to the corresponding Ticket. We map the full message history including internal notes (flagged with a private flag in HubSpot), external replies, attachments (as file links), and timestamps. Author identity resolves to the Contact or User record in HubSpot by email. CC recipients on Servicetonic conversations are preserved in a custom text field st_cc_recipients__c; HubSpot's native ticket CC function is not used because it operates differently from Servicetonic's multi-party thread model.

Servicetonic satisfaction survey responses (CSAT score, NPS, free-text feedback, and survey date) linked to resolved Incidents and Service Requests migrate as a custom object named CSAT_Survey__c with fields for score, survey_type, feedback_text, survey_date, and a lookup to the original Ticket via the st_incident_id__c field. HubSpot Service Hub's native survey functionality (Customer Feedback Surveys) is a separate product tier and is not automatically populated by migration; the admin configures survey delivery rules post-migration if desired.