The Definitive Guide to Migrating to HubSpot Service Hub

HubSpot, Inc. was founded by Brian Halligan and Dharmesh Shah in 2006 and is headquartered in Cambridge, Massachusetts ¹. Service Hub is the customer-service product inside a broader suite that also includes Sales Hub, Marketing Hub, Content Hub and Data Hub, all sharing the same underlying Smart CRM.

The helpdesk experience is split across two surfaces: the Conversations Inbox for unified email/chat/social threads, and the Help Desk workspace — a ticket-centric UI launched in 2024 to give agents the queues, filters and SLA timers that legacy users expected from Zendesk-style tools.

The typical Service Hub customer is a 10 to 200-seat support team already standardised on HubSpot for sales or marketing, or a B2B SaaS support org consolidating away from a standalone helpdesk. Compared with Zendesk and Freshdesk, Service Hub positions on tighter integration with Contacts, Companies and Deals — a shared graph that means an agent sees deal context on every ticket. Compared with Intercom, it positions on lower per-seat pricing on Professional and a more mature ticketing primitive ⁹.

The shapes of migration that actually land on Service Hub fall into four patterns. First, consolidation projects: a company replacing Zendesk plus a separate live-chat tool with Service Hub's unified Conversations Inbox and Help Desk workspace. Second, Zendesk exits, driven by per-seat price pressure and a desire to use one CRM for sales and support.

Third, legacy replacements — Freshdesk, Help Scout, Kayako, Groove, or a shared inbox like Gmail — where the source schema is loose and the project is really a re-architecture. Fourth, add-on rollouts inside existing HubSpot accounts that already run Sales or Marketing Hub and are now activating Service Hub on top of the same portal.

What makes migrating *to* Service Hub easier than the category average is that Tickets are a first-class CRM object — they share the import tool, the property model and the association engine used by every other Hub. CSV and Excel uploads handle multi-object files via cross-reference columns, and tier-scaled file and row limits run up to 512 MB and 10 million rows per day on paid plans ².

What makes it harder than the average is the helpdesk-specific layer that sits *on top* of the generic CRM. HubSpot does not allow migrating ticket *Created at*, *Updated at* or *Closed at* dates — they re-stamp to import day, which breaks every SLA report you built in the source.

Conversations as a separate object cannot be backfilled with the same fidelity as Notes. Macros, triggers, SLA policies and feedback survey rules do not import at all — they are rebuilt from documentation. Teams that scope for that work up front finish on time; teams that assume parity do not.

Tickets are a CRM object you can import. The Conversations Inbox, macros, SLAs and CSAT history are not — they are rebuild work, and the scope of that rebuild is the whole project.

HubSpot's Smart CRM is built around a small set of standard objects, each with default and custom properties, and associations that connect them. Service Hub does not introduce its own database — it adds object access and behaviour (ticket pipelines, SLAs, knowledge-base authoring, the Help Desk workspace) on top of the same shared schema used by Sales and Marketing Hubs.

Before you can map a field on the source side, you need to know exactly which destination object the row belongs on, what properties it requires, and which value will serve as its upsert key. The table below summarises the objects you will touch in a Service Hub migration.

Tickets do not have a natural unique key, so plan to either let HubSpot assign Record IDs and store them back in the source, or create a custom single-line text property, mark it Require unique values for this property, and use it as your external ID. Once a property is created you cannot retroactively make it unique — plan for this on day one.

Contacts use email as the default unique identifier — two rows with the same email collapse into one record on import ². Companies use company domain name. Knowledge Base articles import via the dedicated KB import tool and use URL slug plus category as their effective key ¹⁴. Custom property types determine validation and storage; the catalogue below covers what you can model and the limits you need to plan around.

Relationships in HubSpot are modelled as associations with optional association labels (for example, a contact labelled *Primary Requester* on a ticket). HubSpot raised the per-record association cap to 50,000 in late 2025, but high-volume support scenarios where one company has tens of thousands of historical tickets still bump that ceiling ⁵.

Custom Objects (Enterprise) are how teams model assets, subscriptions, devices or contracts that tickets associate to. There is no native master-detail cascade-delete: deleting a parent does not delete children, which is a behaviour you reproduce in workflows if your source platform relied on it.

The single best predictor of a clean Service Hub migration is how much work you do on the source side before the first import button is pressed. Help Desk Migration's own checklist warns that any data that fails in the demo migration will fail in the full run — pre-processing is the only place that gets cleaned.

Treat the source export as raw material that needs shaping to HubSpot's expected formats — email lowercased, ticket statuses converted to HubSpot internal values, dates rewritten to ISO-8601, agent emails resolved to HubSpot user IDs.

Any data that fails in the demo migration will fail in the full run. Pre-processing is the only place that gets cleaned.

Source-side prep

• Decide your data horizon — how many years of ticket history you actually need. Migrating 8 years of closed Tier-1 tickets that nobody will ever reference adds cost and noise; most teams cap at 2–3 years and archive the rest.
• Audit and dedup contacts and companies with a third-party tool like Insycle or Koalify — Service Hub inherits the CRM dedup model, and email-case-only duplicates will silently merge once they hit the importer.
• Normalise ticket statuses and priorities — Open, Pending, Solved, Closed in your source need to be mapped to HubSpot ticket-stage internal values per pipeline. Do this in the spreadsheet, not in HubSpot afterward.
• Stamp a stable external ID on every ticket — the source platform's case number — so re-runs and reconciliation are deterministic and so agents can search by legacy ID after cutover.
• Inventory your macros, triggers and SLA policies — print them, classify them as *rebuild*, *redesign* or *retire*. Most teams find half their automations are stale and only a third are worth carrying forward.

Destination-side prep

• Create a sandbox from Settings → Account Management → Sandboxes (Enterprise) or use a standard development account on lower tiers. Dry-run a 20-ticket sample with attachments and conversation history before you scale.
• Provision agents first under Settings → Users and Teams → Create user, using the same email addresses as the source platform — agent identity has to match for ticket ownership to resolve.
• Pre-create every custom ticket property with the right type — single-line text vs single-select matters, and HubSpot will not let you change a created property's type later for many combinations.
• Build ticket pipelines and stages before importing tickets — recreate one pipeline per support queue (e.g. Tier 1, Tier 2, Billing) with the stages and SLA timers you need. Tickets that target a non-existent stage on the named pipeline are rejected.
• Set up the Conversations Inbox and channel connections (email forwarder, chat, social) — but do *not* turn on the live channels until after cutover, or new messages will mix with the backfill.

People prep

Cutover only works if humans cooperate. Lock down a source-system freeze window — typically 24 to 72 hours for a helpdesk, scheduled over a weekend to minimise live-ticket disruption — and communicate it across customer support, customer success and any sales reps who watch tickets. Train agents on the Help Desk workspace, ticket views, and the rebuilt macros before go-live, not after.

HubSpot exposes several load paths for a Service Hub migration and the right one depends on object type and dataset size. The UI Import Tool handles Tickets, Contacts and Companies. The Knowledge Base importer is its own purpose-built tool. Third-party staging tools like Help Desk Migration sit on top of all of them and add source-platform extraction, schema translation and attachment handling.

UI Import Tool

The native import lives at Settings → Data Management → Data Integration → Import, or by clicking Import in the top right of any object index page. There are two modes: Quick Import for a single object with auto-mapped property names, and Advanced Import for full mapping control, multi-object files, and association creation. HubSpot ships a dedicated Tickets sample spreadsheet to demonstrate the expected column set ¹⁶.

Limits are tier-scaled: free accounts get 20 MB files, 50 imports/day and 500,000 rows/day; Starter, Professional and Enterprise accounts get 512 MB files, 500 imports/day, 10,000,000 rows/day, and up to 1,048,576 rows per individual file ². Up to three imports run simultaneously, and only two can exceed 10,000 rows. The right call: UI for one-shot Ticket and Contact loads under 100k records, or any time you want a visual mapping review before commit.

Knowledge Base importer

Knowledge Base articles do not go through the CRM import tool. The dedicated KB importer is at Settings → Content → Knowledge Base → Current view → Import knowledge base and accepts a CSV with columns for Title, Article Body (HTML source), Meta description, Category, Subcategory, Tags (comma-separated) and Keywords ¹⁴. The importer is published only on Service Hub Professional and Enterprise — teams on Starter migrate KB content by hand or via a partner tool.

Third-party staging tools

Help Desk Migration, Import2 and Suprdense's SuprSwitch are purpose-built for helpdesk-to-HubSpot moves. They handle the source-platform extraction (Zendesk, Freshdesk, Help Scout, Intercom, Jira Service Management and a long tail of others), the schema translation, the file/attachment fetch-and-attach, and the conversation threading that the generic CRM import does not handle natively. Most run a Demo Migration of 20 sample tickets before committing to the full run, and most support Delta Migration to catch records that change during the cutover window.

Mapping is where every helpdesk migration earns its scars. The schema decisions you make determine whether SLA reports work on day two, whether macros fire on day five, and whether your agents trust the queue on day thirty.

Work object by object, top to bottom of the import order: Companies first (so contacts and tickets can associate to them), then Contacts, then Tickets, then Conversations and Activities, then Knowledge Base articles, then Feedback submissions and Custom Objects.

Contacts and Companies

Tickets and pipelines

Recreate every pipeline and every ticket stage in HubSpot before importing tickets. The Help Desk Migration tool defaults all tickets into a single pipeline — if you need source groups mapped to different HubSpot pipelines, that is custom work. Each ticket stage has an internal value (commonly 1, 2, 3, 4 for New, Waiting on contact, Waiting on us, Closed) which you reference in the import file, not the display label.

Ticket history and conversation threading

This is where source platforms differ most and where the cleanest migrations spend the most planning time. Zendesk stores ticket history across CaseComment (public/internal comments), EmailMessage (email threads), CaseHistory (field-change audit) and FeedItem (Chatter-style posts). Salesforce Service Cloud uses the same pattern with different object names. HubSpot Service Hub uses a flatter model — every ticket has a timeline populated by Notes, Emails, Calls, Tasks and Meetings, all associated as engagements, plus Conversations objects for the threaded inbox view.

The practical pattern: split source comments into three buckets — public-facing replies map to Emails (engagement type EMAIL), internal comments map to Notes (hs_note_body with the comment text and hs_timestamp preserving the original date), and field-change audit history is captured into a custom Ticket History (Legacy) multi-line text property because HubSpot has no native per-field audit log on tickets.

Conversations Inbox and multi-channel routing

The Conversations Inbox is HubSpot's unified channel object — email, chat, Facebook Messenger, WhatsApp, calls and form submissions land here as conversation threads before (or alongside) becoming tickets. Conversations themselves are not imported with the same fidelity as Tickets. Most teams map source channel threads to a Ticket with the conversation body captured as Email engagements, leaving the live Conversations Inbox to backfill forward from cutover day.

Channel connectors (email forwarder, Facebook, WhatsApp, calling) are set up *after* the historical import — under Inbox & Help Desk settings — and the routing rules that send conversations to inboxes or agents are configured live, not migrated.

Knowledge Base articles, categories and translations

Knowledge Base content has its own importer at Settings → Content → Knowledge Base ¹⁴. The CSV columns are URL slug, Title, Subtitle, Category (required), Subcategory, Tags (comma-separated, no spaces after the comma or the import errors), Keywords, Meta description (required) and Article Body (HTML source — required) ¹⁴. Images inside articles must be referenced by URL — HubSpot does not bulk-upload binary images during KB import.

Multi-language support is handled by uploading each language as a separate import and linking translations via the article's language variant settings. Each article has a 100-tag ceiling on the new KB editor — articles with more need pruning before import ¹⁷. Service Hub Enterprise allows multiple knowledge bases; Pro is capped at one.

Macros, triggers, workflows and SLA rebuild

None of these import. Zendesk Triggers, Freshdesk Automations and Help Scout Workflows are all rebuilt as HubSpot Workflows under Automations → Workflows after the data is loaded. Macros (the canned-response style) become Snippets or Templates in HubSpot. SLA policies become SLA configurations on the ticket pipeline under Service settings — they cannot be backfilled with historical SLA breach data, so any historical SLA report stops at cutover day.

The judgment call most teams underestimate: not every source automation is worth rebuilding. Print the trigger/macro inventory, classify each as *rebuild*, *redesign* or *retire*. Teams routinely discover half their macros are stale and only a third merit the work.

CSAT, NPS and CES survey history

Feedback surveys are a Service Hub Pro/Enterprise feature. Historical survey scores from a source platform are imported as Feedback submission records associated to the contact and (where possible) the ticket, with the score in a numeric property, the survey type (CSAT/NPS/CES), the response text in a multi-line text property, and the submitted date preserved in a custom datetime property. The live survey machinery — embedded survey emails, the in-product CSAT prompt, the NPS schedule — is configured live in HubSpot, not migrated.

Files and attachments

Attachments do not import in bulk via the CSV UI flow. The supported path is to upload each binary into the HubSpot Files tool and attach it to a Note that is then associated with the ticket. Specialist helpdesk migration tools automate this loop, including the option to convert inline images in source ticket bodies into proper attachments. Customer Portal attachments are capped at 50 MB; one-to-one email attachments at 20 MB ⁸.

Audit trail, ownership and original timestamps

Standard createdate, hs_object_id, hs_createdate and hs_lastmodifieddate are HubSpot-managed system properties — they cannot be overwritten during import. For tickets specifically, HubSpot does not allow migrating ticket Created at, Updated at, or Closed at dates to Service Hub. That means SLA dashboards filtered on those system fields will treat every imported ticket as created on import day.

The pattern: create three custom properties per ticket — *Legacy Created Date*, *Legacy Closed Date*, *Legacy Updated Date* — populate them from the source export, and rewrite every historical-period support report to filter on the legacy fields. Owner assignment during import works only if the agent email exists at the moment of import; rows whose owner cannot be resolved are imported with no owner set, which silently breaks downstream owner-based routing.

Validation is the bridge between the import finishing and agents being allowed in. The Help Desk Migration playbook recommends a three-stage validation: a Demo Migration of 20 tickets and 20 articles with stakeholder spot-checks, the full load with real-time monitoring of record counts and attachment integrity, and a 30-day post-migration data-quality audit. The most reliable signal is having support team leads verify their own queues — they know what right looks like better than any reconciliation script.

Build a reconciliation queries spreadsheet that compares source and destination on each of these counts. Anything outside a 0.5 percent variance gets investigated before agents get login access.

• Total tickets imported per pipeline per stage vs source — and a date-bucketed comparison against *Legacy Created Date* to confirm the historical distribution survived.
• Total contacts and companies vs source — checking that domain-based collapse did not over-merge support requesters who use the same generic vendor email.
• Total ticket comments and emails per ticket — sampling 100 random tickets and counting Notes + Emails on the HubSpot timeline against the source thread length.
• Attachments — download a sample of attachments from imported tickets and confirm the binaries match the source, particularly for inline images that the migrator converted to attachments.
• Associations per object type — count ticket→contact, ticket→company and ticket→deal associations and compare against the source-derived expected counts.
• Agent ownership distribution — GROUP BY hubspot_owner_id and confirm no ticket landed unowned that should not have, and that deactivated source agents were reassigned.
• Knowledge Base — count articles per category, count translations per article, and verify the meta description, URL slug and tags imported cleanly on a 30-article sample.

On top of reconciliation, run a manual spot-check protocol: pick 30 random tickets across age and priority, and verify each field against the source UI. Pick five high-touch tickets with long conversation threads and trace the full timeline. If a non-trivial discrepancy shows up in three or more of the 30, halt the load, fix the root cause, and re-import the affected tickets by external ID.

HubSpot ships Restore CRM Properties and Records, which captures the last 20 versions of every property change (45 for contacts) and lets super admins undo changes from the last 14 days via Settings → Data Management → Backup and Restore. This is the closest thing to a native undo, but it is not a bulk-rollback button — it works property-by-property.

The real rollback strategy: export everything to S3 before the import starts, stamp every imported ticket with an *Import Batch ID* custom property, and if catastrophe strikes, bulk-delete by that batch ID and re-import from the cleaned source.

Cutover sequencing: (1) source helpdesk goes read-only; (2) final delta export captures every ticket that changed during the test-import window — most specialist tools support Delta Migration explicitly; (3) delta is imported; (4) reconciliation runs; (5) channels are switched (email forwarder, chat widget, social) so new conversations land in HubSpot; (6) agents get login access and a 48-hour hyper-care window; (7) source decommission is scheduled 30 to 90 days out.

The HubSpot Solutions Partner Program tiers Elite, Diamond, Platinum and Gold partners by certifications, customer count and revenue. For Service Hub migrations specifically, partners with explicit Zendesk-to-HubSpot, Freshdesk-to-HubSpot or Help Scout-to-HubSpot practices tend to ship cleaner than generalist implementation shops. Origin 63, Incremental, Impulse Creative, SmartBug Media and Infinite Renewals are commonly named on the helpdesk side of the partner directory.

HubSpot itself charges a one-time onboarding fee — $1,500 on Service Hub Professional and higher amounts on Enterprise ⁹ — and some partners waive that fee in exchange for the implementation contract.

For self-service automated tooling, Help Desk Migration is the most widely cited specialist — it supports 30+ source helpdesks, runs a free Demo Migration, is SOC 2 Type II and GDPR-aligned, and prices by record count plus options. Import2 offers a similar one-click model with a money-back guarantee. Suprdense's SuprSwitch focuses on HubSpot-to-HubSpot and helpdesk-to-HubSpot moves with intelligent mapping.

On the ETL and iPaaS side, Fivetran, Airbyte, Workato and MuleSoft have HubSpot connectors. Their role in a helpdesk migration is rarely the migration itself — it is the ongoing sync layer that takes over once the one-time migration is complete, keeping HubSpot Service Hub in sync with a data warehouse, a billing system or a product analytics tool.

Managed-migration cost ranges vary widely. A clean Help Scout-to-Service Hub move of under 10,000 tickets with no Knowledge Base typically lands in the £2,500–£7,500 / $3,000–$10,000 range — Incremental's published model starts at £500 for setup and adds packages by record count.

A Zendesk-to-Service Hub project with 100,000 tickets, KB articles, custom fields, macros to rebuild and SLAs to redesign typically runs $25,000–$120,000, with the upper end driven by ticket count, custom-field complexity, conversation-thread depth and the number of automations rebuilt.

For teams that want to outsource the migration end-to-end, FlitStack specialises in HubSpot Service Hub migrations and handles the field mapping, ticket-pipeline design, Knowledge Base import, attachment fetching, picklist internal-value conversion, and the validation work described in Sections 5 and 7 of this guide. Pricing is fixed-fee, based on ticket count and source platform, with separate line items for KB articles, Custom Objects and macros-to-workflows rebuild scope so the cost is transparent before signature.

This is one of several legitimate paths — the right choice for any given team depends on whether they want a Solutions Partner, HubSpot's in-house onboarding, an automated specialist tool, or a managed migration vendor. Explore FlitStack →