Migrate from FieldPro to Mailchimp

Visit history migrates as tags, not as a functional activity log

FieldPro's visit records are its core data asset — every store audit, replenishment visit, and routine check is a visit record. Mailchimp has no field-activity object: it cannot store visit date, visit type, and audit outcome as independent records linked to a contact. We translate visit history into Mailchimp tags (VISIT_30D, AUDIT_PASS, VISIT_FREQ_HIGH) and contact properties (LAST_VISIT_DATE, VISIT_COUNT). These are useful for segmentation but cannot power Mailchimp automations that depend on a structured activity timeline the way FieldPro does. Audit workflow triggers, visit-based alerts, and route resequencing must be rebuilt in Mailchimp's automation builder or abandoned.

Internal employee emails inflate Mailchimp contact count and billing

FieldPro stores both customer contacts and internal field-employee contacts in the same contact object. Mailchimp bills per subscriber — each member in your audience counts toward your plan tier whether they are a customer or an internal user. If you migrate FieldPro employee contacts to Mailchimp as regular members, you pay for every field rep and manager in your Mailchimp bill. We apply a domain-exclusion filter during migration: contacts with email addresses from your specified internal domains (e.g., @yourcompany.com, @corp.) are tagged EMPLOYEE and can be excluded from your subscriber count via Mailchimp segment filtering. This requires you to specify internal domains during planning — missed domains mean inflated billing.

Mailchimp merge field name limits break FieldPro JSON custom properties

FieldPro custom properties sometimes store structured data as JSON strings — for example, a shelf_compliance property with value '{"score": 92, "notes": "minor gap aisle 3"}'. Mailchimp merge fields accept only flat string or number values, not JSON. We parse JSON property values and split them into separate merge fields (SHELF_SCORE, SHELF_NOTES). This requires per-property inspection during the planning phase. Properties with deeply nested JSON structures or arrays of variable length may need manual decisions about which elements to keep. Merge field names are also capped at 30 characters and cannot contain spaces — long FieldPro property names get truncated, which can cause naming collisions if two truncated names resolve to the same string.

Mailchimp API rate limits require batched migration for large audiences

Mailchimp's API enforces hourly rate limits that vary by plan tier (1,000–100,000 API calls per hour depending on your Mailchimp plan level). FieldPro setups with 50,000+ contacts require batching across multiple hours to stay within limits. We schedule migration batches, monitor rate-limit headers returned by the Mailchimp API, and resume automatically after the cooldown window. This extends migration clock time but does not cause data loss. If your Mailchimp plan is on the lower API tier, we will surface this during scoping and adjust the batch schedule accordingly.

Territory and outlet hierarchy collapses to flat tags in Mailchimp

FieldPro outlets often have hierarchical relationships (region → district → store) or multi-tier territory assignments. Mailchimp supports groups and tags, but not a native hierarchy. We flatten hierarchical territory data into a combination of merge fields (REGION, DISTRICT) and tags (REGION_NORTH, DISTRICT_CHICAGO) that preserve the information but require Mailchimp's segmentation builder to reconstruct multi-level filters. If your FieldPro territory logic depends on nested hierarchies for routing or assignment, those relationships are not mechanically replicated — they become filterable attributes rather than active routing logic.