Migrate from Serviceform to Nutshell

Discovery and data audit

We audit the Serviceform account across Leads, conversation history volume, form count, chatbot flow count, ATS usage, team members, and active integrations. Because Serviceform lacks a documented API, we assess the available export methods (UI-based extraction, direct coordination with Serviceform support, or both) and scope the conversation volume to understand usage-based cost implications. We produce a written discovery document with record counts per object, identified export challenges, and a migration scope recommendation.

Data extraction coordination

We coordinate the data extraction from Serviceform, working within the constraints of their UI-based export mechanisms. For conversation history, we extract full transcripts in a structured format. For Leads, we export standard fields plus any custom properties. For ATS data, we run a separate export from the ATS module. We validate the export files for completeness before mapping begins. Any gaps identified in the export (missing fields, truncated transcripts) are flagged to the customer for resolution with Serviceform support.

Nutshell schema setup and custom field design

We configure the destination Nutshell account with custom fields to receive Serviceform data that has no direct standard equivalent. This includes custom fields on Person for chatbot metadata (channel, lead source, qualification score), form field data, and ATS applicant flags. We set up Company records in advance so that Person-to-Company lookups are resolved at import time. We document the chatbot and form rebuild specification in parallel, capturing intent mappings, flow trees, and conditional logic rules from Serviceform.

Sandbox validation and mapping refinement

We run a test migration into a Nutshell trial or sandbox environment using representative data volume. The customer's lead or operations team spot-checks migrated Person records, Company associations, and Activity transcripts against the source data. Any field mapping corrections, custom field additions, or de-duplication rule adjustments happen here before production migration begins. The chatbot and form rebuild specification is reviewed with the customer at this stage.

Production migration in dependency order

We run production migration in record-dependency order: Companies first (from extracted company names), then Persons (with the Serviceform lead source, qualification status, and any form field data as custom fields), then Activities (conversation transcripts attached to the corresponding Person). ATS applicant records run on a separate track and land in the same Person object with the applicant flag set. Each phase emits a row-count reconciliation report before the next phase begins. Chatbot flow data is not imported; it is documented for manual rebuild.

Cutover, validation, and rebuild handoff

We freeze Serviceform writes during cutover and run a final delta migration of any records modified during the migration window. We validate Person record counts, Company associations, and Activity attachment rates against the discovery baseline. We deliver the chatbot rebuild specification and form conditional logic documentation to the customer's admin team. We provide a one-week hypercare window for reconciliation issues. We do not rebuild chatbot flows or form logic as part of the data migration scope; that work is handled by the customer's team using the specification we deliver.