Migrate from FotoNotes to Mailchimp

FotoNotes customers with a valid email address migrate directly to Mailchimp contacts using the EMAIL field. During the pre‑migration audit we validate each email for format and deliverability, flagging any that are malformed or bounce‑prone. Customers without an email are excluded and reported in a separate CSV, because Mailchimp requires a unique email for every audience member. Duplicate emails across properties are noted for conflict‑resolution before the bulk import commits.

FotoNotes property or container records — including address, property type, unit number, and other location details — map to Mailchimp address merge fields for street, city, state, and ZIP, while property type and unit are stored as custom text merge fields. The property name, which has no direct Mailchimp equivalent, is placed in a separate custom text merge field. This structure preserves the relationship between contacts and properties within Mailchimp’s field model.

Work order status, category, and latest inspection date merge from FotoNotes into Mailchimp text merge fields. Work order category and current status also generate Mailchimp tags — properties with open work orders get tagged by category for segmentation without needing custom fields.

FotoNotes role assignments such as Owner, Tenant, Vendor, Contractor, Field User, and Customer map directly to Mailchimp tags, with each role generating a distinct tag on the contact. When a contact holds multiple roles, each role produces a separate tag, enabling multi‑dimensional segmentation. The complete tag taxonomy—including naming conventions and hierarchy— is defined in the migration plan and reviewed before any data is imported.

FotoNotes work‑order notes and comments have no native equivalent in Mailchimp; they can be stored as a custom text merge field on the contact record, but Mailchimp does not display them in its standard contact view. These notes are migrated as reference information only, allowing you to view the comments in exported files or retrieve them via API if needed. They do not affect segmentation, tags, or campaign targeting.

FotoNotes inspection templates and custom form definitions have no direct Mailchimp counterpart, so they cannot be imported automatically. We export a template inventory that lists every FotoNotes form, its field structure, and any conditional logic, giving your team a blueprint to rebuild those forms as Mailchimp signup forms or preference‑center pages. The inventory includes screenshots and field‑type mappings to speed up recreation, ensuring data‑capture workflows are preserved in Mailchimp.

FotoNotes batch reports and bulk PDF exports contain property inspection data, photos, and completion status for each work order or container. Because Mailchimp does not store reports, these files are exported as a ZIP archive organized by property and work‑order ID. The deliverable includes a manifest linking each PDF to its Mailchimp contact and merge fields, so your team can host the files or attach them to campaigns.

Inspection photos attached to work orders and containers cannot be migrated to Mailchimp contacts because Mailchimp only accepts images as inline email attachments, not as contact assets. We export all photos as a ZIP archive organized by property and work‑order ID, with a manifest linking each image to the relevant Mailchimp contact. Your team can host the images on a CDN and reference them in Mailchimp campaigns.

FotoNotes portal users and admins are internal system accounts, not customer contacts, so they are excluded from the contact migration to Mailchimp. If your team requires access to Mailchimp for campaign management, user accounts must be created separately in Mailchimp’s user management settings, independent of the migrated audience. The migration scope focuses solely on customer records, leaving administrative and field‑user credentials to be handled outside the migration process.