Migrate from Mothernode to Nutshell

Mothernode Contacts map directly to Nutshell Person records via the Contacts API endpoint. We extract name, email, phone, address, and custom field data and write to the Person entity using Nutshell's JSON-RPC newPerson method. Nutshell's API uses Contacts as the internal entity type name even though the product UI refers to People, so our API calls target the correct endpoint regardless of UI label. Mothernode Contacts associated with a Department are flagged for Team assignment review during scoping.

Mothernode Customers map to Nutshell Account records. The distinction between Customer and Contact in Mothernode (documented in their FAQ: Customers represent organizations, Contacts represent individuals) aligns structurally with Nutshell's Account-Person model. We extract the customer name, address, and any custom fields and write to the Account entity using Nutshell's newAccount method. Mothernode Customers without associated Contacts still migrate as standalone Accounts to preserve the organizational hierarchy.

Mothernode Leads and Opportunities share a single API endpoint (leads-and-opportunities), and we separate them using the record type indicator in the API response before migration. Mothernode Leads map to Nutshell Lead records using the newLead method. The source lead status maps to Nutshell's Lead status field. Any lead score or qualification data present in Mothernode custom fields migrates to Nutshell Lead custom fields.

Mothernode Opportunities (from the shared leads-and-opportunities endpoint) map to Nutshell Lead records with the opportunity amount, stage, and close date preserved. If the destination Nutshell instance has progressed to a won stage, we recommend creating an Account-Person-Opportunity chain for long-term pipeline reporting rather than leaving opportunities as standalone Leads. We flag this decision during scoping and document the chosen mapping in the pre-import review.

Mothernode Notes and Events both live under the Notes/Events API endpoint. We extract note content, associated entity IDs (contact_id, customer_id, lead_id), timestamps, and author attribution. Notes migrate to Nutshell Activities linked to the relevant Person (contact), Account (customer), or Lead record. Activity type is set to note to preserve the original record semantics.

Mothernode Events migrate to Nutshell Activities with event type, date/time, duration, and the associated Contact or Lead link preserved. Calendar-bound events from Mothernode map to Nutshell Activities with a meeting type designation. Nutshell's Activity entity covers both meetings and notes, so we use the type field to distinguish them after import.

Mothernode Invoices have a documented API endpoint but Nutshell does not have a native Invoice object in its standard CRM tiers. We extract invoice line items, totals, status, and customer reference and write them to Nutshell as Activity records with a custom note field capturing the invoice data, or flag them for the customer's admin to evaluate Nutshell's integration ecosystem (QuickBooks, Xero, or other billing tools) as the replacement for invoice management. We document this gap in the pre-import scope.

Mothernode's API does not expose a dedicated Users endpoint in the public documentation. Owner references on Lead, Opportunity, Note, and Event records use owner_id. We resolve owner_id by matching the associated email address against Nutshell's User list during migration scoping. Any Mothernode Owner without a matching Nutshell User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

Opportunity records in Mothernode carry a pipeline stage value governing workflow state. Stage names and count vary by Mothernode configuration. We extract the stage names from source data and create Nutshell Lead status values or custom status fields that match the original stage labels. Stage probability mapping is preserved where available in the source payload.

Custom fields on Contacts, Customers, Leads, and Opportunities are not explicitly documented in the Mothernode API reference. We probe the API response schema during extraction to identify any non-standard fields beyond the documented payload structure. Unmapped custom fields are flagged in the pre-import review, and we configure corresponding custom fields in Nutshell before migration where the destination schema supports the field type.