How Long Does a 500,000-Ticket Help Desk Migration Take?

How Long Does a 500,000-Ticket Help Desk Migration Take?

At 500,000 tickets, the data migration portion of a help desk move typically runs 7–13+ business days with a managed service, or 6–12+ weeks if you're building and running scripts yourself. The binding constraint isn't compute power or network bandwidth — it's how many API calls the source and target platforms allow per minute.

This article breaks down the rate-limit arithmetic that governs every large-scale help desk migration, shows you what "500K tickets" actually means in API operations, explains what breaks at this scale that doesn't break at 50K, and explains how to plan so the data transfer doesn't become your project's critical path.

Keep two clocks apart

The 7–13+ business day figure describes the data migration — extracting records from your old help desk, transforming them, and loading them into the new one. It does not include your broader replatforming work: rebuilding automations and workflows, reconfiguring integrations, retraining agents, or running systems in parallel.

Rebuilding routing rules, training agents on a new interface, and restructuring your knowledge base is a separate effort measured in months. The data transfer and the application rebuild are different work streams with different owners and different timelines.

Olark's published account of moving 500K+ cases to Help Scout reinforces this distinction — their write-up spends as much attention on rerouting email and chat channels, rebuilding filters, handling custom fields, and training a 40-person team as it does on the case archive itself. (olark.com)

When migrating 500,000 tickets, start scoping at least 3–4 months before your internal deadline. That buffer covers data auditing, field mapping, sample migrations, the bulk transfer window, and delta syncs — not because the transfer pipe needs months, but because permissions, field decisions, stakeholder sign-off, and cutover rehearsal take calendar time.

Why 500K tickets is a data-shape problem, not a record-count problem

Data shape is the real structure behind the ticket count: comments, internal notes, attachments, inline images, authors, timestamps, users, organizations, tags, custom fields, and cross-links.

At 500,000 tickets, the expensive part is rarely creating 500,000 ticket shells. The expensive part is recreating 500,000 histories faithfully. Each ticket carries:

• Comments and replies — the average support ticket has 3–8 threaded replies, each requiring a separate API call to read or write. At 5 comments per ticket, that's 2.5 million comment operations alone.
• Attachments — screenshots, log files, signed documents. Each must be downloaded from the source and uploaded to the target individually.
• Custom field values, tags, and user associations — every ticket links to contacts, organizations, and agents that must already exist in the target before the ticket can reference them. If you are consolidating platforms—such as a Zendesk to HubSpot migration—preserving these cross-object associations is often the most complex part of the project.

A dataset labeled "500K tickets" often represents 3–5 million total API operations once you count comments, attachments, and prerequisite objects.

effective volume ≠ ticket count
 
effective volume ≈
  ticket shells
+ comments and notes
+ attachments and inline images
+ users / orgs / tags
+ custom field translations
+ validation passes
+ delta changes during the bulk run

Before you estimate time, answer these questions:

• How many comments does the average ticket have? What does the 95th percentile look like?
• How many attachments per ticket, and how large are they?
• How many unique users, agents, and organizations need deduplication or remapping?
• Which custom statuses, fields, forms, and tags exist in the source but not the target?
• How much data will keep changing while the bulk migration is running?

If you don't size the project by data shape, the date is a guess.

How API rate limits set the timeline ceiling

API rate limits are hard restrictions set by software vendors on how many requests an account can make per minute. The formula is straightforward:

Total API calls ÷ platform rate limit per minute = minimum transfer minutes.

The result is the theoretical floor — the fastest possible time assuming zero errors, zero retries, and perfectly saturated connections. In practice, sustained throughput runs below documented limits due to burst guards, connection overhead, and retry back-off. The sections below note where documented limits and observed sustained throughput diverge.

Worked example: Zendesk Enterprise → Freshdesk Enterprise at 500K tickets

Read side (extracting from Zendesk):

• Ticket metadata via incremental export: ~50 minutes. This endpoint returns up to 1,000 records per page at 10 requests/minute.
• Comments for 500K tickets at 700 requests/minute (Enterprise-tier general limit): ~12 hours. Each ticket needs at least one GET to fetch its conversation thread.
• Attachment downloads: bandwidth-bound rather than strictly API-limited, but still hours for large volumes.

Write side (importing to Freshdesk):

• Ticket creation at Freshdesk Enterprise's sub-limit of 280 ticket-creates/minute: ~30 hours.
• Threading 2.5M comments via reply/note endpoints: ~6+ days, depending on which sub-limits apply.
• Attachment uploads: additional hours depending on file sizes and upload endpoint throttling.

Theoretical minimum at Enterprise tier: ~8–10 days of continuous processing. Factor in retries from transient errors (typically 3–8% of API calls on high-volume runs), rate-limit back-off windows, validation passes, and edge cases — HTML encoding errors, oversized attachments, orphaned records — and you reach 10–13+ business days for the data migration alone.

Drop to a lower-tier plan — Zendesk Team at 200 requests/minute, Freshdesk Growth with ticket-create sub-limits as low as 50–80/minute — and the same migration stretches to 4+ weeks of continuous runtime.

Help desk API rate limits at a glance

Sources: Zendesk, Freshdesk, Help Scout, Intercom, Front, and HubSpot developer documentation. (developers.freshdesk.com)

Intercom's limits look generous at 10,000/min, but conversation parts (comments) are only returned on single-conversation retrieval — not on list or search endpoints. For 500K conversations, you still need 500K individual GET requests to read thread contents. Attachment URLs expire after 30 minutes, forcing immediate download during extraction rather than batch processing later. This structural constraint eliminates most of the apparent throughput advantage.

The pagination degradation problem

At 500,000 records, API pagination methods become a constraint of their own.

Offset-based pagination (e.g., page=50000&per_page=10) forces the source database to scan and discard tens of thousands of rows before returning the requested batch. At deep page depths, this causes severe latency and HTTP 504 Gateway Timeout errors. Freshdesk's docs explicitly warn against page numbers over 500 — which means offset pagination caps reliable extraction at 50,000 records per endpoint call series, not 500,000. (developers.freshdesk.com)

Cursor-based pagination passes a pointer to fetch the next batch in constant time — far better at scale. If your source system relies on offset pagination, extracting half a million tickets requires windowed extraction by date range or ID partition to stay inside workable page depths.

Practical implication: a naive page=1..5000 crawler against a Freshdesk account will fail or time out well before reaching your full ticket history. Windowed extraction — partitioning by created_at date range into segments of ≤50,000 tickets each — is the correct design for offset-paginated sources.

What breaks at 500K that doesn't break at 50K

Problems that are edge cases at 50,000 tickets become routine at 500,000. A structured risk register for this scale:

These failure modes do not surface during 50K-ticket test migrations unless you specifically sample from the tail of your data distribution. Sampling strategy matters: always include your oldest tickets, your largest tickets by attachment size, and tickets with the highest comment counts in any pre-migration sample run.

Why attachments dominate transfer time at scale

Ticket metadata is small — a few KB per record. Attachments are not. A single ticket with three screenshots and a PDF can carry 10–30 MB of files. At 500,000 tickets, even a conservative 20% attachment rate with an average of 2 files per attached ticket produces:

• 100,000 tickets × 2 files = 200,000 file transfers
• At 5 MB average per file: ~1 TB of data to download and re-upload

To move an attachment, the migration process must:

1. Request a secure download URL from the source system's storage (e.g., AWS S3).
2. Stream the file into temporary staging.
3. Upload the file to the target system's storage.
4. Map the new target URL back into the specific comment or ticket description where it originally appeared.

Target platforms often throttle upload endpoints separately from general API limits, and some impose per-file size caps (Freshdesk at 20 MB per request, Zendesk at 50 MB, Front at 25 MB). Oversized files can fail silently if not handled in advance — the API returns a success response for the ticket record while the attachment write fails independently.

Applying the rate-limit arithmetic to attachment volume: at a sustained transfer rate of 50 files/minute (accounting for upload throttling and staging overhead), 200,000 attachments represent approximately 66 hours of continuous transfer time on top of ticket and comment operations. A 500K-ticket dataset with minimal attachments migrates measurably faster than a 200K-ticket dataset where every ticket has five screenshots. Attachment volume measured in GB, not record count, is evaluated before quoting a timeline.

Quantified impact of scope reduction

Reducing scope is the single most effective way to shorten your timeline. The arithmetic makes this concrete.

Scenario: archive tickets older than 24 months, reducing from 500K to 200K tickets.

Assumptions: Freshdesk Enterprise target (280 ticket-creates/minute), 5 comments per ticket average, 20% attachment rate.

• Ticket-create operations eliminated: 300,000 ÷ 280/min = ~18 hours removed
• Comment operations eliminated: 300,000 × 5 = 1.5M comments; at applicable sub-limits, approximately 2–3 days removed
• Attachment operations eliminated: 60,000 files at 50 files/min = ~20 hours removed

Net reduction from archiving 300K tickets: approximately 3–4 days of transfer time at Enterprise tier. At lower-tier limits, the savings are proportionally larger.

Additional scope reduction options:

• Filter spam and bot-generated tickets. These inflate counts without business value; filtering 10–15% of a typical 500K dataset removes a proportional share of API operations.
• Evaluate attachment necessity by ticket age. Tickets older than 3 years with large attachments (log files, promotional assets, outdated screenshots) are candidates for text-only migration. Migrating 500K ticket bodies without their 200GB of attachments is a fundamentally different project than migrating both.
• Archive vs. migrate distinction. Records needed for compliance but not agent reference can be exported to CSV or PDF and stored outside the new platform. This preserves auditability without adding API overhead.

Cross-platform field mapping: what survives intact, what requires transformation

Source fields do not map 1:1 to target schemas. The table below covers the five most common migration paths for data going out of or into each platform. "Transform" means the data can be moved but requires translation logic. "No equivalent" means the data must be stored in a custom field, appended to ticket body, or dropped.

Key constraints:

• Help Scout has no native custom field concept for tickets. Custom field data from Zendesk or Freshdesk must either be encoded as tags, appended as formatted text in the ticket body, or discarded.
• Intercom has no CC field concept. CC recipients from other platforms must be appended to conversation metadata or dropped. This structural mismatch is a primary challenge when migrating from Intercom to Zendesk, where flat conversations must be translated into structured tickets.
• SLA policies do not migrate anywhere — the rules engine is platform-specific. Historical SLA compliance records are distinct from future policy configuration.
• Linked/parent-child ticket relationships (Zendesk) have no equivalent in Freshdesk, Help Scout, Front, or Intercom. These relationships are typically surfaced as tags or body annotations, which is a common source of data loss during a Zendesk to Freshdesk migration if not mapped explicitly.

Map these conflicts explicitly during scoping. Discovering them during the bulk run causes re-architecture mid-transfer, which is the most common cause of timeline overruns.

How to run an extraction benchmark

The final section of this article recommends benchmarking your source system before committing to a timeline. Here is the specific methodology:

Step 1: Sample ticket retrieval rate

Run the following sequence against your live source system (not a sandbox):

GET /api/v2/tickets?page=1&per_page=100     → record response time T1
GET /api/v2/tickets?page=50&per_page=100    → record response time T2
GET /api/v2/tickets?page=500&per_page=100   → record response time T3

If T3 is more than 3× T1, your source uses offset pagination and will degrade significantly at depth. Partition extraction by date range; do not paginate past page 500.

Step 2: Sample comment retrieval rate

For 100 randomly selected tickets spanning your full date range (oldest 10%, most recent 10%, random 80%):

GET /api/v2/tickets/{id}/comments

Record: average response time, p95 response time, average comment count, maximum comment count. Multiply average comment count by total ticket count to estimate total comment API calls.

Step 3: Estimate total operations and floor time

Total ticket-create calls = ticket count / batch size (if batching supported)
Total comment-write calls = tickets × avg comments
Total attachment transfers = tickets × attachment rate × avg files per attached ticket
Total API calls = sum of above

Floor time (minutes) = total API calls / sustained write limit
Practical time = floor time × 1.15 to 1.25 (accounts for retries and back-off)

Apply your target platform's write-side rate limits from the table above. If the target supports batch creation (Zendesk accepts 100 tickets/request), divide ticket-create calls accordingly before computing floor time.

Step 4: Validate against a 1,000-ticket sample run

Run a migration of exactly 1,000 tickets — selected to include your oldest 200, your largest by attachment size 200, your most comment-heavy 200, and random 400. Record actual elapsed time. Compare to your floor-time estimate. The ratio of actual to estimated is your calibration factor; apply it to the full dataset projection.

Platform-specific constraints at 500K tickets

Zendesk as source or target

Zendesk is workable at 500,000 tickets, but the extraction and import path matters. For large exports, Zendesk recommends JSON once above 200,000 tickets; those exports can take a few minutes to a day or more, skip records updated within the last 6 minutes, and split out tickets whose payload exceeds 1 MB because comments are omitted from oversized records. (support.zendesk.com)

On the write side, Zendesk's bulk ticket import accepts 100 tickets per request and caps queued or running background jobs at 30. Imported tickets do not bring over historical first-reply or first-resolution metrics, and triggers do not run on imported tickets. If SLA metrics or trigger side effects matter to your acceptance criteria, that's a scope discussion, not cleanup for later. (developer.zendesk.com)

Zendesk also documents a direct-to-archive option for large historical imports of 750,000+ tickets — a signal that active history and cold history often deserve different handling. (developer.zendesk.com)

Freshdesk as source

Freshdesk breaks naive extract scripts before it breaks the migration plan. The docs cap list responses at 100 objects per page and warn against page numbers over 500. At 500,000 tickets, a simple page=1..5000 crawler will fail with timeouts and incomplete results. Correct design: windowed extraction by created_at date, with each window sized to stay under 50,000 tickets (≤ page 500 at 100 per page). (developers.freshdesk.com)

The Growth plan's rate limits are currently in flux as Freshworks transitions from per-hour to per-minute enforcement. Verify actual limits against your account's X-RateLimit-* response headers before projecting timeline, not against documentation that may lag enforcement reality.

Front as target

Front's API budget is often the bottleneck for high-volume imports. Company-wide limits start at 50 rpm on Starter, 100 rpm on Professional, and 200 rpm on Enterprise, with some endpoints protected by burst guards. Attachment downloads count against rate limits, and imported messages cap attachments at 25 MB. At 500,000 tickets landing as imported conversations, large attachments and threaded message history typically dominate the schedule. (help.front.com)

At Front Enterprise limits (200 rpm), 500,000 ticket-create operations represent a floor of approximately 41 hours of continuous API calls — before comments, attachments, or prerequisite object creation. This is the tightest write-side constraint in the platform comparison table above.

Native importers and model gaps

Built-in importers are quick to start and easy to underestimate. Help Scout's standard importer doesn't bring over knowledge base articles, inbox settings, saved replies, automations, or concepts like custom fields and custom statuses. Its guidance also says not to change records in the old system while the full import is running. (docs.helpscout.com)

If your acceptance criteria include more than plain conversation history, a native importer may shorten setup time while stretching the real project.

How the bulk-and-delta strategy works

Delta sync is the process of identifying and transferring only the records created, updated, or deleted since the initial bulk migration began.

For a 500,000-ticket dataset, the initial bulk transfer takes days. Your support team can't stop working while the data moves. The bulk-and-delta strategy keeps source systems operational:

1. Historical bulk sync. Extract and load the majority of historical data (e.g., tickets closed over a year ago) while agents continue working in the old system.
2. Continuous delta sync. Once historical data is in the target, run background delta syncs using updated_at timestamps on the source to catch new tickets or replies created during the bulk phase.
3. Final cutover. Typically over a weekend — pause the source system, run one final delta sync to capture the last hours of activity, and route all new traffic to the new platform.

An honest caveat on zero downtime: it depends entirely on the source system's API and change-tracking capabilities. Legacy systems without accurate updated_at timestamps may require workarounds that introduce brief sync delays or a short freeze window. Zendesk incremental exports skip records updated within the last 6 minutes — that gap must be accounted for in your final delta pass. See zero-downtime help desk migration for a deeper treatment.

Referential integrity and migration order

Help desk data is highly relational. A single ticket references an author (User ID), an assignee (Agent ID), an organization (Company ID), and a specific workflow state.

If you migrate Ticket #450999 before the target system recognizes Agent #102, the target API rejects the payload with an HTTP 400 Bad Request, or the ticket becomes orphaned. Strictly enforce migration order:

1. Agents and Admins
2. Users and Customers
3. Organizations and Companies
4. Tickets and Custom Fields
5. Comments and Threads
6. Attachments and Knowledge Base Articles

Field-level validation ensures custom dropdown values in the source map exactly to the target schema before the first ticket payload is sent. If your source has 50 custom fields and the target has 20, mapping that data complexity requires architectural decisions during scoping — not improvisation during the transfer.

DIY vs. managed: structured comparison

When DIY makes sense: your source or target is a proprietary or on-premise system with no connector coverage, you have a small engineering team that will own the migration end-to-end, and your ticket volume is under 100K with low attachment density.

When it doesn't: at 500K tickets, you're not migrating a CSV — you're building a one-off data pipeline that needs to handle millions of API calls gracefully, survive transient failures across days of runtime, and produce a verifiable audit trail. The engineering cost of building that correctly typically exceeds the cost of using a service that already has it built. If you are evaluating partners, see our comparison of the best Zendesk migration service providers.

How to reduce scope before the migration starts

Reducing scope is the single most effective way to shorten your timeline. The arithmetic in the scope reduction section above quantifies the savings. The decision framework:

• Archive tickets older than 12–24 months if agents don't reference historical tickets in day-to-day work. Export to CSV or PDF for compliance; don't migrate into the new platform. At Enterprise tier limits, removing 300K tickets saves approximately 3–4 days of transfer time.
• Filter spam, test, and bot-generated tickets. These inflate your count, slow the transfer, and add noise to reporting. Most 500K datasets contain 10–20% records with no business value.
• Migrate ticket text without attachments for old tickets. If tickets older than 3 years carry large files that are no longer operationally relevant, text-only migration is a valid choice. It converts a 1TB attachment transfer problem into a metadata-only problem.
• Stage the migration by ticket age. Migrate the last 12 months first (highest operational value, lowest volume), validate that completely, then decide whether to migrate the historical archive.

A structured data audit before migration begins is the difference between migrating everything (slow, expensive) and migrating what matters (fast, clean). See the data migration playbook.

Validation approach at enterprise scale

Multi-stage validation ensures data fidelity across a transfer of this size. Running validation concurrently with the bulk transfer — not as a separate phase afterward — catches mapping errors while there is still time to correct and re-run without extending the project window.

Validation stages:

1. Record-count parity. Total tickets extracted from source = total tickets successfully ingested in target. Discrepancies trigger investigation before sign-off.
2. Field-level checksums. For a stratified sample (oldest 5%, most recent 5%, random 10%), verify that subject, status, assignee, custom field values, and tag sets match source records exactly.
3. Referential integrity checks. Confirm that every ticket's author, assignee, and organization ID resolves to a valid record in the target. Orphaned tickets indicate migration order failures or deduplication mismatches.
4. Comment thread verification. For the same stratified sample, verify comment counts and authorship match source. Internal vs. public note designation is a common failure point.
5. Attachment verification. Confirm attachment count per ticket matches source; spot-check that attachment files open correctly in the target (URL expiry and re-upload failures can produce valid-looking records with broken file links).
6. Spot checks on high-risk records. Your oldest tickets, your largest tickets by attachment size, your tickets with the most comments, and any tickets your team flags as business-critical.

Document the validation criteria and acceptance thresholds before the full run begins. "Looks right" is not a sign-off criterion at 500K records.

Estimating before you promise a date

The only honest way to estimate a 500,000-ticket migration is to benchmark the actual source and target against representative data.

1. Inventory the dataset shape. Pull counts by ticket state, created date, comment depth, attachment count and size buckets, unique users and organizations, and custom field cardinality.
2. Benchmark the source extraction method. Don't time a CSV export and call that your schedule. Zendesk full exports can take minutes to over a day; JSON exports skip the most recent 6 minutes; CSV omits comments entirely. (support.zendesk.com)
3. Benchmark the target write path separately. On Zendesk, model throughput around 100-ticket import batches and the 30-job background cap. On Front, model around 50–200 rpm plus attachment overhead. Verify whether plan-based rate-limit add-ons are available and scope their cost before locking the date. (developer.zendesk.com)
4. Run the extraction benchmark methodology above. The four-step process — pagination degradation test, comment retrieval sampling, total-operations estimate, and 1,000-ticket calibration run — converts a guess into a projection with a known error margin.
5. Define validation criteria before the full run. Record-count parity, field mapping, authorship, attachments, referential integrity, and spot checks across your oldest and most complex tickets.
6. Rehearse the delta sync. If a native importer requires you to stop changing the old system during import, factor that into business risk and staffing. If the source has usable change-tracking, rehearse a delta pass so agents can keep working and your freeze window stays small.

Do not estimate from ticket count alone. At 500,000 tickets, the schedule can swing by days based on attachment volume, comment depth, pagination strategy, and whether the target preserves the source data model. The extraction benchmark and 1,000-ticket sample run are the minimum inputs for a defensible timeline estimate.

This is why sample migrations matter. At this size, a sample isn't a checkbox — it's where you find malformed HTML, orphaned users, over-limit attachments, broken mappings, and fields that need translation rather than literal copy. Always sample from the tail of your distribution: your oldest tickets, your largest tickets, and your most complex comment threads.

The math decides the timeline

At 500,000 tickets, your migration timeline is governed by arithmetic, not ambition. API rate limits on your source and target set a hard floor. Attachments, comment threads, custom fields, referential integrity sequencing, and retry overhead multiply that floor into the actual project window.

The worked examples, rate-limit table, field-mapping matrix, failure mode taxonomy, and extraction benchmark methodology in this article give you the inputs to calculate that window before committing to a date. Run the numbers against your specific source, target, and data shape. The answer will be more accurate than any estimate based on ticket count alone.