Migrate from MetroLeads to Zoho CRM

MetroLeads Leads map to Zoho CRM Leads. The lead_id becomes an external reference field for reconciliation. We map MetroLeads name fields to Zoho First_Name and Last_Name, with full_name mapped to the Full Name composite field if Zoho layout uses it. assigned_to user references resolve by email match against Zoho Users. The MetroLeads lead_group UUID is preserved as a custom text field for downstream grouping logic in Zoho.

MetroLeads Companies map to Zoho CRM Accounts. The API path /companies/<company_uuid>/leads/ establishes the parent-child hierarchy that maps to the Account-Contact relationship in Zoho. We export Company records first, create Zoho Accounts, then associate each MetroLeads Lead to its parent Account during Lead import using the company reference.

MetroLeads stores phones as an embedded array within Lead records with type (Work, Mobile) and phone number. We flatten these into a normalized contact-phone table during transformation, preserving type metadata. On import to Zoho, each phone entry becomes a separate row in the multi-line Phone subform on the Lead record with the phone type mapped to the subform field label.

MetroLeads stores emails as an embedded array within Lead records with type and address. We extract these into a standard contact-email table, preserving Work, Personal, and other type metadata. On import to Zoho, each email entry becomes a separate row in the multi-line Email subform on the Lead record.

MetroLeads Events track engagement history tied to Leads. We preserve event_type and event_timestamp, mapping event_type to Zoho Task (for calls and follow-ups) or Event (for meetings) depending on the MetroLeads event classification. The event-to-Lead association requires join mapping across the MetroLeads API response structure; we resolve the Lead reference by lead_id during import.

MetroLeads Advanced Data Modules are tenant-specific data structures extending the base schema. Their field definitions vary per organization. We export the module schema alongside records, pre-create equivalent Zoho Custom Modules (using _C.csv file naming convention per Zoho migration wizard expectations), and map all fields including lookup relationships to Accounts or Contacts. The customer confirms the destination Custom Module structure before data import begins.

MetroLeads source_tags are string arrays on Lead records indicating lead disposition (e.g. disposition_answered). We export the raw tag strings and map them to Zoho Tags, which are attached to Lead records via the Tag feature. The tag vocabulary is preserved as-is unless the customer requests normalization during scoping.

MetroLeads Lead state is a tenant-configured string field (e.g. contacted) representing lifecycle stage. The valid values are per-tenant and not standardized. We extract all unique state values during the export scan, present them to the customer for lifecycle-stage mapping against Zoho standard values (New, Contacted, Qualified, Unqualified, etc.), and flag any unmapped values so no records are orphaned with an unresolvable stage during import.

MetroLeads User records (id, name, role assignments) map to Zoho CRM Users. We export Users and preserve owner assignments on Leads so that assigned_to and user_assigned_to references resolve correctly. Matching is by email address. Any MetroLeads User without a matching Zoho User goes to a reconciliation queue for the customer's admin to provision before record import resumes.

MetroLeads lead_fields store tenant-specific custom property values keyed by property ID (e.g. customer_id_070) rather than human-readable names. The property name catalog is a separate API call. We fetch the full MetroLeads property schema first, build an ID-to-name mapping, then apply that mapping so that destination Zoho custom fields carry the customer's intended field names. Property types are mapped to equivalent Zoho field types (text, number, date, picklist, checkbox) based on the MetroLeads property schema.