Migrate from MetroLeads to Salesforce Sales Cloud

MetroLeads Leads with state values indicating unqualified prospects map to Salesforce Lead. Leads with state values indicating qualified buyers map to Salesforce Contact tied to a Salesforce Account. We extract all unique state values during discovery, present them to the customer for lifecycle-stage mapping, and apply the split rule during the transform phase before import. The original MetroLeads state value is preserved in a custom field ml_original_state__c on both Lead and Contact for audit and reporting continuity.

MetroLeads Companies are parent containers for Leads via the /companies/{company_uuid}/leads/ API hierarchy. They map directly to Salesforce Account. We export Companies first, establish them as Account records, then resolve the parent-child relationship when Leads import by matching company_uuid to Account external ID. Account is always created before any child Lead import so the AccountId lookup is satisfied.

MetroLeads Events track engagement history tied to Leads, with a stable field structure and event_type distinguishing call, email, meeting, and task variants. We split by event_type during export: call events map to Salesforce Task with TaskSubtype=Call and CallDisposition; email events map to Salesforce Task with an associated EmailMessage record; meeting events map to Salesforce Event; general task events map to Salesforce Task. Event-to-Lead associations are preserved via WhoId resolution at migration time.

Intellisearch is a MetroLeads-specific lead scoring and saved-search layer that applies algorithmic scoring to Lead data. The scoring logic, weighting rules, and saved search criteria do not map 1:1 to standard Salesforce objects. We export the raw Intellisearch configuration as a JSON payload and deliver it as a written specification document. Salesforce admins can rebuild scoring logic as a custom object with formula fields and custom scoring rules, or as Salesforce Einstein Activity Capture scoring if Einstein is licensed.

Advanced Data Modules are tenant-specific data structures extending MetroLeads's base schema, with field definitions that vary per organization. We export the module schema alongside all records during discovery. Each module maps to a Salesforce custom object with __c suffix, with field types matched (text to Text, number to Number, date to Date). Lookup fields on Advanced Data Modules that reference Leads or Companies are resolved to Salesforce IDs during the transform phase before import.

MetroLeads User records (id, name, role assignments) export by email match against the destination Salesforce org's User table. Owner references on Leads and Companies resolve to OwnerId via email lookup. Any MetroLeads User without a matching Salesforce User is held in a reconciliation queue; the customer's Salesforce admin provisions the missing Users before record import resumes.

MetroLeads Phones are embedded arrays within Lead records with type (Work, Mobile, etc.) and phone number. We flatten these into Salesforce Contact standard phone fields (Phone, MobilePhone) and custom Phone type fields (ml_phone_work__c, ml_phone_mobile__c) matching the type metadata. Phone number formatting is preserved as-is during import; Salesforce validation rules for phone format should be reviewed before migration.

MetroLeads Emails are embedded arrays within Lead records with type and address. We extract Work and Personal email addresses into the Contact standard Email and HomeEmail fields, with additional type-specific addresses mapped to custom fields (ml_email_work__c, ml_email_personal__c). Email addresses are validated for format before import to prevent rejection by Salesforce email validation rules.

MetroLeads lead_fields on each Lead store tenant-specific custom property values keyed by property ID (e.g. customer_id_070). Property naming conventions are per-tenant and not self-describing. We fetch the full MetroLeads property schema catalog first, build an ID-to-name mapping, then apply that mapping during field mapping so destination custom fields use human-readable names derived from the schema. Custom field types are inferred from the property value types in the schema catalog.

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 Salesforce multi-select picklist on Lead (ml_source_tags__c) if the tag cardinality is under 150 unique values. If cardinality exceeds Salesforce's multi-select limit, we create a custom tag-lookup object and TopicAssignment records for each tag reference.

MetroLeads Lead state is a tenant-configured string field (e.g. contacted) representing lifecycle stage. Valid values vary by tenant, meaning 'contacted' in one MetroLeads instance may not exist in another. We extract all unique state values during the discovery scan, present them to the customer for lifecycle-stage mapping, and flag any unmapped values so no records are orphaned with an unresolvable state. Mapped values populate Salesforce Lead Status or a custom ml_original_lifecycle__c field.

lead_group is a MetroLeads-specific UUID reference grouping related Leads. This is not a standard CRM concept in Salesforce. We export the lead_group UUID and the set of Leads sharing each group. Options for destination mapping include Campaign membership (each group becomes a Campaign with Leads as CampaignMembers), a shared List, or a custom grouping custom field (ml_lead_group__c) holding the original UUID for reference. The customer selects the preferred grouping strategy during scoping.

MetroLeads merge-pending Lead pairs are identified during the export scan by checking the merge API's pending state. When two Leads should be merged in MetroLeads, we present the pair to the customer for explicit survivor selection before executing the Salesforce import. The survivor record absorbs fields from the merged record per the customer's preference, and the duplicate record is excluded from import. This prevents silent field overwrites that the MetroLeads merge API's default primary-field-priority behavior would otherwise cause.

MetroLeads native cloud telephony embeds call logs directly in Lead records. These call log records export as Task objects with TaskSubtype=Call, CallDurationInSeconds, CallDisposition, and a CallRecordingUrl custom field pointing to the VOIP recording. The WhatId on the Task points to the parent Lead (or converted Contact after split). Call timestamps preserve the original MetroLeads call time for activity timeline ordering.