Migrate from ConSol*CM to Zendesk

ConSol*CM Requests are the primary ticket object and map directly to Zendesk Tickets. We extract all Request fields, status values, priority flags, and requester references via the REST API. The ConSol Request status workflow maps to Zendesk Ticket status (New, Open, Pending, Solved, Closed) based on the customer's status configuration. Custom fields on Requests migrate to Zendesk Ticket custom_fields entries using the field ID from the destination schema. Conversation history (linked Request Conversations) migrates as Ticket comments with timestamps and author attribution preserved.

ConSol*CM Contacts map to Zendesk End-User records. The extensible Contact model with custom field groups requires explicit field-by-field mapping during the discovery phase; there is no machine-readable schema export from ConSol*CM. We extract the field group configuration via the system documentation export and map each custom field to a typed Zendesk User field (text, dropdown, checkbox, date). The customer's admin signs off on all non-standard field mappings before the import dry-run. Organizations extracted from Contact company references map to Zendesk Organizations for deduplication.

Conversations linked to ConSol*CM Requests migrate as comments on the corresponding Zendesk Ticket. We preserve timestamps, author attribution (mapping to the Zendesk User who authored the comment), and the internal or external visibility flag. Zendesk's Agent Workspace applies new markdown conventions to comments generated in the standard interface after migration, which can affect spacing on legacy comments; we document this behavior and recommend a post-migration review of comment formatting on high-visibility tickets.

File attachments associated with ConSol*CM Requests and Contacts are downloaded from the source API and uploaded to Zendesk via the Attachments API. We handle filename deduplication by appending a numeric suffix when collisions occur. Zendesk attachment size limits vary by plan (20 MB on Suite Team and Suite Growth, 50 MB on Suite Professional and above); we verify each attachment against the destination plan's limit and flag any files exceeding the threshold for customer resolution before the import phase.

ConSol*CM Resources represent internal staff or system entities with user assignments on Requests and workflow roles. Resources with active Request assignments map to Zendesk Agent User records; Resources with administrative permissions map to Zendesk Admin records. We resolve Resource references by email match against the Zendesk User table. Any Resource without a matching Zendesk User goes to a reconciliation queue for the customer's admin to provision before the User import phase proceeds.

ConSol*CM Team structures map to Zendesk Groups. We preserve team-to-agent assignments and team-level routing configurations during migration. Zendesk's Group model supports agents belonging to multiple Groups with a primary assignment; if ConSol*CM's team model allows agents to belong to only one team, we map that constraint to a Zendesk Group as the primary assignment and document the difference for the customer's admin to review post-migration.

Tags applied to ConSol*CM Requests and Contacts export as flat lists and map directly to Zendesk Tags. We map them to the destination tagging schema and flag any tag naming conflicts during the import dry-run. Zendesk tags are case-sensitive and can include spaces when quoted; ConSol*CM tag naming conventions are preserved verbatim, and any conflicts are resolved by the customer's admin before final import.

ConSol*CM Request field groups define custom property sets that vary per installation. We extract the field group configuration via the system documentation export and map each field individually to Zendesk Ticket custom fields. Field types from ConSol (dropdown, checkbox, text, date) map to equivalent Zendesk custom field types. Any required-field constraints in Zendesk are temporarily disabled during import and re-enabled after migration to prevent record rejection on historical data.

ConSol*CM Contact field groups define custom properties on the extensible Contact model. Each custom field is mapped to a Zendesk User custom field with the matching type (text, numeric, dropdown, checkbox, date). Field dependencies (conditional visibility or required-ness based on other field values) in ConSol*CM have no direct Zendesk equivalent and are documented as configuration notes for the customer's admin to rebuild using Zendesk's conditional field visibility settings.

ConSol*CM Knowledge Base articles export with content and metadata, but the article hierarchy (category structure and section nesting) requires manual mapping to Zendesk Guide sections. Zendesk Guide's section nesting is limited compared to what ConSol*CM may support; ConSol*CM articles nested more than two levels deep in the source hierarchy require flattening into Zendesk Guide sections. We extract article content and HTML, map categories to Zendesk Guide Sections, and flag any content requiring re-authoring due to structural differences.

ConSol*CM workflows built in the Process Designer with activities, conditions, and decision branches cannot be exported via API and do not migrate as code. We extract the workflow logic documentation from ConSol*CM's system configuration export and produce a written inventory of every active workflow with its trigger conditions, actions, decision branches, and assigned Request types. This inventory maps each workflow to its equivalent in Zendesk's Trigger, Automation, or Macro model. The customer's admin or a Zendesk implementation partner rebuilds the automations post-migration.

ConSol*CM does not have a separate Organization object, but company information is often embedded in Contacts via custom field groups. We extract organization data from Contact records and construct Zendesk Organization records using company name and domain as deduplication keys. Organization-to-agent assignments and organization-level SLAs from ConSol*CM map to Zendesk Organization fields and business rules, with any SLA-specific configuration documented for manual rebuild.