Many guides say a help desk migration takes 4 to 12 weeks. That range describes a project planned and tested by hand, with the transfer scripted from scratch. With a tested migration tool, most of those weeks never happen: mapping takes minutes in a wizard, a test run takes minutes, and the transfer runs in the background while your team keeps working.
The real swing factor is the platforms. Zendesk allows 200 API requests per minute on its Team plan and 2,500 on Enterprise Plus (Zendesk Developer Docs). Halo caps API use at 300 calls per five minutes (HaloPSA Fair Use Policy). Since 2 March 2026, Atlassian has metered Jira Cloud apps against a points-based hourly quota (Atlassian Developer). Below you'll find typical times by project type, by data volume, and by platform, plus the steps that make up a migration project.
How long a help desk migration project takes, start to finish
The data transfer is only one step. Most of the project is preparation and checking, so plan the whole timeline, not just the run.
Help Desk Migration preparation: 10 steps before Go-Live
Start by defining project goals and auditing existing records, then clean data, configure the target platform, and test field mapping; each step helps prevent delays and data issues. Here's a breakdown of the key migration stages and their typical timelines.
| Phase | What to do | Typical time |
|---|---|---|
| 1. Define scope and goals | Agree on why you’re moving, the target platform, and the go-live date | 1–2 days |
| 2. Align the team | Name a project owner, brief agents and managers, and agree on a cutover window | 1–3 days |
| 3. Audit your data | List what you have: tickets, contacts, companies, attachments, custom fields, macros | 2–5 days |
| 4. Decide what to migrate | Mark data as must move, move later, or archive. Older closed tickets are often safe to leave out | 1–2 days |
| 5. Clean the data | Merge duplicates, close stale tickets, remove junk | 2–7 days |
| 6. Prepare the target | Set up custom fields, agents, and automations so imported records have a place to land | 3–10 days |
| 7. Run a demo migration | Test on a sample, check field mapping and attachments, and fix issues | 1–3 days |
| 8. Full migration | Transfer all records (hours to several days, depending on volume and API limits) | 1–5 days |
| 9. Cutover | Move the records created since the full run and switch agents over | 1 day |
| 10. Verify and support | Compare record counts, spot-check data, and train agents | 1–2 weeks |
Overall: most whole migration projects take 2 to 6 weeks, and the data transfer is often under a week of that. Phases 3–6 can overlap, so starting preparation early is the best way to shorten the project.
The Migration Process: estimated migration timelines by project size and complexity
The table below adds up every stage of a project for three common scenarios. Transfer times come from our logs. The other stages are planning ranges based on the step durations later in this article.
| Scenario | Setup and Demo | Testing and mapping fixes | Full Migration (transfer) | Delta and cutover | Typical total |
|---|---|---|---|---|---|
| Small, standard setup: under 10K records, few custom fields | 15–30 min | 1–2 h | ~35 min (9 in 10 within ~4.5 h) | 1–2 h | About 1 day |
| Mid-size with custom fields: 10K–100K records, several Demo re-runs | 1–2 h | 1–3 days | ~4 h (9 in 10 within ~1 day) | 2–4 h | 2–5 days |
| Enterprise or merging several help desks: 1M+ records, custom objects, low-limit target | 1–2 days of planning | 3–7 days | ~2 days (9 in 10 within ~8.5 days) | half a day | 2–6 weeks |
Most of the time in a large project is review and decisions, not machine time. That's why the biggest savings come from testing early and keeping the scope tight. The speed-up tips below cover both.
Typical data migration times by data volume
The table below shows how long the data transfer took in observed Help Desk Migration runs, grouped by the number of records moved. The columns give the number of runs, the range covered by the middle half of runs, the median, and the time within which 9 in 10 runs finished.
| Data volume (records) | Runs | Typical range (middle 50%) | Median | 9 in 10 finish within |
|---|---|---|---|---|
| Small: under 10K | 496 | 15 min – 1.5 h | ~35 min | ~5 h |
| Medium: 10K – 100K | 572 | 1.5 h – 11 h | ~4 h | ~1 day |
| Large: 100K – 1M | 457 | 5 h – 1 day | ~12 h | ~2 days |
| Very large: 1M+ | 263 | 21 h – 5 days | ~46 h | ~8.5 days |
These are observed durations from real migrations, not a formula. They cover API-to-API routes on whatever plan tier each customer used. CSV, database, and mailbox sources run at different speeds and are excluded. The same 30,000 records can move in an hour or take most of a day, depending on the platforms in the next section.
Migration time by platform (API limits)
Each platform's API limit sets how fast records can be read out of it (export) or written into it (import). The table lists 13 platforms with their documented API limits at the standard and top tiers, plus observed export and import times for migrations of about 100,000 records.
| Platform | API limit (std / top tier) | Export, ~100K records | Import, ~100K records | Notes |
|---|---|---|---|---|
| Zendesk | 200 / 2,500 rpm | 7 h | 24 h | Fastest common target |
| Freshdesk | 100 / 700 rpm | 6.5 h | 23 h | Fast both ways |
| Freshservice | 100 / 500 rpm | 17 h | 23 h | Slow as a source; export speed barely rises with volume |
| Jira Service Management | points-based (hourly quota) | 25 h | 25 h | Slowest common target by far: ~1,250 records/h at any size |
| Intercom | 10,000 rpm per app; higher on request | 5 h | 5 h | Fast both ways; limits counted in 10-second windows |
| HubSpot Service Hub | 600 / 1,140 rpm | 1 h | 6 h | Very fast export |
| Salesforce Service Cloud | daily: ~100K req/day | 30 h | 70 h | Daily cap; slows sharply above 1M records (see below) |
| Zoho Desk | daily credits | 2.5 h | 13 h | Daily credits; wide spread |
| ServiceNow | admin-configurable | 2 h | 19 h | Depends on the instance's own limits |
| Halo | 60 rpm (300 req / 5 min) | 4.5 h | 12 h | Lowest documented limit in the table |
| Pylon | not documented | n/a (target only) | 23 h | Confirm the limit with Pylon |
| Front | 50 / 200 rpm | 32 h | 20 h | Low limit matches slow times |
| Gorgias | 120 rpm (40 req / 20 s) | n/a | 19 h | Slow target |
API limits were checked against each vendor's developer documentation in November 2026. Vendors change these limits often, and most sell higher tiers or add-ons, so check your own plan before you plan a cutover. To get an exact figure for your own data,
Help Desk Migration by Relokia completed Vanta’s Freshservice to Jira Service Management migration in just 21 days, transferring 128K+ tickets while preserving historical context, attachments, and audit trail integrity. Here's how we made it happen:
Vanta: 128K+ Tickets Migrated in Just 21 Days
Help Desk Migration by Relokia completed Vanta’s Freshservice to Jira Service Management migration in just 21 days, transferring 128K+ tickets while preserving historical context, attachments, and audit trail integrity. Here's how we made it happen:
From project launch to successful completion in only 21 days, Vanta migrated 128K+ tickets, 512K comments, 86K attachments, and 4.2K+ requesters and agents from Freshservice to Jira Service Management, preserving historical context and full audit trail integrity.
The tight timeline was achieved through automated migration options, tailored configurations, and an iterative approach. Inline images were transferred as ticket attachments, while custom tags based on Group fields kept migrated records organized and easy to identify.
The Premium Support Package included re-migration, giving Vanta time to apply customizations, validate results, and complete the final transfer without extending the 21-day project timeline.
What affects how long a data migration takes
API limits set the ceiling. Four other factors determine how close a migration gets to it and how long the project takes.
- Number of records. Every ticket brings its comments; one ticket can include hundreds or thousands of comments, and every comment is part of the transfer. Volume sets the baseline.
- Attachments. Each file is a separate upload, so attachments can matter more than ticket count. A large account with few attachments can finish sooner than a smaller account full of screenshots and PDFs. The number of files is also hard to estimate in advance, which makes attachment-heavy migrations the hardest to predict.
- Plan tier on both sides. Most vendors scale API limits with the plan - the higher the plan, the more API calls you are allowed to use. For example, Freshservice goes from 100 requests per minute on Starter to 500 on Enterprise, with add-on packs up to 2,000 (Freshservice API docs).
- Merging several help desks into one. Consolidation isn't one migration but several into the same target. Each source runs as its own migration, and every run after the first lands in a target that already holds data. Our technical engineers can assess your migration requirements and determine whether a parallel (multithreaded) or sequential migration approach will deliver the most time-efficient results. Mayvik moved data from Freshdesk, Zendesk, Desk.com, and Groove into Help Scout this way.
Our guide to customer support data migration challenges lists everything that can slow a project down, with fixes.
Data migration timeline, step by step
Transfer time is only one part of a migration project. The timeline below covers the full process and how long each step usually takes.
Step 1: Map your data and run a Demo Migration (15–30 minutes)
So, here are the main options you may consider when choosing a way of data transition:
A Free Demo usually takes 15–30 minutes. In the Migration Wizard, you connect the source and target platforms (you need admin access to both). Then you choose the records to transfer, match agents and groups, and map organization, customer, ticket, and article fields. The exact mapping steps vary by migration pair. You can also choose pre-built automated options to tailor the import.
The Demo takes longer if pre-migration setup isn't done. Before you start, collect access credentials for both platforms, create matching agent profiles and groups in the target, and set up the required ticket custom fields. With many custom fields, plan for several rounds of mapping rather than one.
Step 2: Review the Demo results (minutes to 2 hours)
Reviewing a Demo takes a couple of minutes. Testing the results of a Full Data Migration takes at least 1–2 hours. The Demo mirrors the Full Migration, so if something doesn't migrate in the Demo, it won't migrate in the Full Migration either. Re-run the Demo as many times as you need to tune the mapping.
Check that:
- comments have the correct authors
- tickets are assigned to the right agents
- custom fields carry the right values
- companies and customers are linked
- attachments arrive with their names
- articles sit in the correct sections and categories
- Sharing access to the migration lets your team help validate.
Sharing access to the migration lets your team help validate.
Step 3: Prepare your team and the target help desk (under 2 hours)
Start onboarding agents as early as possible. How long it takes depends on the number of agents and the target platform. The cutover itself is short:
- Turn off automations on the target, or request a tag: 5–30 minutes
- The support team stops working in the source: 5 minutes
- Turn off communication channels on the source: 5–15 minutes
- Activate communication channels on the target: 15 minutes to 1 hour
Step 4: Run the Full Migration (hours to days)
This is the transfer time shown in the volume and platform tables. Your team can keep working in the source help desk while it runs. You can track progress in the record table, which shows retrieved and transferred records, and you receive an email when the migration completes. If the run has to fit around business hours, Interval Migration lets you pause and resume the Full Migration in coordination with our team.
Step 5: Run a Delta Migration for new records
Tickets created or updated in the source during the Full Migration can be moved in a later pass with Delta Migration, available on the Premium plan. Validate the result before you switch agents to the target.
8 ways to speed up your data migration
To speed up a help desk, ITSM, or RMM migration, you can take several steps to reduce data transfer time, simplify preparation, and avoid unnecessary delays. From optimizing API limits and cleaning up source data to streamlining field mapping and using parallel migration, the right approach can make the entire project faster and more predictable. Consider the following ways to accelerate your migration without compromising data accuracy or business continuity.
- Ask the vendor for a temporary API limit increase. Intercom accepts requests for higher limits, Freshdesk sells additional API calls, and Zendesk offers a High Volume API add-on that raises qualifying plans to 2,500 requests per minute.
- Skip attachments. The "Skip attachments" option moves records without
files. Exclude attachments from all tickets or tickets last updated more than 6, 12, or 24 months ago. Reduce migration time and storage costs by transferring only the files your team needs. Ideal for large migrations, outdated files, and avoiding storage overages. - Filter out old or irrelevant records. Fewer records mean fewer API calls. You don't have to migrate everything to your new platform. Use the filtering options in the Migration Wizard to select which records to transfer and exclude irrelevant data, such as all tickets or tickets last updated more than six months ago. If the standard filters don't cover your requirements, you can request additional filtering options from our technical team. They can help configure custom filters based on your migration scope, so you transfer only the data you need, reduce API calls, and save migration time.
- Multithreaded Migration with Help Desk Migration. Migrate in parallel. Asynchronous, multithreaded transfer runs as parallel threads, sending many requests at once instead of one by one, which cuts the time lost to waiting on responses. Pair it with a higher API limit, since parallel requests still count against it. It is available in the Premium and Enterprise plans.
- Upgrade the plan tier during the migration. A higher tier on the slower platform usually raises its API limit for the duration of the run.
- Migrate the newest records first. Transfer the most recent tickets first so your team can prioritize active customer issues while older records migrate in the background. This option is ideal for limited downtime windows, uninterrupted support, tighter budgets, and testing active tickets before cutover. Available for Full Migration only.
- Use Delta Migration for the cutover. Transfer tickets created or updated in the source after the Full Migration, ensuring your new platform has the latest data before go-live. This minimizes downtime and prevents data gaps. Available on the Premium plan.
- Use Interval Migration to fit business hours. Pause the Full Migration during peak hours and resume it afterwards. You can pause up to five times, for up to five days each time, in coordination with our team.
For complex migrations, our Managed Migration Services provide expert support with planning, customizations, data mapping, API limits, and validation to ensure a smooth transition with minimal disruption.
Pandora: Enterprise-Wide Migration Completed in Just 4 Weeks
In just 4 weeks, with zero downtime, Pandora completed an enterprise-wide migration from Zendesk to Salesforce Service Cloud, consolidating customer support data across 6,500+ points of sale and 37,000 employees worldwide.
The migration transferred complete ticket and customer histories, call recordings, attachments, internal notes, side conversations, and business workflows while preserving data relationships.
To keep the project on schedule, the team used an iterative approach with five Demo Migrations to validate field mapping and configurations before the final transfer. Salesforce backend triggers were temporarily disabled to prevent system blockages and ensure a smooth transition.
Manual, automated, or managed migration: how the timelines compare
A team-built script, a self-serve migration tool, and a managed migration service differ most in the time spent before and after the transfer, not during it.
| Criterion | Manual (custom script) | Automated (self-serve tool) Help Desk Migration Tool | Managed migration service by Help Desk Migration Support & tech Team |
|---|---|---|---|
| Setup time | Weeks to months studying both APIs | Minutes to connect and map in a wizard | Our team scopes the project and maps the data with you |
| Testing | Built and repeated by your team | Demo Migration on a sample, re-run as needed | Demo runs plus a validation plan for the project |
| Handling API limits | Your code has to throttle and retry | Built into the tool | Built in, plus vendor limit requests planned in advance |
| Custom fields, filters, merges | Whatever your team builds | Standard mapping and automated options, filtering. Request custom filters or additional migration customizations from our technical team to tailor the process to your data and project needs. | Custom filtering, custom mapping, multi-source consolidation |
| Typical project length | Weeks to months | Hours to a few days | Days to a few weeks, depending on scope |
| Cost | Engineering time, often hidden | Priced by record volume and options, support package (pricing) | Quoted by record volume, options, support package (migration services) |
A managed service doesn't have to mean custom code for every project. Help Desk Migration's team runs the same tested engine as the self-serve tool, so the speed of the transfer stays the same, but planning, mapping, and validation move off your team's desk.
to see how your own records behave on your route, or Talk to an Expert about an enterprise or multi-source project.
FAQ
In our logs, migrations of more than 1 million records took a median of about 46 hours. The middle half of runs finished in 21 hours to 5 days, and 9 in 10 within about 8.5 days. A low-limit target such as Jira Service Management would take about a month, or a daily-capped one such as Salesforce Service Cloud, pushes the run to the long end of that range. Add a few days to a week of mapping and testing around the transfer, and a 1-million-ticket project usually fits in one to three weeks, not three months.
Those ranges usually describe the whole project with a manual or custom-built approach: weeks of planning, a scripted test migration, the transfer, and weeks of QA. With a tested migration tool, mapping and testing take minutes to days, and the transfer itself takes hours for most accounts. Very large or multi-source projects still need careful planning, but a timeline measured in months usually means a lot of manual work.
Yes. Each attachment is a separate upload, so an account full of files can take longer than a larger account with few of them. Knowledge base articles are usually few compared with tickets, but inline images and article structure (sections and categories) add mapping and checking time. If attachments are slowing the transfer, the "Skip attachments" option moves records without files.
For help desk data in Salesforce Service Cloud (cases, contacts, and knowledge articles), Zendesk-to-Salesforce migrations in our logs took a median of about 6 hours for 10,000–100,000 records and about 12 hours for 100,000–1 million. Above 1 million records, Salesforce's daily API request cap starts to slow the run: Zendesk-to-Salesforce migrations of that size took a median of 3.4 days. These figures don't cover a full Sales Cloud CRM migration. See our Salesforce Service Cloud migration page for supported records.
Parallel migration runs in multiple threads, sending many requests at once to cut the time spent waiting on responses. It helps most on large accounts with many record types, and less if you’re already hitting the vendor’s API limit, so raise the limit first in that case. Related records, like tickets and their requesters, are still created in the correct order, and a demo migration lets you check the result before the full run.
Yes. Agents keep working in the source help desk while the Full Migration runs, because the transfer reads data through the API without locking the account. Turn off automations in the target first, so imported tickets don't trigger emails to customers. The zero-downtime migration guide covers the cutover sequence.
Tickets created or updated in the source after the Full Migration starts aren't part of that run. A Delta Migration moves them in a later, much shorter pass, so agents can switch to the target with complete history. Delta Migration is available on the Premium plan. The general data migration checklist shows where Delta fits in the cutover.
Yes, with Interval Migration. You can pause the Full Migration up to five times, for up to five days each time, and resume it in coordination with the Help Desk Migration team. For example, you can keep peak support hours free of API load. Interval Migration isn't the same as Delta Migration, which moves records created after the main run. The pause and resume steps are in the Get Started help section.
During a Demo Migration, the Migration Wizard shows a progress bar with the percentage of sample data transferred. During the Full Data Migration, a record table shows how many records were retrieved and transferred. You receive an email when the Demo or Full Migration completes.
Compare the target with the source: record counts by type, comment authors, ticket assignees, custom field values, attachments, and article categories. Check a sample of old, recent, and attachment-heavy tickets, then turn on triggers, automations, and notifications in the target. Gather feedback from agents during their first days in the new help desk. The post-migration checklist lists every check.
First, check the platform table: a slow run into a low-limit target such as Jira Service Management, Halo, or Front is often normal. If the record count in the progress table hasn't moved for several hours, a daily API cap or an expired token may have paused the run. In that case, contact our support team with your migration ID so they can check the logs.
