Migrate from LeadMaster to Microsoft Dynamics 365 Sales

LeadMaster Accounts map directly to Dynamics 365 Account records. The primary contact link migrates as a separate Contact record with the accountid lookup set to the parent Account. All standard address fields (address1, address2, city, state, zip, country) transfer. LeadMaster custom fields on Account are mapped to Dynamics 365 custom fields (new_fieldname) that must be pre-created in the target environment before migration so that no record is rejected for missing attribute requirements.

LeadMaster Leads map directly to Dynamics 365 Lead records. Owner assignment (hubspot_owner_id equivalent) migrates by resolving the owner email to a Dynamics 365 User. Lead status, source, and lifecycle fields from LeadMaster Smart Queue metadata are preserved as custom fields in Dynamics if no native equivalent exists. The leadscore__c custom field carries any imported lead scoring value.

LeadMaster Opportunities map to Dynamics 365 Opportunity. Stage, amount, close date, owner, and account link transfer. Custom pipeline stages from LeadMaster require mapping against the target Dynamics 365 Sales Process stage list during import configuration. We create a Sales Process per LeadMaster pipeline before Opportunity records are inserted so that stage values are valid at the moment of record creation.

LeadMaster Cases migrate to Dynamics 365 Case records. The destination org must have Service Cloud (or the Case entity enabled) for full support. Case number, status, priority, description, and associated account or contact links transfer. Conversation threads migrate as EmailMessage records linked to the parent Case. If the destination has no Service Cloud license, Cases are mapped to a custom entity or to Tasks as a fallback, determined during scoping.

LeadMaster custom form definitions are inventoried during discovery and the submitted response data is mapped to existing Lead, Contact, or Account records. Where a form field has no equivalent in Dynamics 365 schema, we fall back to a custom field (pre-created) or a structured Notes field to preserve the data. The form layout itself does not migrate and must be replicated as a Dynamics 365 custom form or Power Apps canvas form post-migration.

LeadMaster marketing campaigns migrate to Dynamics 365 Campaign records with campaign type, status, budget, and target dates preserved. Contact and Lead associations from the campaign migrate as CampaignMember records. Email send history migrates as CampaignActivity records where the target Dynamics 365 edition supports them. Automated sequences and workflow triggers associated with the campaign are documented separately and do not transfer as executable logic.

LeadMaster landing page templates and form integrations are documented during discovery. The page content is exported as HTML. The form-to-record routing must be re-established in the destination marketing or form platform post-migration. Dynamics 365 does not include landing page hosting in the base Sales license; customers typically use Power Pages, a separate marketing tool, or a third-party platform for this function.

LeadMaster user accounts and role assignments map to Dynamics 365 User records by email address. Active and inactive status is preserved. Owner assignments on Leads, Opportunities, Cases, and Activities are maintained by resolving the owner email to the User record's systemuserid. Any LeadMaster owner without a matching Dynamics 365 User is held in a reconciliation queue for the customer's admin to provision before record migration continues.

LeadMaster activity records (calls, emails, meetings, logged tasks, notes) migrate to Dynamics 365 Task, Event, and Note records. Call duration and disposition are mapped to custom Task fields. Meeting start and end timestamps migrate to Event with location preserved. Notes migrate as Dynamics 365 Note records linked via Regarding (objectid) to the parent Lead, Contact, Account, or Opportunity. Activity dates are preserved to maintain the engagement timeline ordering.

LeadMaster Smart Queue filter definitions are documented during discovery. Each Smart Queue is translated into a Dynamics 365 Saved View (filter criteria on the entity) with the equivalent field names and operators. The mapping table is delivered as a written document so the customer's admin can create the corresponding Views in Dynamics 365. Smart Queue automation triggers are documented separately and do not migrate as active filters.