Migrate from Logicalware to Zendesk

Logicalware Tickets map directly to Zendesk Tickets. The ticket ID, subject, body (description), status, priority, and created-at and updated-at timestamps migrate. Logicalware status values (Open, Pending, Resolved, Closed) map to Zendesk ticket status (Open, Pending, Solved, Closed). Priority maps to Zendesk priority (Low, Normal, High, Urgent) using a value-map we define during scoping. Original Logicalware ticket IDs are preserved in a custom field lwr_original_id__c for cross-reference.

Logicalware Customer contact records map to Zendesk End Users (the requester on a ticket). The email address is the primary identifier and dedupe key. Name fields map to name. Phone numbers map to phone. If the same email appears on multiple Logicalware tickets, we create one Zendesk End User and link all associated tickets to it.

Logicalware Company records map to Zendesk Organizations. Company name becomes the Organization name. Where a Company has no associated Customer records in the export, we note it as a potential orphaned organization and flag it for the customer's admin to either merge or leave as a reference record.

Logicalware Conversation message events map to Zendesk Ticket Comments. Each message event within a thread becomes a separate comment entry ordered by timestamp. The sender (agent or customer) and the message body migrate. Channel metadata from Logicalware (email, chat, SMS, WhatsApp, social) is preserved in a custom field lwr_channel__c on the comment rather than natively in Zendesk because Zendesk does not support mixed-channel thread contexts. This means the original single-threaded Logicalware conversation may appear as separate comment segments in Zendesk.

Logicalware Agent records include name, email, and role. We map agent assignment on migrated tickets by matching the Logicalware agent email against a provided Zendesk agent list. Any Logicalware agent with a @logicalware.com email address is flagged as stale and remapped to a designated replacement owner the customer provides during scoping. Agents without a Zendesk match go to a reconciliation queue.

Logicalware channel types (email, live chat, SMS, WhatsApp, social media) are stored as a property on message events and on tickets. Since Zendesk does not natively support multi-channel mixed threads, we preserve the channel type on each comment via a custom text field lwr_channel__c. The primary channel on the ticket is stored in lwr_primary_channel__c. This allows agents to filter by channel in Zendesk Views if needed.

File attachments on tickets migrate where export artifacts include intact file references or binary data. We flag any attachment URL that points to a Logicalware domain no longer active post-2023 dissolution as inaccessible and note the original filename and URL in a custom field lwr_attachment_url__c. Zendesk attachment upload uses the Zendesk API with a 20 MB per-file limit. Files exceeding this limit are flagged for manual handling.

Tags applied to Logicalware tickets migrate as Zendesk Tags. Tag vocabulary is mapped directly without consolidation unless the customer explicitly requests synonym merging during scoping. Tags are applied at the ticket level only; Zendesk does not support tag inheritance from parent records.

Custom fields present in the Logicalware export file are mapped to Zendesk custom fields of the matching type (text, integer, checkbox, dropdown). We pre-create the Zendesk custom fields in Admin Center before migration begins. Custom fields present in the export but not structurally intact (malformed values, encoding errors) are flagged and populated with a lwr_import_error__c note rather than a null value. Any Zendesk custom fields with no corresponding Logicalware source are left empty and documented.

Logicalware threaded conversations carry metadata including reply-to chain references and internal notes. We flatten this into standard Zendesk ticket comments (public) and internal notes (private). The thread context (which messages were in the same Logicalware thread) is preserved in a custom text field lwr_thread_context__c containing the original Logicalware thread ID for audit purposes.