How to Migrate Customer Support Tickets & Data to HubSpot Service Hub

Start by defining the exact support data you want to bring over. In most migrations, that includes tickets, ticket properties, internal notes, customer replies, conversation history, attachments, and the contact and company records tied to each ticket. If a field helps the team route, solve, or report on the ticket, it belongs on the migration list.

The key is to move more than the headline fields. A support ticket is only useful when the team can still see who raised it, what happened, who handled it, and how it was resolved. If that context is missing, the record may exist in HubSpot, but it will not be very useful.

A good migration scope usually includes:

• Ticket subject.
• Ticket description.
• Status.
• Priority.
• Owner.
• Created date.
• Closed date.
• Internal notes.
• Customer replies.
• Attachments.
• Contact associations.
• Company associations.
• Custom support fields.

Before you move anything, review the source support system and confirm what can actually be exported. Some systems make it easy to export ticket records but harder to preserve history, attachments, or relationship data. (Source: Manage tickets in help desk - HubSpot Knowledge Base)

At this stage, decide three things:

• Which tickets are in scope.
• Which historical details must be preserved.
• Which records can be simplified or left out.

This is also the right time to prepare HubSpot itself. Create the properties you will need, set up the ticket pipeline, and make sure your team has agreed on status names, ownership rules, and the way tickets should be organized once they arrive.

If you skip this step, the import may still work, but the data will not be easy to use after the move. A clean plan here saves a lot of cleanup later. For source-system review and scope planning, see Pre-Migration CRM Audit.

Field mapping is where most migrations succeed or fail. Every source field should have a clear destination in HubSpot, and that mapping should be agreed on before the first import starts.

A few common examples:

• Source ticket ID to original ticket ID custom property.
• Subject to ticket subject.
• Description to ticket details.
• Priority to priority field.
• Status to pipeline stage.
• Created date to created timestamp.
• Closed date to closed timestamp.

HubSpot’s ticket object supports properties and associations, so you can structure ticket data in a way that still makes sense after migration. That is why the field map should not be treated as a rough guide. It should be a working document that tells you exactly how each record will land. (Source: CRM API | Tickets)

If you have custom fields in the source system, map only the ones that matter. It is better to import fewer fields cleanly than to import every field badly. For the broader mapping approach, see CRM Data Mapping.

Tickets are much more valuable when they stay connected to the right contact and company. HubSpot supports associations on ticket records, so those links should be part of the migration plan from the start.

The safest sequence is usually:

• Import or match contacts first.
• Import or match companies second.
• Import tickets last.
• Attach each ticket to the correct records using a stable identifier.

Email is often the simplest contact match field. Company domain is often the simplest company match field. If your source data does not match cleanly, define a fallback rule before you import.

For tickets that involve multiple people, decide who should be treated as the primary contact. For tickets with no clear match, flag them instead of forcing a bad association. A wrong association is often worse than no association at all. If you want to preserve data relationships cleanly, review Preserve CRM Data Integrity During a HubSpot Migration.

Conversation history is what gives a support ticket its meaning. A record with only a subject and a status may be enough for reporting, but it is not enough for support work.

Keep the thread readable by preserving:

• Message order.
• Internal notes.
• Customer replies.
• Timestamps.
• Ticket ownership changes if they matter to the case history.

Attachments need the same care. Check file size, file type, and naming before migration. If full attachment import is not practical for every record, use a clear fallback method so the team still knows where the supporting files live.

The goal here is simple. After migration, an agent should still be able to understand the case without going back to the old system.

Once the data model is ready, recreate the support process inside HubSpot. That means rebuilding the pipeline, mapping old statuses to new stages, and setting up any workflow logic that support teams depend on.

Keep this part practical:

• Match old statuses to HubSpot stages.
• Recreate assignment rules.
• Recreate escalation rules.
• Rebuild SLA-related logic.
• Review notifications tied to ticket movement.

If you have automation running in the old system, pause it during the migration window if needed. Then test the rules in a controlled way before turning them back on.

The goal is not to copy the old system line for line. The goal is to make the new system work properly for the team.

A test run is not optional. Use a small sample set that includes open tickets, closed tickets, tickets with attachments, tickets with custom fields, and tickets with multiple associations.

During testing, check four things:

• Record counts match.
• Field mapping works.
• Associations are intact.
• History and attachments still make sense.

HubSpot’s ticket APIs let you work with properties and associations directly, which is useful when you want to validate or troubleshoot records during the migration process. That makes testing easier, but it also makes it more important to confirm the data before you move the full set. (Source: A Developer's Guide to HubSpot CRM Objects: Ticket Object)

If something looks off in the test batch, fix it before the main import. A small error caught early is cheap. The same error after go-live is not.

For a structured validation pass, use HubSpot Migration QA Checklist.

 Do not switch systems in the middle of active support work without a freeze window. Announce the cutover date, stop changes in the source system at the right time, and run a final delta migration to catch anything created after the test run.

After the move, monitor the first 24 to 72 hours closely. Look for missing tickets, broken ownership, incorrect statuses, duplicate records, and workflow issues. This is the period when most hidden migration problems show up.

A smooth cutover is usually the result of good preparation, not luck. 

 The most common problems in a ticket migration are predictable.

Missing associations usually mean the import order was wrong or the matching key was weak. Duplicate tickets usually mean the original ticket ID was not tracked properly. Missing attachments usually come from file handling issues that were not tested early enough. Incorrect timestamps usually come from timezone formatting problems. Broken workflows usually mean a property was missing or mapped incorrectly.

None of these issues are unusual. They are just easier to avoid when the migration plan is clear. 

Can I migrate customer support tickets to HubSpot Service Hub?

Yes. HubSpot’s ticket object is designed to manage support requests, and tickets can be created and associated with related records through the CRM API.

Can I preserve ticket history and attachments?

Yes, but the exact result depends on how your source data exports and how the import process is designed.

How do I keep ticket associations with contacts and companies?

Import or match those records first, then connect the tickets to them using stable identifiers and HubSpot associations. (Source: CRM API | Associations)

Can I keep original ticket IDs?

Yes. Store the source ticket ID in a custom property so the record stays traceable after import.

How do I map old ticket statuses to HubSpot?

Create a status mapping table before migration and make sure each old status has one clear destination in the new pipeline.

How do I avoid duplicates during migration?

Use unique identifiers, check for existing records before import, and validate a sample set before moving the full batch.

How do I test the migration before go-live?

Run a small staged import, compare counts, review sample records, and confirm that associations, history, and attachments look right. For a broader post-migration check, use HubSpot Migration QA Checklist.

 A good support migration keeps the full case context intact. If you preserve the fields, relationships, history, and workflow logic, HubSpot Service Hub can become a reliable new home for your support data instead of just another system filled with disconnected records.

The safest approach is simple. Prepare first, map carefully, test early, and cut over with control. (Source: Manage tickets in help desk - HubSpot Knowledge Base)