Migrate from OpenText Service Manager to HubSpot Service Hub

Service Manager Incidents map to HubSpot Tickets. The Incident ID becomes the Ticket subject or a custom field opentext_incident_id__c, the priority maps to HubSpot Ticket priority (high/medium/low), the assigned technician maps to the HubSpot Owner (resolved by email), and the status maps to the pipeline stage in HubSpot. We preserve the incident type as a custom ticket property inc_type__c so that Incident records remain distinguishable from Request records after migration. Timestamps (created, updated, resolved) migrate as HubSpot Ticket properties for reporting continuity.

Service Manager Service Requests map to HubSpot Tickets with the same mapping pattern as Incidents. The Service Request ID is preserved in a custom field opentext_request_id__c, the fulfillment group maps to HubSpot Owner or Team assignment, and the request category maps to a HubSpot Ticket pipeline or a custom picklist field for category routing. We set a cutover rule to redirect inbound email routing to the HubSpot shared inbox during the cutover window.

Service Manager Knowledge Articles export as structured records with title, body (HTML or RTF), author, publish date, and status (draft/published/archived). We re-import these into HubSpot Knowledge Base via the Knowledge Base API endpoints, mapping the article body directly and preserving publish date and author. If the source articles use a category hierarchy, we replicate it in HubSpot as Knowledge Base sections or topic tags depending on the destination HubSpot edition.

Service Manager Problem records map to HubSpot Tickets using a dedicated ticket pipeline or a custom case type field problem_case__c set to true. The Problem title, description, root cause analysis, and linked Incidents migrate as ticket properties and associations. The Problem-Incident linkage is preserved by creating HubSpot association records or by adding linked_incident_ids__c as a multi-line custom property. If Problems are infrequent in the source, the pipeline approach keeps them visible without requiring a separate HubSpot object.

Service Manager Change records map to HubSpot Tickets with a custom change_case__c flag and structured custom fields for change_type (standard, normal, emergency), risk_rating, implementation date, CAB approval status, and rollback plan. Approval signatures from the CAB process do not migrate as records; we document them as part of the Change audit trail for the customer's admin to attach as Notes in HubSpot. If the customer requires formal Change management tracking, we recommend configuring a dedicated HubSpot ticket pipeline for Changes separate from regular support tickets.

Service Manager users and technicians map to HubSpot Users. We resolve by email address as the dedupe key. Active Service Manager users become active HubSpot users; inactive or suspended users are created as inactive HubSpot users to preserve historical assignment records without granting login access. Role and group membership from Service Manager does not map to HubSpot Roles and Teams as a direct translation; we document the role matrix for the customer's admin to reconfigure in HubSpot Settings post-migration.

Service Manager contacts and requesters map to HubSpot Contacts. The contact name, email, phone, department, and organization fields map to their HubSpot Contact equivalents. If the source contact has a linked Organization record, we resolve it to a HubSpot Company via domain match or explicit name lookup. Contact records with no email address are imported with a placeholder email domain and flagged in the reconciliation report for the customer's admin to complete.

Service Manager Organizations map to HubSpot Companies. The organization name becomes the Company name, and any associated domain fields map to the Company website field for automatic contact-company association. If Service Manager Organizations have hierarchical structures (parent/child), we flatten these in HubSpot as a parent_company__c lookup or a single flat Company list depending on the customer's preference during scoping.

Attachments on Incidents, Requests, Problems, Changes, and Knowledge Articles export as binary files with their association metadata (parent record type, parent record ID, file name, MIME type, upload date). We re-upload them to HubSpot via the Files API and re-attach them to the corresponding Ticket or Knowledge Base article using the file associations API. File size limits on the destination HubSpot account may require splitting large attachment batches; we flag any files exceeding HubSpot's 10 MB per-file limit during scoping.

Service Manager custom fields added to Incident, Request, Problem, or Change records are reproduced in HubSpot as custom Ticket properties. We extract the full field schema during discovery — field name, data type, picklist values, display order, and required flag — and pre-create the corresponding HubSpot custom properties before any ticket data imports. Multi-select picklists, date fields, and numeric fields map directly; lookup fields to related records require additional association mapping to resolve at migration time.

Service Manager CIs represent managed infrastructure assets and their relationships. HubSpot Service Hub has no native CMDB. We map CIs to HubSpot Companies (if they represent customer-accountable assets) or to a HubSpot custom object CI__c (if the customer needs to preserve CI-to-Incident relationships and asset tracking). During scoping, the customer chooses the strategy based on whether CI data is primarily used for asset ownership tracking (Company) or impact and dependency mapping (custom object). CI relationships do not migrate as structured graph data; we document the relationship matrix for the admin to re-enter if a CMDB rebuild is required.

Service Manager SLA records define response and resolution time targets by priority level and service category. In HubSpot Service Hub, SLA policies are available at Professional tier and above. We map the SLA name, first response target (hours), and resolution target (hours) to HubSpot SLA Policy configuration. Priority-to-SLA assignment migrates by mapping Service Manager priority levels to HubSpot Ticket priority values. If Service Manager SLAs are service-scoped rather than global, we configure multiple HubSpot SLA policies and assign them by ticket category using HubSpot's conditional SLA routing.

If the source is OpenText SMAX, the service catalog defines request fulfillment workflows, catalog visibility, and SLA scoping per service. HubSpot Service Hub has no equivalent service catalog object. We map catalog categories to HubSpot Ticket categories or Help Center topics, and map request fulfillment workflow stages to ticket pipeline stages. The workflow binding is not migratable; we document the active catalog workflow definitions as a written specification for the customer's admin to rebuild in HubSpot using Workflows and Breeze Customer Agents.

Service Manager ticket activity logs and internal comments migrate to HubSpot Ticket Engagements of type note. We extract the comment body, author, and timestamp, and insert them into HubSpot via the CRM Associations and Timeline APIs. The chronological order of engagement activity is preserved by setting the engagement timestamp to the original Service Manager timestamp. External customer-facing communications migrate as Ticket conversations if the customer used Service Manager's customer portal; internal-only notes are flagged during scoping for privacy review before import.