HubSpot to Front Migration: API Limits, Data Mapping & Methods

Migrating from HubSpot Service Hub to Front is a data-model reconstruction problem. You're taking a CRM-centric system — where tickets, emails, notes, and calls are separate objects connected through an associations layer — and translating it into a conversation-first platform where everything lives as threaded messages inside shared inboxes. The challenge isn't volume. It's that HubSpot fragments what Front treats as a single conversation into five or more discrete API objects, and standard HubSpot exports don't include any of them.

If you only need HubSpot context inside Front — contact details, company info — Front's native HubSpot integration handles one-way contact and company sync. But if you need historical support threads, private notes, call logs, and attachments to live natively in Front, you need an API-led migration that rebuilds HubSpot tickets as Front conversations. (developers.hubspot.com)

This guide covers the exact API constraints on both sides, the complete field mapping between HubSpot objects and Front conversations, every realistic migration method (including why there is no native importer), and the edge cases that cause silent data loss — so you can plan the move without losing ticket history or operational context.

For a deeper look at Front's conversation-based architecture and omni-channel capabilities, see Mastering Front: A Technical Deep Dive. If you're still evaluating whether Front is the right move, Why Forward-Thinking Teams Are Choosing Front covers the strategic case.

Why Migrating from HubSpot to Front Is a Data Model Challenge

HubSpot Service Hub organizes support around tickets — structured CRM records with pipelines, statuses, priorities, owners, and custom properties. The actual conversation content doesn't live on the ticket. Emails, notes, calls, and meetings are separate engagement objects stored at their own API endpoints (/crm/v3/objects/emails, /crm/v3/objects/notes, /crm/v3/objects/calls, etc.) and linked to tickets through HubSpot's associations API. HubSpot's association docs expose separate type IDs for ticket-to-call, ticket-to-email, and ticket-to-note. (developers.hubspot.com)

Front organizes everything around conversations — collaborative message threads that live inside shared inboxes. A conversation contains all its messages, comments, tags, and assignments as a single unit. There is no separate "engagement" layer. You import messages into conversations and add internal comments where needed.

This architectural difference is the root cause of every migration complication:

• A single HubSpot ticket might be associated with 12 emails, 3 notes, 2 calls, and 5 attachments spread across 4 different API object types.
• Reconstructing that into one coherent Front conversation requires fetching the ticket, fetching all associated engagement IDs, fetching each engagement's full content (including HTML body, attachments, and metadata), ordering everything chronologically, and writing it as a single threaded conversation into Front.
• Standard HubSpot exports give you none of this.
• HubSpot's ticket batch read endpoint cannot retrieve associations, so a real extractor has to pull ticket properties, then associations, then the underlying email, note, call, contact, company, and file objects separately. (developers.hubspot.com)

HubSpot Export Limitations: Why CSVs Won't Work

The first thing most teams try is exporting tickets from HubSpot's UI. It won't get you what you need.

Standard UI Export

HubSpot's record export (CRM > Tickets > Export) produces a flat CSV of ticket-level properties only — subject, status, pipeline, priority, owner, create date, and custom fields. It does not include associated engagement data: no email bodies, no internal notes, no call logs, no attachments.

HubSpot's official export documentation confirms that exports download current property values and associations, and directs users to different paths for activities like calls or notes — specifically the engagements API. (knowledge.hubspot.com)

In HubSpot community forums, staff and experienced partners consistently tell users that standard exports do not provide full engagement history and that ticket exports stop at ticket-level properties unless you separately pull associated email engagements. (community.hubspot.com)

CRM Exports API

HubSpot's programmatic CRM Exports API (POST /crm/v3/exports/export/async) has its own constraints: 30 exports per rolling 24-hour window, only one export running at a time, and a default cap of 1,000 associations per row unless you explicitly override it. Large exports exceeding one million rows get partitioned into multiple files delivered as a zip. (developers.hubspot.com)

The export API produces the same flat output as the UI — ticket properties and associated record IDs, but not engagement content. That's acceptable for reporting or backup snapshots. It's not useful for iterative migration runs, retries, and QA re-checks.

What You Actually Need: The Engagements API

To extract the full conversation history behind each ticket, you must use HubSpot's v3 engagement endpoints:

The extraction workflow is multi-step:

1. Fetch all tickets via /crm/v3/objects/tickets (paginated, 200 records max per page)
2. For each ticket, fetch associations: GET /crm/v3/objects/tickets/{ticketId}?associations=emails&associations=notes&associations=calls
3. For each associated engagement ID, fetch the full object with its properties
4. Order engagements chronologically by hs_timestamp
5. Download attachments separately via the Files API

This creates an N+1 query problem at scale. A portal with 50,000 tickets averaging 8 engagements each requires roughly 450,000+ API calls just for extraction — before you've written a single record into Front.

HubSpot API Rate Limits That Matter

HubSpot's general API rate limits vary by subscription tier:

The CRM Search API has a separate, stricter limit: 4 requests per second shared across all search endpoints (contacts, tickets, deals — all share the same pool). If your extraction script uses search queries for filtering or deduplication, this becomes the primary bottleneck.

Batch endpoints help — HubSpot allows up to 100 records per batch request, counting as a single API call. But engagement objects don't support the same batch retrieval patterns as core CRM objects, so you're often stuck making individual calls.

tickets
  -> ticket associations (email, note, call, contact, company)
  -> activity objects (full properties + bodies)
  -> HubSpot files / signed URLs
  -> normalized timeline
  -> Front messages + comments

Front Import API: Limits and Constraints

No Native HubSpot Importer

Front does not offer a native HubSpot import tool. The only built-in importers Front provides are for Freshdesk and Zendesk — and even those have significant limitations. Front's Freshdesk importer, for example, caps at the most recent 9,000 tickets, does not import tags, and is not actively maintained. Front's own documentation recommends working with migration partners such as Help Desk Migration or ClonePartner when the built-in importer falls short. (help.front.com)

Front's published HubSpot integration docs cover CRM actions plus one-way contact and company sync — not historical ticket migration. (front.com)

For HubSpot migrations, your only option is the Front Core API.

The Import Message Endpoint

Front's primary endpoint for historical data migration is:

POST /inboxes/{inbox_id}/imported_messages

This endpoint is designed for importing historical, non-active conversations. Each call creates a message inside a specified inbox, requires a stable external_id, and accepts html or markdown bodies for email messages. The endpoint supports message types including email, sms, intercom, and custom. Attachments are capped at 25 MB per message. Files above that threshold need an alternate storage or link strategy. (dev.frontapp.com)

To build a multi-message conversation (the equivalent of a HubSpot ticket with multiple emails and notes), import the first message, retrieve its conversation_id from the response, then add subsequent messages to that conversation.

Front API Rate Limits

Front's rate limits are tighter than HubSpot's and vary by plan:

Rate limits are enforced per-company, not per-token. If you have other integrations running alongside your migration script, they share the same quota.

The import message endpoint falls under Tier 2 rate limiting — capped at 5 requests per resource per second on top of the global limit. Even on an Enterprise plan, you can import at most ~200 messages per minute globally, and no more than 5 per second to the same inbox. (dev.frontapp.com)

Purchasing Front's API rate limit add-on adds 300 additional calls per minute per add-on, which can help during the migration window. But even with add-ons, a 100,000-message migration at 500 rpm takes over 3 hours of continuous, error-free execution.

When you exceed the limit, Front returns a 429 Too Many Requests response with a Retry-After header. Your script must honor this header exactly — sending additional requests before the retry window resets pushes the delay further into the future. Throwing more threads at the problem usually makes it slower.

Status Mapping Caveat

Base Front conversation status supports open, archived, deleted, and spam. Front only exposes status_id for richer ticket status mapping when ticketing is enabled for the company. HubSpot pipeline stages rarely map 1:1 unless you predesign that status model in Front first. (dev.frontapp.com)

Data Mapping: HubSpot Engagements to Front Conversations

The safest mapping is activity-aware. Don't think ticket-to-ticket. Think ticket shell plus ordered activities.

Ticket → Conversation Mapping

Engagement → Message Mapping

Contacts and Companies

Front contacts are handle-based — the contact API requires email or phone handles. If you're running a phased migration, Front's native HubSpot sync can seed up to 1M contacts and 500K accounts into Front one-way, with field mapping and a 24-hour refresh cycle. That's useful for reference data during coexistence. It is not a substitute for importing historical ticket activity. (front.com)

Audit IDs and Re-run Safety

Make re-runs safe. Use stable external_id values in Front, and store original HubSpot ticket and activity IDs in Front custom fields or tags. Front search supports custom-field-based conversation queries, which makes spot checks and count reconciliation faster after cutover. (dev.frontapp.com)

external_id = hubspot:email:<hubspot_email_id>
external_id = hubspot:note:<hubspot_note_id>
external_id = hubspot:call:<hubspot_call_id>

Edge Cases That Cause Silent Data Loss

Inline images in emails. HubSpot stores inline images as references to its file manager or as base64-encoded content in the hs_email_html body. Front can import HTML bodies and attachments, but there's no one-click inline-image conversion between the two. In practice, you fetch each asset from HubSpot, make it reachable, and rewrite the HTML before import. If HubSpot file URLs expire or require authentication after migration, those images break in Front permanently. (developers.hubspot.com)

Private file attachments. HubSpot's Files API generates signed URLs for private files, but hidden private CRM attachments may require the files.ui_hidden.read scope to retrieve signed URLs. Missing this scope means silent attachment drops during extraction.

Email threading. HubSpot doesn't always store the Message-ID and In-Reply-To email headers that Front uses for native email threading. If these headers are missing, each email imports as a separate conversation instead of being grouped under the original ticket.

Closed ticket timestamps. HubSpot records when a ticket was closed. When importing into Front, if you archive a conversation immediately after import, the archived_at timestamp reflects the migration date, not the original close date. There is no API field to set a historical archive date.

Custom field type mismatches. HubSpot supports field types (calculated fields, score fields, rich text) that have no equivalent in Front's custom fields. These must be flattened to text or number values, or converted to tags.

Multi-pipeline mapping. If your HubSpot instance uses multiple ticket pipelines, each one should map to a separate Front inbox or workspace. Flattening multiple pipelines into a single inbox destroys the operational segmentation your team relies on.

For more on the challenges of CSV-based migrations, see Using CSVs for SaaS Data Migrations: Pros and Cons.

Migration Methods: DIY Scripts vs. Automated Tools vs. ClonePartner

Three realistic approaches. Each has real trade-offs.

DIY API Scripts

How it works: Your engineering team writes custom extraction scripts for HubSpot's API (Python, Node.js, etc.) and import scripts targeting Front's Core API.

Pros:

• Full control over mapping logic and data transformation
• No per-record licensing costs
• Can handle custom objects and edge cases specific to your setup

Cons:

• Severely underestimated effort. The N+1 query pattern for engagements, combined with HubSpot's rate limits and Front's 50–200 rpm ceiling, means a mid-size migration (50K tickets) requires handling 400K+ API calls with retry logic, pagination, error handling, and deduplication.
• The CRM Search API's 4 requests/second limit becomes the bottleneck when filtering tickets by pipeline or date range.
• Attachment handling is a separate project. Downloading files from HubSpot's file manager and re-uploading to Front requires tracking file sizes, MIME types, inline-vs-attached status, and the files.ui_hidden.read scope for private files.
• No delta migration unless you build incremental sync logic. Any tickets created between your initial extract and go-live are lost. Building this adds another week of engineering time.
• Typical timeline: 3–6 weeks of engineering effort for a production-quality script.

Automated Migration Tools

Help Desk Migration (Relokia) positions itself as a self-serve tool for helpdesk-to-helpdesk migrations, offering demo runs, data mapping, delta migration, and inline-image export. Its HubSpot marketplace app also positions the product as a certified HubSpot Service Hub import/export tool. (front.com)

That's attractive when the move is straightforward. The question for a HubSpot-to-Front project is narrower: show me exactly how emails, private notes, calls, and attachments appear in Front on your own dataset before trusting the wizard. HubSpot's fragmented engagement model — where emails, notes, and calls are separate API objects — doesn't always map cleanly to the tool's expected input format. Per-record pricing also gets expensive at scale.

Skyvia is a data integration platform with HubSpot and Front connectors. Good for flat record syncing and ongoing integrations — keeping contacts aligned or feeding Front with current CRM context. It is not marketed as a purpose-built historical thread reconstruction workflow, so treat it as an integration layer, not proof that your support history will land in Front the way agents expect. Syncing flat records works; reconstructing multi-engagement conversation threads does not. (skyvia.com)

ClonePartner (Managed Migration Service)

How it works: Our engineering team builds custom migration scripts tailored to your specific HubSpot instance and Front configuration. We handle extraction, transformation, loading, validation, and a final delta sync.

What you get:

• Full engagement reconstruction. We extract every email, note, call, and attachment associated with each ticket and assemble them into properly threaded Front conversations — with correct sender attribution, chronological ordering, and inline image handling.
• Rate limit engineering. Our scripts handle HubSpot's tiered API limits and Front's per-minute caps with intelligent batching, exponential backoff, and queue management. We've done this across 1,200+ migrations.
• Delta migration. Your team keeps working in HubSpot until the moment of cutover. We run a final incremental sync to capture everything created between the initial migration and go-live — zero downtime, zero data gap.
• Validation and QA. We run automated checks comparing source and target record counts, message content hashes, and attachment integrity before declaring migration complete.

Typical timeline: 3–5 days from kickoff to completed migration, depending on volume and complexity.

Front's own Freshdesk import documentation recommends working with migration partners when built-in importers are limited. That signal applies to HubSpot migrations too — when the history, volume, or timeline is non-trivial, a custom engineering service is usually the safer trade. (help.front.com)

Pre-Migration Checklist

Before any data moves, get these right:

1. Audit your HubSpot data shape. Don't just count tickets. Count how many tickets have associated emails, notes, calls, attachments, multiple contacts, and multiple companies. The ticket row is not enough to estimate effort. (developers.hubspot.com)
2. Map owners to teammates. Export your HubSpot owner list and match each to a Front teammate. Create Front accounts for anyone who doesn't have one yet.
3. Decide what to leave behind. Not every ticket needs to migrate. Spam, test tickets, and ancient closed tickets often aren't worth the API calls. Define a cutoff date.
4. Set up Front before loading history. Create destination inboxes matching your HubSpot pipelines, configure tags, set up custom fields, and define ticket statuses if using Front's ticketing feature. If coexistence matters, decide whether Front's native HubSpot sync will seed contacts and companies while you stage history imports separately. (help.front.com)
5. Request a Front API rate limit increase. If you're on the Professional plan, contact Front to discuss temporary rate limit increases for the migration window. The standard 100 rpm will bottleneck any migration over a few thousand tickets.
6. Freeze HubSpot configuration. Stop adding custom fields, changing pipeline stages, or modifying ticket properties during the migration window. Schema changes mid-migration break mapping scripts.

For a complete pre-migration walkthrough, follow the Front Migration Checklist.

Validating After Migration

Once data is in Front, validate before you go live:

• Spot-check 50 conversations across different pipelines. Verify message ordering, sender attribution, note content, and attachment accessibility.
• Check contact matching. Ensure conversations are linked to the correct Front contacts — especially where HubSpot had multiple email addresses per contact.
• Verify tag and status mapping. Confirm that pipeline stages, priorities, and custom property values translated correctly to Front tags and ticket statuses.
• Test rules and workflows. Imported conversations may or may not trigger Front rules depending on how they were imported. Test before enabling any auto-assignment or auto-tagging rules.
• Confirm attachment integrity. Open a sample of attachments to verify they're downloadable and not corrupted. Check inline images specifically.
• Search by source IDs. If you stored HubSpot ticket IDs in Front custom fields, run searches to verify the lookup works. This is your audit trail for post-migration troubleshooting.

If your team is moving from another helpdesk, the patterns above apply broadly. See our Freshdesk to Front Migration Guide for a parallel walkthrough with a different source system.

What to Do Next

The decision tree is straightforward. If you only need HubSpot context inside Front, use Front's native HubSpot integration for one-way contact and company sync. If you need historical support data, plan an API migration that extracts HubSpot activities and rebuilds them as Front conversations and comments. If the history, volume, or timeline is non-trivial, don't let a CSV export choose the architecture. (front.com)

Before execution, run through our Front Migration Checklist. If anyone on your team is still arguing for flat-file imports, send them Using CSVs for SaaS Data Migrations: Pros and Cons.