Migrate from SMART Service Desk to HubSpot Service Hub

Requests are the core ticket object in SMART Service Desk and map to HubSpot Tickets. We migrate the full request lifecycle including status, priority, category, requester name and email, assigned technician, conversation history, attachments, and SLA timer state. The request's request_id becomes a custom ticket property for traceability. HubSpot's ticket pipeline stages are configured before migration to approximate the SMART request lifecycle stages as closely as the model allows.

HubSpot Service Hub has no native Problem record type. Problems from SMART Service Desk are reconstructed as HubSpot Tickets with a custom picklist field problem_type set to Root Cause or Known Error, a link back to the originating Request via a custom lookup field, and the Problem description, impact, urgency, and priority stored as custom text and picklist properties. We preserve the Problem-Request association through the custom lookup so agents can trace a ticket back to its root-cause Problem record in the migrated data.

Change records in SMART Service Desk carry ITIL-specific lifecycle fields including Change Category (Normal, Standard, Emergency), Risk, Impact, and approval status. HubSpot has no native Change Management object, so Changes are migrated as HubSpot Tickets with a custom picklist field change_category and a multi-select picklist for risk and impact levels. Approval status and CAB membership are stored as custom fields and text blocks; we flag that approval routing requires rebuilding in HubSpot Workflows post-migration. The Change ID sequence is regenerated post-migration unless the customer contacts SMART Service Desk support before migration begins to request a workaround.

Releases carry planned start and end dates, assigned technician, and status. In HubSpot, Releases become Tickets with a custom picklist field record_type set to Release, and the planned deployment window is stored in custom date fields. Release-to-Change associations are preserved as custom text linking the release ticket to the corresponding change tickets migrated in the previous step. If a release management workflow is required, it must be rebuilt as a HubSpot Workflow post-migration.

Assets in SMART Service Desk include workstation records, components, consumables, and allocation details. HubSpot Service Hub has no native asset management object, so we create a HubSpot Custom Object named Asset with fields for name, serial number, type, location, assigned user (as a Contact lookup), and status. Component-to-parent-asset relationships are preserved as Custom Object lookup fields. The asset allocation history migrates as a custom multi-line text field on the Asset record.

SMART Service Desk Solutions are KB articles associated with the self-service portal and agent-facing knowledge base. We migrate article title, body content (with HTML preserved), summary, category, and publication status. Articles linked to specific SMART categories are re-tagged in HubSpot using HubSpot's Knowledge Base category and section structure. Any hyperlinks in article bodies pointing to the SMART Service Desk instance are stripped and flagged in a separate URL mapping table for the customer to update post-import.

Contracts record vendor agreements and SLA terms attached to Requests or Assets. We create a HubSpot Custom Object named Contract with fields for name, type, vendor reference, start date, end date, and SLA tier. Multi-document contract attachments migrate as ContentDocument records linked to the Contract. Associations to Assets are preserved through the Asset custom object lookup established during the asset migration step.

Vendor records in SMART Service Desk store name, contact details, and type. These map to HubSpot Companies with a custom picklist field record_type set to Vendor, preserving vendor name, phone, email, and address. Vendor associations to Purchase Orders and Contracts are preserved through text fields on the related Contract and Purchase Order custom objects. If the customer maintains separate vendor and customer company records, we apply a dedupe key using the company domain.

Purchase Orders link to Vendors and represent procurement records. We create a HubSpot Custom Object named Purchase Order with fields for PO number, vendor reference (as a Company lookup), line items (stored as JSON text or as child Line Item records depending on complexity), total amount, and status. Associations to Assets and Contracts are preserved as custom lookup fields on the Purchase Order.

SMART Service Desk Categories form a taxonomy classifying Requests, Problems, and Changes across multiple levels. We export the full category tree and re-create it in HubSpot as a combination of Ticket pipelines (for high-level separation of issue types) and Tags (for granular category assignment). The customer chooses the pipeline/tag split during scoping. Subcategory depth beyond two levels is flattened into the tag structure since HubSpot's native tagging does not support hierarchical nesting.

User records include name, email, department, site, and role. Active users migrate to HubSpot Contacts with a custom field original_user_id__c for traceability. Technicians migrate as HubSpot Contacts with an additional custom field role set to Technician. Department-level role resolution differs between SMART Service Desk on-premises (resolver based on requester's department) and cloud (resolver based on the request's own department field); we detect the deployment variant during discovery and remap all approval routing rules to match the destination's team-based assignment model.

CAB membership attached to Change records has no direct HubSpot equivalent. We export the CAB member list during discovery, flag each member's approval role and Change associations, and store this as a written inventory document rather than migrating it as data. This inventory documents which CAB roles the customer's admin must re-populate manually in HubSpot, either as team memberships or as tagged Contact records with role notation. Note that CAB members without an active SMART Service Desk login are silently omitted from the export; we cross-reference against the user list during discovery and flag each missing member before migration begins.