Migrate from Mothernode to HighLevel

Mothernode Contact records map directly to GoHighLevel Contact. The email address serves as the dedupe key during import. We map first_name, last_name, email, phone, address fields to their GoHighLevel equivalents and preserve any Mothernode custom properties as GoHighLevel custom fields on the Contact object. Contact import runs first so that any subsequent Customer-to-Company mapping can link via email domain.

Mothernode Customers are business entities, not individual people. We split this into GoHighLevel Company (business name, address, industry) and a primary Contact record (the main business contact stored in the Mothernode Customer payload). The Customer record type is preserved in a custom field mn_record_type__c for audit. This split is the most consequential design decision in the migration because it governs how Opportunities attach to the right parent.

Mothernode Leads (distinct from Opportunities in the platform's FAQ) migrate as GoHighLevel Contacts with a custom field mn_lead_source__c carrying the original lead attribution data. GoHighLevel does not have a separate Lead object; all prospects live in the Contact model. We tag imported Leads with a lifecycle_status custom field set to imported_lead so that the customer's admin can segment them for nurture workflows.

Mothernode Opportunities map to GoHighLevel Opportunities with the pipeline stage mapped to a GoHighLevel Pipeline stage. We extract the deal amount, close date, probability (if present), and owner_id and write these to the corresponding GoHighLevel Opportunity fields. If Mothernode Opportunities reference a Contact or Customer, we resolve the GoHighLevel Contact or Company lookup at migration time.

Mothernode pipeline stages migrate as GoHighLevel Pipeline stages. Stage names, probabilities, and order are extracted from the source data and recreated in GoHighLevel before any Opportunity records are imported. Each GoHighLevel Pipeline is associated with a Status category (Open, Won, Lost) matching the Mothernode stage semantics.

Mothernode Notes migrate as GoHighLevel Notes attached to the parent Contact or Opportunity. We extract note body, created timestamp, and associated entity ID and write these as GoHighLevel Note records linked via the relationship to the parent Contact or Opportunity. Author attribution is preserved in a custom field if available.

Mothernode Events (calendar appointments) migrate as GoHighLevel Calendar Events with start time, end time, location, and attendee data preserved. Events without a specific time or duration migrate as Tasks with the activity type set to meeting. We resolve the associated Contact or Opportunity reference at migration time using the parent lookup.

Mothernode Invoices migrate to GoHighLevel Invoices if the destination account has the Payments module enabled. We extract line items, totals, status, and customer reference. Invoice records require an existing Contact or Company in GoHighLevel before the invoice import runs, enforcing the dependency order of the migration phases. We flag any invoices with status of voided or deleted as archived records.

Mothernode owner_id on Lead, Opportunity, and Event records is resolved by email match against the GoHighLevel User table. If a matching GoHighLevel User does not exist at migration time, the record is held in a reconciliation queue and assigned to a migration service account with a custom field mn_original_owner__c preserving the original owner name for post-migration reassignment.

Mothernode Project Folders are an Enterprise-tier feature with unconfirmed API availability. We probe the endpoint during extraction, but if it returns 403 or 404, we flag the object as requiring manual UI export. GoHighLevel does not have a Project Folder or project management module as a native object; customers relying on this feature should plan for a parallel manual export and an alternative project tracking tool post-migration.