Migrate from OpenText Service Request Center (SRC) to HubSpot Service Hub

SRC Service Requests map to HubSpot Tickets. The SRC request category, priority, and status map to HubSpot ticket pipeline, ticket status, and priority properties. We create a dedicated HubSpot ticket pipeline for service requests and configure stage values to match SRC's workflow stages. Original SRC Service Request IDs are preserved in a custom property src_service_request_id__c for audit and cross-reference.

SRC Incidents are distinct from Service Requests and track IT infrastructure disruptions. If the customer maintains separate ITSM processes for incidents, we map incidents to a separate HubSpot ticket pipeline with incident-specific statuses and properties. Impact and urgency fields from SRC become custom priority and urgency properties on the incident pipeline. If the customer consolidates all ticket types into one pipeline, incidents map to the same HubSpot ticket object with a type property set to Incident.

SRC KB Articles map to HubSpot Knowledge Base articles. Article titles, body content, categories, and publish status migrate. SRC HTML-formatted article content is sanitized to HubSpot's markup format during migration, with embedded images downloaded, uploaded to HubSpot's File Manager, and src URLs rewritten to HubSpot-hosted URLs. Articles with tables, multi-column layouts, or iframes are flagged for manual review post-migration. Article-to-ticket associations are preserved as ticket property values referencing the migrated article slug.

SRC user records map to HubSpot Users by email address. Display name, department, and manager hierarchy transfer to HubSpot. Support group memberships map to HubSpot Teams. We flag any SRC user without an email address for admin provisioning. Passwords cannot migrate and require the customer's admin to provision HubSpot login credentials before production cutover. Users active on tickets at migration time are prioritized for User provisioning.

External requesters tracked as Customer records in SRC map to HubSpot Contacts. Contact name, email, phone, and company information migrate. SRC customer-to-ticket associations map to HubSpot ticket-to-contact associations. Note that HubSpot's Contact model differs from SRC's Customer model: Contacts in HubSpot exist within the CRM context alongside Deals and Companies, enabling service reps to see the full customer lifecycle. Any SRC customer without an email address is flagged for manual handling.

Files attached to SRC Service Requests and Incidents migrate as inline HubSpot ticket attachments. We scan for attachments stored in external OpenText Content Suite repositories during discovery; these external references are retrieved and uploaded to HubSpot's File Manager before migration. Attachment filenames and descriptions transfer as metadata. File size limits in HubSpot (500 MB per file) apply; files exceeding this limit are flagged for manual handling or chunked upload. Attachments linked to deleted or archived tickets are excluded unless the customer specifies retention scope.

SRC custom fields on Service Requests are recreated as HubSpot custom ticket properties. Data types map as follows: text fields to single-line text or multi-line text in HubSpot, picklist values to dropdown or radio button properties, date fields to date properties, numeric fields to number properties, and boolean fields to checkbox properties. Validation rules and conditional requireds from SRC cannot be transferred programmatically and are documented for manual recreation in HubSpot's property settings. We map picklist values individually and flag any custom field with a data type that has no HubSpot equivalent.

SRC custom fields on Incidents map to custom ticket properties on the incident pipeline in HubSpot. Impact, urgency, and related CI (Configuration Item) fields migrate as custom text or association properties. Any SRC custom fields referencing configuration items stored in an OpenText Asset Manager or SAM module are flagged during discovery because HubSpot does not have a native IT asset management object and may require a custom object or the HubSpot Asset Management add-on for full reconstruction.

SRC SLA definitions including response time targets, resolution time targets, business hours calendars, and priority-to-SLA mappings do not migrate as data records. We export the SLA configuration as a structured document listing every SLA definition, its trigger conditions, target values, and applicable calendar. The customer's admin configures SLA targets in HubSpot Goals and Help Desk settings manually post-migration. For organizations using SLA tracking heavily, we recommend scheduling a dedicated SLA configuration session during the migration project.

SRC support groups and team structures map to HubSpot Teams. Group names, email routing aliases, and membership lists transfer. Team-to-ticket routing configurations in SRC are documented for the customer's admin to reconfigure using HubSpot's ticket assignment rules and team routing settings. Manager hierarchies within support groups map to HubSpot Team structure where applicable.

SRC Service Catalog items and request offerings are extracted as metadata (name, description, category, available to, estimated response time) and reconstructed in HubSpot Help Desk as request submission forms using HubSpot's form builder or the Professional-tier Help Desk request form feature. Complex catalog hierarchies with conditional routing, approval chains, or integration with financial systems require significant manual rebuild and are scoped separately from the base migration.

SRC workflow definitions are tightly coupled to the platform's internal process engine and are not exportable in a portable format. We do not migrate workflows as code. We document every active workflow including its trigger conditions, routing rules, escalation paths, approval chains, and SLA breach actions. This inventory is delivered as a written playbook for the customer's admin to rebuild using HubSpot's automation tools (ticket pipelines, assignment rules, and notification workflows) post-migration. Workflow rebuild scope should be estimated separately by the customer's implementation team.