Migrate from HelpNinja to HubSpot Service Hub

HelpNinja Customers map to HubSpot Contacts. We match by email address as the dedupe key. First name, last name, phone, and any custom properties on the Customer record migrate to the corresponding HubSpot Contact property. If HelpNinja stores a company name on the Customer record, we optionally create a HubSpot Company record and associate it via the contact-company relationship. Historical timestamps (created_at, updated_at) migrate as custom properties or as the standard HubSpot contact creation date depending on whether the timestamp falls within the customer's retention window.

HelpNinja Customers that carry an organization or company name map to HubSpot Company records. We use the company name as the dedupe key. The Company is created before any Contact import so that the primary Company association is satisfied at the moment of Contact insert. If HelpNinja stores a customer domain, it maps to the HubSpot Company domain property for association logic.

HelpNinja Tickets map to HubSpot Tickets with the ticket ID preserved as a custom property for reconciliation. The HelpNinja ticket subject becomes the HubSpot Ticket subject. Ticket status (open, pending, resolved, closed) maps to HubSpot Ticket status values, which we configure before migration. Priority and category custom properties map to HubSpot custom ticket properties. The original ticket creation timestamp migrates as hs_ticket_originated_date__c.

HelpNinja ticket statuses and any grouping by category map to a HubSpot Ticket Pipeline with custom stage values. We pre-create the pipeline in HubSpot before ticket import, with stage names and order matching HelpNinja's structure as closely as the HubSpot data model allows. If HelpNinja uses a single-status model, we create one pipeline; if it uses category-based routing, we consider creating separate pipelines per category.

HelpNinja Agents map to HubSpot Users resolved by email address. We extract every distinct Agent email from ticket assignments, comments, and status changes and match against the destination HubSpot portal's User table. Any Agent without a matching HubSpot User goes to a reconciliation queue for the customer's admin to provision. If HelpNinja has role-based agent types (admin, agent, viewer), we map these to HubSpot role-based access tiers during the User provisioning phase.

HelpNinja ticket comments and conversation threads map to HubSpot Ticket conversation records. Each comment's author maps to the associated HubSpot User (Agent) or Contact (Customer). Comment body migrates as the conversation message, with attachments preserved as file references. The original comment timestamp preserves thread ordering. Private internal notes in HelpNinja migrate to HubSpot internal ticket notes if supported by the source export; otherwise they are flagged for manual handoff in the migration inventory.

HelpNinja Tags stored on Tickets migrate to HubSpot Ticket custom properties of type multi-select checkbox. If tags represent topic categorization rather than label tagging, we discuss migrating them to HubSpot Topics with TopicAssignment records. The customer chooses tag strategy during scoping based on how they use HelpNinja tags for filtering and reporting.

Any HelpNinja custom fields on Tickets migrate to HubSpot custom ticket properties with type-matched field types (string, number, date, select, multi-select). We pre-create the custom properties in HubSpot before ticket import so that values are accepted on insert. Custom field API names are preserved with a prefix (e.g., hn_) to avoid collision with HubSpot native properties.

Any HelpNinja custom fields on Customers migrate to HubSpot custom contact properties. We pre-create these as HubSpot contact properties before contact import. If the same field name appears on both Customer and Ticket, we treat them as separate properties to avoid schema confusion. String, boolean, date, and number field types map directly; select and multi-select map to HubSpot picklist equivalents.

HelpNinja ticket and comment attachments migrate to HubSpot file storage and are linked to the parent Ticket record via ContentDocumentLink. We handle inline images embedded in comment bodies separately from named file attachments. If HelpNinja's export does not include attachment binary data, we flag this gap and recommend a file URL reference strategy or manual re-upload as part of the post-migration cleanup checklist.

HelpNinja SLA settings (first response time, resolution time targets) migrate as a written inventory to be rebuilt in HubSpot SLA policies if the destination is Professional or Enterprise tier. HubSpot SLA policies require manual configuration in the Service Hub settings and cannot be populated via API import. We document the current HelpNinja SLA values during discovery and deliver them as a configuration guide for the customer's admin.

If HelpNinja includes a knowledge base feature in the customer's tier, articles migrate to HubSpot Knowledge Base articles. HubSpot's knowledge base object structure (title, body, slug, publish status) differs from HelpNinja's; we map article content to HubSpot's rich text body field and preserve the original publish date. HelpNinja article categories map to HubSpot knowledge base sections. We do not migrate article view counts or feedback data as HubSpot does not store these on the article object.