Migrate from OTRS to HubSpot Service Hub

OTRS Tickets map directly to HubSpot Tickets. We extract Title, State (open, closed, pending), Priority, Queue assignment, Owner (agent), and CustomerID. Article history becomes conversation entries in the HubSpot timeline. OTRS ticket number is preserved in a custom property otrs_ticket_number__c for audit and cross-reference. We use the HubSpot Tickets API for upserts with ticket_id as the external key.

OTRS Articles (ticket communications: emails, notes, external replies) map to HubSpot conversation timeline entries attached to the Ticket. Each article body, content-type, sender type (agent vs customer), and timestamp migrates. We preserve the chronological ordering by setting the conversation entry timestamp to the original article create date. Attachments referenced in articles migrate as HubSpot file attachments linked to the conversation entry.

OTRS Customer records (name, email, phone, user type, preferences) map to HubSpot Contact. CustomerID from the ticket record resolves to the Contact email as the dedupe key. We run a dedupe pass before import to handle cases where the same customer email appears multiple times in OTRS. Valid email format is required for Contact creation; invalid emails are flagged in a reconciliation report for the customer's admin to clean before re-import.

OTRS Dynamic Fields are enumerated during scoping (field name, type, object attachment). Text, Number, Date, Dropdown, and Checkbox types map to equivalent HubSpot custom property types. Multi-select and EAV-pattern fields with multiple rows per ticket are flattened into delimited strings or migrated as separate custom properties depending on the field structure. Data Hub subscription is required if the customer exceeds HubSpot's standard property limit (500 on Professional, 1,000 on Enterprise). We flag this requirement during scoping.

OTRS Queues define routing and access boundaries. We map each OTRS Queue to a HubSpot Pipeline with a corresponding Team. Queue-based routing rules (e.g., priority assignment by queue) become HubSpot workflow rules triggered on ticket creation or property change. If the customer uses queue-based SLA targets, we preserve those as custom number properties on tickets.

OTRS Agents are matched to HubSpot Users by email. Role, Group, and Queue permissions do not have direct HubSpot equivalents; we map the OTRS role to a HubSpot role (Admin, Agent, Viewer) and assign the user to the corresponding Team. Any OTRS agent without a matching HubSpot user goes to a reconciliation queue for the customer's admin to provision before record import resumes.

OTRS SLA definitions (response time, resolution time, calendar) attach to queues and ticket types. We export SLA names and thresholds as custom number and date properties on each ticket (sla_response_minutes__c, sla_resolution_minutes__c). Escalation events (first response breach, resolution breach) are not native to HubSpot; we store the escalation state as a text property for the customer's admin to design a HubSpot workflow that recreates urgency alerting.

OTRS Configuration Items (CMDB entries) have a class-based schema (Server, Network Device, Software, Contract) with custom attributes. We export CI data and the CI-to-Ticket link table. If the customer has a Data Hub subscription, we migrate CIs as a HubSpot Custom Object (ci_ticket_link__c lookup to Ticket). Without Data Hub, we store CI identifiers as a text property on the related Contact or Company record. CI-to-Ticket associations are preserved as a separate import pass with the link table resolved after both objects exist in HubSpot.

OTRS attachments are binary blobs stored in the database linked to articles. We extract each blob with its filename and MIME type, upload to HubSpot Files via the Files API, and attach to the corresponding conversation entry. PDF, image, and document attachments preserve their original filename. We flag any attachment exceeding HubSpot's file size limit (256 MB per file) and provide a download link in the migration report.

OTRS Services define available offerings linked to SLAs and queues. We export service names, descriptions, and SLA associations as HubSpot Knowledge Base articles with internal tags for service category. The service-to-SLA mapping migrates as article metadata. Service catalog ordering and customer-visible service links require manual recreation in HubSpot's Knowledge Base settings.

OTRS Process Management stores multi-step workflows as XML with activity nodes and transition rules. We export the process structure and deliver it as a written inventory: process name, steps, conditions, responsible agents, and ticket state transitions. This document serves as the specification for rebuilding in HubSpot Workflows. We do not migrate Process Management XML as executable code because the workflow models are incompatible.

OTRS reporting stores report definitions and rendered output in the database. These are proprietary to OTRS and cannot be directly imported into HubSpot. We note this gap in the migration scope and advise rebuilding key reports in HubSpot's analytics tools post-migration. Historical ticket volume data can be extracted as a CSV for manual upload to HubSpot's reporting tools.