Migrate from Talisma to Nutshell

Talisma Contact records map to Nutshell Person. Standard fields (name, email, phone, address, title) migrate directly. Custom fields from the Talisma configuration export map to Nutshell custom fields on Person; we pre-create these in Nutshell during schema design before import. The Contact-to-Account relationship resolves to the Person-Company link in Nutshell using the Talisma Account foreign key at migration time.

Talisma Account records map to Nutshell Company. Company name, website, industry, address fields, and any custom properties migrate directly. Company is created before Person records so that the Company link is satisfied at Person insert time. Any Talisma Account with no associated Contacts becomes a standalone Company record in Nutshell.

Talisma Cases have no direct Nutshell equivalent because Nutshell does not have a native Case or Ticket object. We handle this by mapping Case status, priority, owner, and description to a structured Note attached to the linked Person or Company record, using a standardized prefix pattern (e.g., [CASE-{case_id}]) that preserves the case identifier for reference. Multi-case threading (parent-child case relationships) becomes a custom field or a cross-reference Note. The customer may also choose to create a Nutshell custom entity for Cases on the Enterprise tier; we scope this during discovery.

Talisma interaction logs for email and phone map to Nutshell Activity records (Task subtype) with the original timestamp preserved. Interaction type (email_inbound, email_outbound, phone_inbound, phone_outbound) migrates as a custom field on the Activity. We link each Activity to the correct Person record using the Talisma Contact reference at migration time. Nutshell's Activity timeline does not distinguish between engagement types by default, so a custom field stores the interaction type for filtering.

Talisma Chat and Cobrowse sessions are stored in a separate module from standard interaction logs. We extract session metadata (session date, duration, cobrowse event flags) and transcript text where accessible, and write these as structured Notes attached to the related Person or Company in Nutshell. Cobrowse event data does not map natively to any standard CRM activity object in Nutshell; the structured Note preserves the content for search and reference. This is documented explicitly so the customer understands why Cobrowse sessions appear as Notes rather than native activity records.

Talisma Product records with SKU, name, description, and pricing fields map to Nutshell Product. We create Nutshell Products during migration before Deals are imported so that line items can reference them. Bundling logic and complex pricing rules from Talisma (discount schedules, volume tiers) do not transfer; we document these in the product catalog handoff document for the customer's admin to rebuild in Nutshell's pricing configuration.

Talisma user records with name, email, role, and team assignment map to Nutshell Users. We match by email address. Talisma roles (agent, supervisor, admin) do not map 1:1 to Nutshell's permission model, so we apply a default role mapping (all migrating users become Nutshell Members) and flag any role that requires a higher Nutshell permission tier (e.g., Admin) during reconciliation. Inactive Talisma users can be migrated as inactive Nutshell Users to preserve historical assignment.

Talisma file attachments linked to Contacts, Cases, or Accounts migrate as Nutshell Attachments on the corresponding Person, Company, or Deal record. We preserve the original filename and association. Some Talisma deployments store attachments in a proprietary or database-blob format — we test re-encoding during staging and flag any file that cannot be restored to its original format. Customers with more than 2,000 attachments should add additional validation time to the cutover window.