Migrate from Dashly to Nutshell

Dashly Leads map to Nutshell Person records. Standard properties ($name, $email, $phone) migrate directly to Person Name, Email, and Phone fields. Custom properties defined in Dashly (without the $ prefix) are exported as structured field data and mapped to Nutshell Person custom fields during import. We run a pre-flight check to confirm all custom property names in Dashly have valid Nutshell custom field equivalents created before Person import begins. Visitor behavioral data (page views, referrer, UTM) is not migratable as structured records and is flagged in the handoff documentation.

Dashly Conversations are top-level threads linked to Leads. Each conversation carries status, assignee, source channel, and timestamps. We map Conversation records to Nutshell Activity records of type Task attached to the corresponding Person. The Conversation status (open, closed) maps to Activity completion status. Assignee email in Dashly is resolved against Nutshell Users by email during migration; any unresolved assignees are held in a reconciliation queue for the customer admin to provision before record import resumes.

Messages are embedded within Dashly Conversations, each recording sender (agent or visitor), body content, timestamp, and delivery channel. We preserve the full thread order by setting the Activity's description and timestamps to match the original message sequence. If a conversation has more than one significant message, we attach additional Notes to the Activity record to preserve the full dialogue. Author attribution migrates as a text label on the Note body. Channel metadata (web chat, email) is preserved in a custom Activity field.

Dashly Company records map directly to Nutshell Company. The company domain in Dashly becomes the Company Website field and is used as a dedupe key during import. Any custom company properties migrate as Nutshell Company custom fields. Company is created before any Person import so that the Company-Person relationship is satisfied at the moment of Person insert, using the link already stored in Dashly.

Dashly User accounts (support agents and admins with roles, email addresses, and availability settings) map to Nutshell Users by email address. We extract every distinct user referenced on Conversation and Message records and match against the Nutshell destination User table. Any Dashly User without a matching Nutshell User is held in a reconciliation queue, and the customer's Nutshell admin provisions missing accounts before Person and Activity import resumes.

Tags applied to Leads, Conversations, or Companies in Dashly are exported as flat label arrays and mapped to Nutshell's built-in tagging system, which supports tagging on both Person and Company records. All tag assignments are preserved during migration and reattached to the corresponding migrated records. If a tag name conflicts with a Nutshell system label, we append a suffix during import and document the rename in the mapping guide.

Dashly custom fields on Leads and Companies (properties without the $ prefix) are inventoried during discovery with their data types. We map text fields to Nutshell text custom fields, numeric fields to number custom fields, and date fields to date custom fields. Picklist or multi-select custom properties in Dashly map to Nutshell picklist or multi-select custom fields. We create all destination custom fields in Nutshell before migration begins and document any type conversions applied during the transform phase.

Leadbots are automation configs with trigger conditions, dialogue trees, and action sequences defined in Dashly's JSON schema. Nutshell has no native bot-builder or AI dialogue-tree feature, so leadbot logic cannot be migrated as functional automation. We export each active leadbot as a structured JSON config file and deliver a rebuild guide that maps Dashly trigger conditions to Nutshell Activity-based follow-up rules and assignee assignments. The customer's admin rebuilds the bot logic manually in Nutshell using the exported config as a reference.

Triggered messages define automated outbound sequences tied to visitor behavior or time delays. Dashly stores the trigger rules and message content as structured automation data. Since Nutshell does not have an equivalent automated outbound sequence feature, we export the triggered message configurations as JSON with a rebuild guide that maps each sequence step to a recommended Nutshell Activity template, follow-up reminder, or email template setup. Manual rebuild is required for all triggered message automations post-migration.

Dashly knowledge base articles are stored with title, body content, SEO settings, and category associations. Nutshell has no native knowledge base feature, so articles cannot be migrated as a functional replacement. We export articles as structured HTML files with metadata preserved, and the customer chooses the rebuild destination: an external knowledge base tool, a shared file repository with attachments on relevant Person or Company records, or a documented reference guide. The exported files are delivered as part of the migration handoff package.

Visitor session data (page views, referrer, UTM parameters, session duration) is ephemeral and aggregated by Dashly's analytics engine. It is not meaningfully migratable as structured CRM records to Nutshell because Nutshell's Person model does not support session-level behavioral tracking. We document the existence of visitor analytics data in the discovery output and flag it as outside migration scope. If the customer requires behavioral tracking post-migration, a separate analytics tool integration (e.g., Google Analytics, Mixpanel) is recommended.

Dashly Conversation assignee data maps to Nutshell Activity assignment fields. Routing rules that assign conversations to specific agents or teams are exported as configuration data. Because Nutshell does not have a native rule-based routing engine equivalent to Dashly's conversation assignment logic, routing rules are documented in the automation handoff guide and the customer rebuilds them as Nutshell Activity filters, team assignment rules, or manual setup in the Activity ownership model.