Migrate from Signpost to Mailchimp

Signpost Contacts migrate to Mailchimp Audience members. The primary identifier is email address, used as the dedupe key during import. We preserve name, phone, address, and email as standard Mailchimp contact fields. Signpost's custom contact properties migrate to Mailchimp merge fields (FNAME, LNAME, PHONE, and custom fields prefixed with SIGNPOST_ to avoid naming collisions with existing Mailchimp fields). Unsubscribe and bounced status from Signpost imports as a Mailchimp suppression list before active contacts are imported to prevent re-messaging.

Signpost Business records have no direct Mailchimp equivalent because Mailchimp does not maintain a Business or Account object. We offer two migration strategies: (1) tag-based mapping where each Signpost Business name becomes a Mailchimp tag applied to all contacts associated with that business, preserving the relationship for segmentation; or (2) Company merge field mapping where the business name is stored as a custom contact field. The choice depends on whether the customer plans to use Mailchimp's tag-based segmentation for business reporting. We flag any contacts with multiple Business associations for customer review.

Signpost Campaigns (email and SMS) migrate as Mailchimp Campaigns. Campaign name, subject line, content body, and scheduled or sent status transfer. Note that the automated trigger logic managed by Mia (timing rules, behavioral triggers, scoring-based sends) does not migrate as automation rules. We document the campaign scheduling and contact-targeting logic from Signpost for manual reconstruction in Mailchimp Automations. Campaign performance metrics (open rates, click rates) do not migrate; these live in Signpost's reporting layer and cannot be extracted via API.

Signpost's review solicitation history includes request timing, status (pending, responded, positive, flagged), and customer response. Mailchimp has no native review object. We migrate the most recent review request status as a custom contact merge field (SIGNPOST_REVIEW_STATUS) and the response date as SIGNPOST_REVIEW_DATE. Full solicitation history across all time is flattened into the contact's notes field or stored as a custom text area merge field (SIGNPOST_REVIEW_HISTORY) if the customer requires the full record. This is documented during scoping as a custom field configuration decision.

Signpost appointment records include scheduling data, customer association, and status (scheduled, completed, cancelled). Mailchimp does not have a native scheduling object. We migrate appointment data as custom contact merge fields: SIGNPOST_APPT_DATE, SIGNPOST_APPT_STATUS, and SIGNPOST_APPT_TYPE. The customer chooses whether to store only the most recent appointment or a summary of appointment history. Calendar synchronization (two-way) is not part of the migration scope and requires a separate integration setup if the customer wants Mailchimp to reflect changes made in their scheduling tool.

Signpost contact tags and segment assignments migrate as Mailchimp tags. Segment logic (which contacts belong to which segment based on behavioral criteria) does not migrate because Signpost's segmentation often relies on Mia's scoring model, which is proprietary and not exportable. We deliver a written segment inventory with the criteria used for each Signpost segment so the customer's admin can rebuild equivalent Mailchimp segments or static tags post-migration.

Signpost custom fields on contacts and businesses migrate to Mailchimp custom merge fields. We preserve field types where possible (text, number, date, checkbox as yes/no). Multi-select or multi-checkbox properties migrate as pipe-delimited text fields in Mailchimp. Dropdown or picklist properties migrate as text fields unless the customer specifies a matching Mailchimp predefined field. Field naming conventions in Mailchimp use uppercase prefixes; we map SIGNPOST_PROPERTY_NAME to SIGNPOST_PROPERTY_NAME in the destination with a prefix to avoid collisions with Mailchimp's reserved field names.

Signpost's Mia-driven workflow automations are not accessible via API and cannot be migrated. We conduct a scoping session to document every active Mia rule (triggers, conditions, actions, timing delays) and deliver a structured Workflow Audit Form. The customer or their Mailchimp specialist uses this form to manually rebuild equivalent automations in Mailchimp's Automation Builder. This is a limitation of the migration scope, not a technical gap in our process, and is disclosed upfront during scoping.