Migrate from Servicely to HubSpot Service Hub

Servicely Tickets (covering incidents, service requests, and problems) map directly to HubSpot Tickets with all standard fields preserved including status, priority, source, ticket owner, and timestamps. We resolve the parent Contact and Company lookups before ticket insert to satisfy HubSpot's referential integrity requirements. Any Servicely custom ticket fields enumerated during the discovery call map to HubSpot custom properties of the equivalent field type. SLA metadata (response deadline, resolution deadline, elapsed time) migrates to custom properties if the destination uses HubSpot's SLA add-on or is noted as text fields for manual tracking.

Servicely Customer records (end-user profiles with contact details and portal association) map to HubSpot Contacts. We preserve email, first name, last name, phone, and any custom properties. The HubSpot Contact is the primary child record that must exist before any associated Ticket is inserted. We deduplicate by email address during import to avoid creating duplicate Contact records.

Servicely Companies (organizational entities linked to tickets and customers) map to HubSpot Companies with company name, domain, and custom properties preserved. The domain field becomes the dedupe key. Companies are loaded before Contacts so that the Company lookup is satisfied at Contact insert time. Any organizational hierarchy in Servicely (parent-company relationships) maps to HubSpot's parent company association.

Servicely Agent records (user profiles with role-based access and assignment permissions) map to HubSpot Users. We resolve agents by email match against the destination HubSpot portal. Any Servicely Agent without a matching HubSpot User goes to a reconciliation queue for the customer's admin to provision before record import resumes. Role and permission set definitions vary by destination platform and require post-migration review by the admin team.

Servicely SLA configurations define response and resolution deadlines tied to ticket priority. We map SLA names and target hours to HubSpot's SLA configuration if the destination account has the SLA add-on enabled, or to custom properties on the Ticket object for manual SLA tracking. SLA enforcement logic does not migrate; HubSpot's SLA enforcement depends on its scheduling engine configuration which the admin rebuilds post-migration.

Servicely Service Catalog items define requestable services with variable fields and approval chains. HubSpot Service Hub does not have a native Service Catalog equivalent; catalog items requiring approval routing must be rebuilt using HubSpot Forms and Workflows post-migration. We migrate catalog item titles, descriptions, and variable field definitions as a written catalog inventory document for the admin to use during the rebuild. Requestable service content without approval routing can map to Knowledge Base articles.

Servicely KB articles (resolution content linked to tickets) migrate to HubSpot Knowledge Base articles with title, body HTML, category, and tags preserved. We recommend using HubSpot's built-in Knowledge Base importer for cleaner results than raw CSV for high-volume KB migrations. Formatting compatibility depends on whether Servicely and HubSpot both use rich text; we flag any HTML tags that may render differently and provide a pre-migration compatibility report for the customer's KB administrator.

File attachments on tickets and knowledge base articles migrate with their original filenames and MIME types. We download from Servicely and re-upload to HubSpot, preserving URL references where the destination supports attachment linking. Inline images embedded in ticket comments or KB article HTML do not migrate as images; they are skipped unless the customer requests they be converted to file attachments first.

Tags applied to tickets and articles for categorization migrate as label arrays to HubSpot Tickets and Knowledge Base articles. No value transformation is required. Tags stored as multi-checkbox custom properties in Servicely map to HubSpot multi-select properties or to tags depending on the customer's preferred organization model selected during scoping.

Servicely's virtual agent and embedded GenAI append resolution notes and suggested fixes to tickets. Depending on the customer's Servicely AI configuration, these are stored as ticket comments or custom note fields. We flag the presence of AI-generated content during scoping and either preserve it as a formatted comment block on the HubSpot Ticket or map it to a dedicated AI-notes custom property if one has been created in the destination account.

Servicely stores workflow trees with activity nodes including comment, user action, approval, complete, scriptable, scriptable async, timer, and if/else branches. We export the workflow JSON during the discovery phase and document every workflow with its trigger conditions, activity sequence, conditional branches, and assigned agents in a written workflow inventory for the customer's HubSpot admin to rebuild using HubSpot's workflow builder. Workflow definitions do not migrate as executable code because HubSpot's visual workflow builder uses a different automation model.

Servicely custom ticket fields and custom company properties that only appear within workflow contexts (not visible in the standard ticket form) require enumeration via the mandatory discovery call before field mapping begins. We map each discovered custom field to a HubSpot custom property of the equivalent type, applying transformation logic for date formats, numeric precision, and picklist value matching. Custom fields that reference other Servicely records via internal IDs map to text fields or lookup properties in HubSpot depending on the target object relationship.