Migrate from Rezora to Mailchimp

Mailchimp has no native engagement history — historical open and click rates become static data

Rezora tracks open rates and click rates per campaign and stores those figures on the contact record historically. Mailchimp calculates its own engagement metrics on a go-forward basis using its own tracking pixel and link-rewriting infrastructure. After migration, Mailchimp will not retroactively populate open rates or click rates for emails sent in Rezora. We store Rezora's historical open_rate and click_rate as static number fields on each subscriber — useful as reference data but not connected to Mailchimp's live reporting. Your team should establish new baseline metrics after migration rather than relying on Rezora-era numbers to evaluate campaign performance in Mailchimp.

Merge field names cap at 30 characters — long Rezora property names get truncated

Mailchimp enforces a 30-character maximum on merge field names with a strict character set (letters, numbers, underscores). Rezora custom property names can be longer and may include spaces or hyphens. Before migration, FlitStack audits every Rezora custom property and truncates any name exceeding 30 characters to the first 30, replacing spaces with underscores and stripping disallowed characters. Each rename is documented in the migration plan so your Mailchimp admin knows exactly which Rezora field each merge field originated from. Fields with identical first-30-character names get a numeric suffix (RZR_PROP_001, RZR_PROP_002) to prevent collisions. This is a planning-step gotcha — it surfaces before any data moves.

Rezora's per-agent permission model has no Mailchimp equivalent — teams must choose a structural path

Rezora lets brokerages restrict which agents can access which contacts, templates, and campaigns — this per-agent isolation is a first-class feature of Rezora's permission model. Mailchimp has no equivalent: either all contacts live in one audience (agent identity preserved only as a tag or merge field, visible to everyone with account access), or you use Mailchimp sub-accounts (each agent gets their own Mailchimp account under a parent) but Mailchimp limits you to 5 sub-accounts per parent. Large real-estate teams with 10+ agents cannot replicate Rezora's granular permissions in Mailchimp without a third-party access-control layer. FlitStack surfaces this as a migration-plan decision point — your team chooses the structural path before data mapping begins.

Drip campaigns and nurture sequences do not transfer — must be rebuilt in Mailchimp Customer Journeys

Rezora drip campaigns and multi-step nurture sequences are stored as automation objects with triggers, delays, and content references. Mailchimp's Customer Journeys builder uses a completely different data model — there is no import path for Rezora automation logic. FlitStack exports the full Rezora automation definitions as a structured JSON document that lists each step, its trigger condition, delay, and the email content reference. Your Mailchimp admin uses this as a rebuild specification for Customer Journeys. The rebuild work is billable separately from data migration and depends on sequence complexity — a 5-step drip is a 1–2 hour rebuild; a 20-step multi-branch sequence may take a day.

Rezora HTML templates may break when pasted into Mailchimp due to responsive design differences

Rezora templates built in Rezora's own template designer use platform-specific markup and may include dynamic tokens that only resolve within Rezora's environment (e.g., agent-branded headers, property-specific content swaps). When the HTML is extracted and pasted into Mailchimp's template editor, these tokens become inert text or break the layout. FlitStack copies the template HTML to Mailchimp but marks it for manual review: any Rezora-specific dynamic token gets flagged in the migration plan for replacement with a Mailchimp merge tag or manual rebuild in Mailchimp's drag-and-drop builder. Templates using only standard HTML and CSS (no Rezora tokens) typically import cleanly.