Migrate from Handyman to Mailchimp

Handyman has no native marketing consent field — unsubscribe states require pre-migration mapping

Handyman does not track email marketing consent as a structured field. If your business maintains unsubscribe lists separately (in a spreadsheet, separate CRM, or Handyman notes), that data must be identified and mapped before migration begins. We check for unsubscribe indicators in customer notes and contact fields, but explicit consent tracking in Handyman requires your team to flag which contacts should land as Unsubscribed versus Subscribed in Mailchimp. Failing to do this means all Handyman contacts migrate as Subscribed, which Mailchimp's compliance system will flag if those addresses have previously bounced or unsubscribed elsewhere.

Mailchimp's subscriber status import requires exact value mapping — mismatches cause silent failures

Mailchimp's bulk import API accepts subscriber status as a column value (Subscribed, Unsubscribed, Bounced, Archived, Cleaned). If Handyman data uses different labels or blank values for status fields, those records default to Subscribed silently. We validate status values against Mailchimp's allowed enum before the import run, mapping any Handyman-specific status strings to their Mailchimp equivalents. Any records with missing or unresolvable status are flagged for your review rather than being defaulted, preventing unintended subscription of contacts who should not receive marketing emails.

Job and invoice history cannot map to Mailchimp records — only tags and merge fields survive

Mailchimp is a flat contact list with no support for related records. Handyman job histories (multiple appointments per customer, different service types, recurring visits) have no native Mailchimp object to represent them. We handle this by applying tags for each service type and storing job count and last-job-date as merge fields, but the granular line-item detail of invoices and estimates does not transfer. If your Mailchimp segmentation strategy depends on invoice amounts, line-item products, or detailed job descriptions, those use cases require rebuilding with Mailchimp-native data collection forms or integrating with a separate job management system.

Handyman custom properties require Mailchimp custom field pre-creation before data lands

Handyman supports custom properties on customer records with arbitrary labels and value types. Mailchimp custom fields must be created manually within each Audience before data imports. We deliver a custom field creation checklist based on the Handyman custom property inventory, specifying the field name, type (text, number, date, dropdown), and dropdown options where applicable. If custom fields are not created before the migration run, Handyman data for those properties is skipped rather than causing an import error. This is a planning step your team (or our team acting as your Mailchimp admin) must complete before the migration executes.

Duplicate email addresses in Handyman collapse to a single Mailchimp subscriber

Mailchimp enforces email address uniqueness within a single Audience — each email address maps to one subscriber record. Handyman allows duplicate customer records with the same email address (e.g., a household with two contacts sharing one email). During migration, we identify duplicate emails and flag them before import. Your team decides whether to collapse to a single record, create separate Audience members using Mailchimp's +address syntax (e.g., [email protected]), or exclude duplicate records from the migration entirely. This decision point adds a validation step before the import run.