Migrate your ProProfs Help Desk data

Tickets are the primary object with a standard lifecycle: open, pending, resolved, closed. Every ticket holds a customer reference, assignee, status, priority, labels, and threaded conversations. We migrate tickets with their full conversation history and attachments intact.

Customer records contain contact details, company association, and ticket history. ProProfs stores customers as separate entities from tickets. We map customer records to the destination CRM or helpdesk contact object preserving email, name, and company linkage.

Company records allow grouping customers under organizational accounts. We preserve the company-customer association during migration, which is critical when the destination is a CRM-centric platform.

Agent profiles include name, email, role (admin, agent), and team membership. Roles map directly to destination permission levels, but team structures may differ. We translate team assignments to destination group or queue equivalents.

Each ticket holds one or more conversation messages with timestamps, sender type (customer/agent/system), and visibility (public/private note). Private notes migrate as internal comments on the destination platform.

Files attached to tickets or knowledge base articles are exported with their original filenames and MIME types. We transfer binary attachments via direct URL fetch when ProProfs provides accessible attachment URLs.

ProProfs uses labels for ticket categorization. Labels migrate as tags on destination tickets. We preserve all label-to-ticket associations.

ProProfs supports seven custom field types: text, number, dropdown, date, checkbox, multi-select, and user reference. Field types map to equivalent destination field types where available; unsupported types fall back to text with the original value preserved.

Articles can be exported in PDF (full site) or JSON/XML (per page or filtered set). We extract article content, categories, and URLs from JSON export. PDF exports require OCR or manual reconstruction and are not used as primary sources.

Canned responses are configuration data with no export API. We document the full list of canned responses with their content so they can be recreated manually on the destination.

Workflows and triggers are stored server-side with no documented export endpoint. We capture the rule names, conditions, and actions as a written specification for manual rebuild on the destination.

SLA configurations are platform-level settings with no export capability. We record the SLA thresholds (first response, resolution time by priority) so they can be reconfigured manually.

CSAT and NPS survey settings migrate as configuration records, but individual survey response data may be limited to aggregate reporting. We flag survey responses for explicit scoping before migration.