Migrate from MetroLeads to Microsoft Dynamics 365 Sales

MetroLeads Leads map to Dynamics 365 Lead for unqualified prospects or Contact attached to an Account for qualified buyers. The split rule is defined during discovery by reviewing MetroLeads state values and mapping them to Dynamics 365 Lead Status and Contact Lifecycle Stage. The original MetroLeads state is preserved in a custom field metro_state__c on both Lead and Contact for audit and historical reporting. We also extract and resolve assigned_to user references by matching against Dynamics 365 Users by email before the Lead or Contact is created.

MetroLeads Companies map directly to Dynamics 365 Account. The Company UUID becomes the external ID for deduplication. The /companies/{uuid}/leads/ hierarchy establishes the parent relationship that informs how grouped Leads map to Accounts. If a Company has no Leads, it still migrates as an Account with no Contacts. Company-level custom properties migrate to Account custom fields using the property ID resolution step before field names are written.

MetroLeads Events track engagement history tied to Leads. We export the event_type and event metadata, then split into Dynamics 365 Task (for calls and generic tasks), Email (for email activities), and Event (for meetings). The event-to-lead association is preserved through the WhoId field pointing to the migrated Lead or Contact record. ActivityDate ordering is preserved so the timeline reflects the original sequence.

Phones are embedded arrays within MetroLeads Lead records with type metadata (Work, Mobile, etc.). We extract each phone entry and write it to the corresponding typed phone field on the migrated Contact record. Phone type metadata is preserved in a custom field or the phone number label so that Work versus Mobile versus Home is distinguishable in Dynamics 365.

Emails are embedded arrays within MetroLeads Lead records with type and address. We extract each email entry and write it to the appropriate typed email field on the migrated Contact record. Primary versus secondary email designation is preserved through the email address order in the source array.

MetroLeads lead_fields store tenant-specific custom property values keyed by internal property IDs (e.g. customer_id_070) rather than human-readable names. We fetch the MetroLeads property schema first, build an ID-to-name mapping, then create corresponding custom fields in Dynamics 365 with the correct field types (text, number, date, picklist) before any data is written. This prevents destination fields from being named after internal MetroLeads IDs.

Advanced Data Modules are tenant-specific data structures extending the MetroLeads base schema with field definitions that vary per organization. We export the module schema alongside records, then map each module to a Dynamics 365 Custom Object on Dataverse with equivalent field types and relationships. The source module definition is documented as the target schema specification for the customer's admin to review before import.

Intellisearch is a MetroLeads-specific search and scoring layer built on top of Lead data. The scoring logic and saved searches do not map 1:1 to Dynamics 365 standard objects. We export the raw Intellisearch configuration data and the resulting lead scores as custom fields on the Lead or Contact record, preserving the score values for reference even if the calculation logic cannot be replicated.

Source Tags are string arrays on MetroLeads Lead records indicating lead disposition (e.g. disposition_answered). We export the raw tag strings and map them to a Dynamics 365 multi-select picklist field on Lead or Contact, or to a custom text field if the tag count exceeds picklist capacity. The customer chooses the tag strategy during scoping.

MetroLeads Lead state is a tenant-configured string field (e.g. contacted, qualified) where valid values vary per MetroLeads instance. We extract all unique state values during the export scan, present them to the customer for lifecycle-stage mapping against Dynamics 365 Lead Status values, and flag any unmapped values so no records are orphaned during import. This step prevents silent data loss where MetroLeads state values have no corresponding Dynamics 365 picklist entry.

Lead Group is a MetroLeads-specific UUID reference grouping related Leads. This concept does not have a direct Dynamics 365 standard equivalent. We export the UUID and the grouped Lead membership, then map grouped Leads to Dynamics 365 Teams if the customer has teams enabled, or to a custom text field on Lead that stores the original MetroLeads lead_group UUID for grouping reference.

MetroLeads User records with id, name, and role assignments are exported for owner resolution. We match MetroLeads assigned_to references to Dynamics 365 Users by email lookup. Any MetroLeads Owner without a matching Dynamics 365 User goes to a reconciliation queue for the customer's admin to provision before record import resumes. OwnerId references are required on most standard objects, so this step gates the record import phases.