Migrate from Mothernode to Microsoft Dynamics 365 Sales

Mothernode Customer records represent organizations and map directly to Dynamics 365 Account. The Customer company name becomes Account Name, the website field maps to Account Website, and the customer identifier becomes the external ID for deduplication during import. We extract all Customer records before any Contact or Opportunity migration because Dynamics 365 Account is the parent of Contact and the WhatId reference of Opportunity.

Mothernode Contact records map to Dynamics 365 Contact and attach to the Account resolved from the associated Customer record. Each Contact's email address is used as the primary deduplication key. If a Mothernode Contact references a Customer that does not yet have a corresponding Account, we create the Account first using the Customer data and then link the Contact. Phone, address, title, and custom fields migrate to typed Dynamics 365 fields or custom fields pre-created during schema design.

Mothernode Lead records (distinct from Opportunities per the platform's FAQ on Lead vs Opportunity semantics) map to Dynamics 365 Lead. The lead source, status, rating, and estimated value fields transfer to the corresponding Dynamics 365 Lead fields. We preserve the original lead status from Mothernode in a custom field mn_original_status__c for reconciliation after migration.

Mothernode Opportunity records map to Dynamics 365 Opportunity. We resolve the parent Account reference by matching the linked Customer identifier to the migrated Account record. The pipeline stage name from Mothernode maps to a corresponding Dynamics 365 Opportunity Stage, and we create a Sales Process and Record Type in Dynamics 365 that matches the source pipeline structure before migration begins.

Each Mothernode pipeline becomes a Dynamics 365 Record Type on Opportunity with a corresponding Sales Process that controls the allowed stage values. We extract stage names and probability percentages from the source data and create matching stage entries in Dynamics 365. If the customer has customized stage names in Mothernode, we preserve them as a custom picklist field mn_pipeline_stage__c on Opportunity alongside the standard StageName.

Mothernode Notes map to Dynamics 365 Annotation records linked to the parent Contact, Account, Lead, or Opportunity via the ObjectId field. Note content, author attribution, and timestamps migrate. We resolve the parent record reference using the associated entity IDs extracted alongside the note payload and set the ObjectTypeCode to match the destination entity type.

Mothernode Events map to Dynamics 365 Appointment records. Event type, date/time, duration, location, and associated Contact or Opportunity links transfer to the Appointment's StartTime, EndTime, Location, and Regarding fields. We resolve RegardingObjectId by matching the linked Contact or Opportunity identifier to the migrated record.

Mothernode Invoice records map to Dynamics 365 Invoice. We extract line items, totals, invoice status, and the customer reference. The Invoice is linked to the parent Account via the AccountId resolved from the associated Customer. Any Invoice records referencing Products that do not yet exist in Dynamics 365 are held in a pre-create queue until the product catalog is migrated.

Mothernode does not expose a dedicated Users endpoint in its public API documentation. Owner_id is referenced on Lead, Opportunity, Event, and Note records, but the user record itself is not directly accessible. We extract owner_id values from these records, attempt to derive owner email from the associated contact record (where the owner may be listed as a Contact), and match by email against the Dynamics 365 User table. Any owner without a resolvable match enters a reconciliation queue for the customer's admin to provision the corresponding Dynamics 365 User before record import resumes.

Custom fields on Contacts, Customers, Leads, and Opportunities are not explicitly documented in the Mothernode API reference. We probe the API response schema during the extraction phase to identify any non-standard fields in the returned payload. Discovered custom fields are created in Dynamics 365 with type mapping (text to Text, numeric to Number, date to DateTime) and attached to the relevant entity before the data import phase. Fields that cannot be mapped to a standard Dynamics 365 type are flagged for a pre-import design review.

Project Folders are an Enterprise-tier feature in Mothernode with no confirmed API endpoint in the public documentation. We probe for API availability during the extraction phase and treat any 403 or 404 response as a manual export flag. The customer should schedule a parallel manual export from the Mothernode UI before the migration window opens. We do not include Project Folders in the automated migration scope.

Job Center Modules handle real-time job or project tracking for service and manufacturing operations and are gated behind the Enterprise tier with custom pricing. The public API documentation does not confirm endpoints for Job Center data. We flag Job Center as requiring manual UI export and document the record types and fields the customer should capture from the Mothernode interface. If the customer requires job tracking in Dynamics 365 post-migration, Project Service Automation or Field Service modules are the natural destination, but these require a separate licensing and implementation scope.