Migrate from Logicalware to HubSpot Service Hub

Logicalware Tickets map to HubSpot Service Hub Tickets with ticket ID preserved as a custom property for traceability. Subject, body, status, priority, and timestamps (created, updated, closed) transfer directly. Ticket owner resolves via agent email match against HubSpot Users. Multi-channel tickets carry their original channel type as a ticket property. We flag any @logicalware.com agent emails as stale and map them to a designated replacement owner before import.

Logicalware customer contact records map to HubSpot Contacts. Email address serves as the primary identifier and deduplication key. Phone number, name, and any exported custom fields transfer as HubSpot Contact properties. Where a Logicalware customer has no email but has a phone number, we create a Contact with phone as primary identifier and flag it for email enrichment post-migration. Customers with no contact information are flagged as incomplete records and noted for manual review.

Logicalware Company records map to HubSpot Companies. Company name becomes the primary display property. Domain extracted from email addresses on linked contacts populates the Website field for deduplication. Where a Logicalware company has no contacts in the export, we create the Company record and flag it as a potential orphaned account for customer review. Company notes or description fields map to the HubSpot Company description property.

Logicalware conversation threads map to HubSpot Conversations, preserving chronological message order per ticket. Each message event carries sender, timestamp, body text, and channel type. Channel metadata from Logicalware's omnichannel model (email, chat, SMS, WhatsApp, social) migrates as conversation properties. We document the thread-splitting behavior: HubSpot's channel model may separate what was a single mixed-channel conversation in Logicalware into disconnected thread segments in the destination, which we flag explicitly during scoping.

Logicalware Agent records map to HubSpot Service Hub Users by email match. Every @logicalware.com email address is flagged as deactivated and requires mapping to an active HubSpot User before migration proceeds. We extract agent name and role from the Logicalware export and populate HubSpot User properties accordingly. Agents without any exported email are noted as anonymous and mapped to a system migration owner for customer admin assignment post-migration.

Logicalware channel type (email, live chat, SMS, WhatsApp, social media) migrates as a read-only ticket or conversation property in HubSpot. HubSpot does not expose a standalone Channel object, so we use a custom ticket property (original_channel__c) to preserve channel attribution. Channel routing rules from Logicalware are documented but not migratable; we recommend rebuilding routing as HubSpot Teams and inbox assignment rules post-migration.

Ticket attachments migrate as HubSpot file attachments linked to the parent Ticket or Conversation record. We validate URL accessibility before migration; any attachment referencing a URL hosted on Logicalware infrastructure (logicalware.com domain) post-2023 is flagged as inaccessible and excluded from migration with a written inventory entry rather than a broken link landing in HubSpot. We advise customers to download all accessible Logicalware-hosted attachments before migration scoping begins.

Logicalware Tags applied to tickets migrate as HubSpot Ticket Labels. Tags used for categorization or routing logic transfer directly with no value transformation. We do not consolidate synonymous tags unless explicitly instructed; vocabulary differences between Logicalware and HubSpot label conventions are documented for the customer admin to reconcile post-migration. Tags used for content classification rather than ticket management are noted separately as a potential knowledge base tagging rebuild item.

Logicalware custom fields present in the export artifact migrate as HubSpot custom contact, company, or ticket properties. Field type mapping follows: string fields to single-line text, boolean fields to checkbox, date fields to date picker, numeric fields to number, and picklist-style fields to dropdown. Custom fields absent from the export (a common gap due to inconsistent Logicalware export behavior) are documented as unmapped rather than created as null-value placeholders. We recommend the customer admin reviews all unmapped fields against their Logicalware configuration during scoping.

Logicalware ticket status values (e.g., Open, Pending, Resolved, Closed) map to HubSpot Ticket status pipeline values. We configure the HubSpot ticket pipeline to match the Logicalware status vocabulary during schema design. Status values without a HubSpot equivalent are mapped to the nearest status and flagged. If Logicalware used custom status names, we create custom ticket status options in HubSpot rather than forcing a value-mapping that loses semantic meaning.

Logicalware priority values (e.g., Low, Medium, High, Urgent) map to HubSpot Ticket priority property values. Where Logicalware used numeric priority scores (1-5), we map to HubSpot's Low/Normal/High/Urgent scale and preserve the original numeric score in a custom field (original_priority_score__c) for reporting continuity.

Ticket created_date, updated_date, and closed_date from Logicalware export files migrate to HubSpot Ticket creation and last modified timestamps. Conversation message timestamps preserve the original chronological sequence. We do not override HubSpot's native createdate and lastmodified fields with current migration timestamps; historical dates are critical for support SLA reporting and customer satisfaction trend analysis.