BoldDesk Data Migration Guide: Scope, Prerequisites, and FAQs
BoldDesk data migration helps you move core helpdesk data—including tickets, contacts, companies, agents, and knowledge base content—from your existing platform to BoldDesk. System configurations and operational logic (such as automations, workflows, SLAs, and notification rules) cannot be migrated and must be set up directly in BoldDesk.
1. Supported Migration Scope vs. Not Migrated
| Category | What Can Be Migrated | What Is NOT Migrated (Requires BoldDesk Configuration) |
|---|---|---|
| Tickets | * Messages/conversations * Internal notes * Attachments * Inline images * Supported field values * Historical/closed tickets can be migrated if present in source data/export. |
Ticket audit/history logs. |
| Ticket IDs | Original ticket numbers can be retained as BoldDesk ticket numbers upon request. Original source ID is also stored in External Reference ID. | Automated renumbering without prior coordination. |
| Custom Fields | Field values are migrated based on customer-provided source-to-BoldDesk mapping. | Automatic field creation in BoldDesk. Fields and dropdown/multi-select options must be created by the customer first. |
| Agents, Contacts & Companies | Agents, Contacts (end users), contact groups, companies/organizations. Source IDs stored in External Reference ID. | Account-level configurations. |
| Knowledge Base | Articles, categories/folders, inline images, attachments, and unpublished/draft articles (subject to source export/API availability). | Article feedback history/analytics. Links between Knowledge Base articles may require additional review because BoldDesk uses a different URL structure than many source platforms. Internal article links may continue to reference the original platform URLs unless redirect rules are configured. |
| System Rules & Config | None (Data migration only). | * Automations * Workflows * SLA policies * Email notification templates * Other system/configuration settings * Canned Response * Macros * Integration and webhooks. |
2. Key Migration Rules & Behaviors
- Ticket Date Range & Selection: Migration is fully customizable. You can migrate all data, selected tickets, a specific date range, or agreed export batches.
- Ticket Numbering Configuration: Newly created post-migration tickets can start from any specified number (e.g., #10,000). Set this higher than the highest migrated ticket number to avoid ID conflicts.
- Estimation Ticket Count: Only currently open tickets are counted when calculating migration turnaround estimates (closed tickets are excluded from timeline sizing, though they can be migrated).
- Free vs. Premium Migration: Free migration is a one-time activity. Extended migration scopes, multi-phase iterations, or re-migrations may require premium migration services.
- Attachment Restrictions:
- Size limit: Maximum 20 MB per file.
- Restricted file types: Blocked executables and scripts (
.exe,.bat,.js,.vbs,.dll,.msi,.reg,.apk,.jar,.ps1,.html,.htm,.xml,.php, etc.) are not migrated for security reasons.
- Cutover & Delta Changes:
- You can continue using your source helpdesk during migration.
- For tickets updated or created after the initial migration run, an incremental delta migration can be scheduled prior to final cutover.
- If an already migrated ticket receives new updates in the previous system, the record can be refreshed/re-migrated upon agreement before cutover.
Actual Migration Timeline
Migration typically takes approximately 3–4 working days from the date the required export file is received.
The actual duration may vary depending on:
- Source API rate limits.
- The volume of data being migrated.
- The number of inline images and attachments in tickets.
- The agreed migration scope and data complexity.
The timeline is an estimate and does not guarantee an exact completion date.
3. Supported Source Platforms
BoldDesk supports dedicated, vendor-specific migration workflows for:
- Freshdesk
- Zendesk
- Zoho Desk
- Help Scout
- Jira
- HappyFox
- Other / New Vendors: Evaluated and migrated through custom export formats or API access using the common migration process.
Customer Responsibilities (Pre-Migration Checklist)
- Submit Request: Log your request at bolddesk.com/migration.
- Confirm Scope: Specify source vendor, target date range, specific tickets, and whether original ticket IDs should be retained.
- Provide Access/Data: Supply source API credentials securely or provide required export files (CSV/JSON/DB).
- Create Custom Fields in BoldDesk: Pre-create all required custom fields and exact dropdown/multi-select options in BoldDesk before data ingestion.
- Provide Field Mapping: Supply a mapping table connecting source fields to target BoldDesk fields.
Minimum Source-Account Access Requirements
Generally, one administrator account with the required export permissions and API access should be sufficient to provide the access needed for migration. Ensure that the account has the necessary permissions to access and export the data included in the agreed migration scope.
Large-File Sharing Instructions
If your migration file exceeds the 20 MB attachment limit or cannot be attached to the support ticket because of an unsupported file type, upload it to an external file-sharing service such as OneDrive, Google Drive, or Dropbox and share an accessible link in the ticket.
Ensure that the migration team has permission to access the shared file.
Post-Migration Validation
- Review Migrated Records: Verify ticket message integrity, internal notes, inline images, attachments, and field values.
- Verify Traceability: Check that source IDs are accurately reflected in the External Reference ID field.
- Report Discrepancies: Report sample record IDs to the migration team for immediate investigation.
- Cutover & Renumbering: Configure your post-migration starting ticket number and switch production traffic.
5. Frequently Asked Questions (FAQs)
What data can be migrated to BoldDesk?
Tickets (conversations, notes, attachments, inline images, tags, custom fields), Contacts, Contact Groups/Companies, Agents, and Knowledge Base articles (including drafts, categories, and media).
Can historical or closed tickets be migrated?
Yes. All historical and closed tickets can be migrated as long as they exist in your source export/API data. Note that audit/history event logs are not migrated.
Can our original ticket numbers be retained?
Yes. Upon request, original ticket numbers can be preserved as the BoldDesk ticket ID. In addition, the source ticket ID is always saved in BoldDesk’s External Reference ID for traceability.
Can we set newly created tickets to start from a specific number (e.g., #10,000)?
Yes. This is configured in BoldDesk settings after migration. Choose a number higher than your highest migrated ticket ID to avoid conflicts.
Can custom fields be migrated automatically?
No. You must create the corresponding custom fields and dropdown options in BoldDesk first, then provide a field mapping table so the migration team can map the values.
Are automations, SLAs, canned responses, and workflows migrated?
No. System configurations and operational logic (automations, SLAs, dispatch rules, email notifications, macros, canned responses, integrations, and permissions) are outside data migration scope and must be configured directly in BoldDesk.
Can Knowledge Base articles and unpublished drafts be migrated?
Yes. Articles, category structures, inline images, attachments, and draft/unpublished articles can be migrated based on source data availability.
What happens if new tickets or updates arrive during migration?
You can continue operating on your source helpdesk. A delta/incremental migration plan can be coordinated prior to cutover to bring over new tickets or re-migrate updated records.
How is the migration timeline estimated?
Estimations are based on the volume of currently open tickets, source API rate limits/export sizes, field mapping complexity, and validation needs.
Will ticket relationships and links to task management platforms be retained during migration?
No. The migration process does not preserve parent-child ticket relationships or links to task management platforms such as Jira, Azure DevOps, and Asana. Tickets are migrated as standalone records without these associations.
