Migrate from Logicalware to Salesforce Service Cloud

Logicalware Tickets map to Salesforce Case as the primary support record. Ticket ID, subject, description (ticket body), status, priority, and created/updated timestamps migrate directly. Custom fields present in the export file are mapped to equivalent Salesforce custom fields on Case, which we pre-create in the destination org before import. Any custom fields missing from the export are flagged as unmapped rather than silently nulled. Case Origin is set from the primary channel tag on the Logicalware ticket.

Logicalware threaded conversations split into individual Salesforce EmailMessage records per message event, preserving sender, recipient, timestamp, and body text. Multi-channel threads (tickets containing email, chat, and SMS events) are split by channel type because Salesforce natively supports EmailMessage for email-channel entries and separate Task records for phone and chat events. This means the single conversational context in Logicalware becomes multiple linked entries in the Service Cloud timeline, which we document in the handoff notes so agents understand the thread reconstruction.

Logicalware Customer records map to Salesforce Contact records. Each Customer's company name is resolved to a Salesforce Account record (created if it does not exist) before Contact import so that the AccountId lookup is satisfied at insert time. Email addresses and phone numbers are preserved as primary identifiers. Where a Logicalware Customer record lacks an email address (a common gap in exports), we flag it for manual review and assign a placeholder email domain approved by the customer's admin.

Logicalware Company grouping records map to Salesforce Account. Company name becomes the Account Name. We link any associated Contact records via the AccountId foreign key. Companies with no associated contacts in the export are created as Accounts with no Contacts and flagged in the reconciliation report as potential duplicates to review post-migration.

Logicalware Agent records map to Salesforce User records by email address match. Post-dissolution, most @logicalware.com email addresses are deactivated. We resolve each agent reference against the destination Salesforce org's User table. Agents without a matching User are placed in a reconciliation queue for the customer's admin to provision the User account before record import resumes, since OwnerId is a required reference on Case.

Logicalware channel type metadata is preserved in two ways: Case Origin field captures the primary channel (Email, Phone, Web), and a custom multi-select picklist field Case_Channels__c records all channel types present on the ticket for multi-channel cases. This preserves the full channel history even though Salesforce does not natively support mixed-channel threads.

File attachments on Logicalware tickets are migrated to Salesforce ContentDocument linked via ContentDocumentLink to the parent Case. We validate each attachment URL from the export file. Any URL that no longer resolves (common after the 2023 dissolution and infrastructure decommissioning) is flagged as missing-attachment in the reconciliation report rather than silently skipped. Customers should restore any critical attachment URLs from their own backup storage before migration begins.

Logicalware tags applied to tickets for categorization migrate to a Salesforce custom text field (Case_Tags__c) as a comma-separated list, or to a Salesforce native Topic/TopicAssignment structure if the customer chooses the topic-based approach during scoping. We preserve the original tag vocabulary without consolidation unless explicitly requested.

Where the Logicalware export contains SLA target timestamps and priority classifications, we map these to Salesforce Entitlement and EntitlementProcess objects. Priority maps to the business hours coverage and first-response milestone targets defined in the destination org's service setup. If no SLA data exists in the export, we note this as a gap and recommend rebuilding SLA rules in Salesforce Service Cloud Entitlement management post-migration.

Custom fields present in the Logicalware export (ticket-level fields added by the customer) are mapped to Salesforce Case custom fields of equivalent data type where possible. We pre-create each destination field during the schema preparation phase. Fields present in the export but with inconsistent or malformed data (a common issue in exports from defunct systems) are migrated as-is and flagged for manual review. Fields absent from the export are not populated.