Simon Data ESP Migration Guide for Shopify Brands

If you’re thinking about migrating to Simon AI (formerly known as Simon Data), there are some key factors to consider. 

Moving your customer data platform (CDP) and email service provider (ESP) involves transferring data models, deliverability infrastructure, integrations, and more. 

In any data migration, there’s inherent revenue risk if the cutover goes wrong. A rough transition can hurt deliverability, create data gaps, and break automations you’ve spent time building. So it pays to be methodical.

This playbook covers the full Simon AI (Simon Data) ESP migration process for Shopify brands, from scoping to post-launch optimization.

What Simon AI (formerly Simon Data) ESP migration means

Migration means different things depending on what you’re moving. Simon AI (formerly Simon Data) operates as both a CDP and an ESP (via Simon Mail), so the scope of your project depends on which capabilities you're adopting and what you're leaving behind.

There are three distinct migration types, and each involves different teams, timelines, and risk profiles:

Some brands will migrate all three simultaneously, while others will phase them in. The first step is defining which migration type you're executing, because the preparation and risk mitigation differ for each.

Note that data-feed migration applies specifically to brands already on Simon AI that are transitioning from the legacy Classic configuration to the newer self-serve Activate system. Simon’s data feed migration documentation covers the technical specifics, including destination setup and field configuration.

A key concept for reporting: Simon AI feeds are attached to each flow execution, and capture customer attributes at the exact moment of send. That means values like customer lifetime value (CLV), last purchase amount, or segment membership are recorded as they existed when the message was dispatched. This is what makes post-send attribution possible. 

However, that setup breaks if field configurations aren't mapped correctly during migration. Teams building warehouse schemas should note the global cap of 50 custom fields. You can add further custom fields at the individual flow level, but those aren't saved globally.

Pre-migration readiness

The best migrations are set up before anything actually moves over. This section covers three parallel workstreams: 

• Inventorying and freezing your current state
• Mapping your data and identity model
• Establishing reporting parity

Inventory and freeze

Start by cataloging every asset in your current ESP. That includes everything your email program depends on, including the upstream and downstream systems connected to it.

Here's what to inventory, and who should be responsible:

Once you've inventoried everything, freeze it. Avoid making major lifecycle changes like new flows or segment restructures during the migration window . Such moves could create a moving target, making testing and validation harder. 

For recurring automations that are mid-sequence for existing subscribers, decide on a path beforehand. Will those subscribers complete their journey on the legacy ESP, or transition to the new platform mid-flow?

Consider data ownership as well.Before migration begins, document your key ownership roles. Specify who owns identity resolution rules, consent and subscription status definitions, UTM conventions, and source-of-truth designations for each data type. Ambiguity around ownership causes delays when you hit edge cases during build.

Be careful in peak times. Don't cut over during your highest-revenue promotional windows. If your brand runs major campaigns around Black Friday, the holidays, or seasonal launches, schedule the migration to complete well before those periods.

Data mapping and identity resolution

If your brand is planning a white-glove migration, it’s easy to underestimate identity complexity. 

Guest checkout creates profiles without accounts. Customers use different email addresses online and in-store. SMS opt-ins may not match email identifiers. Marketplace orders from third-party channels may carry yet another identity.

But this won’t be a blocker if you have a plan. Before configuring anything in Simon, answer four questions:

1. What identifiers will you use? Simon’s Identity module generates a unified simon_id for each profile using deterministic matching. Define which identifiers feed that resolution: email, phone, Shopify customer_id, external IDs from loyalty programs or apps. One technical note for planning: defining identity resolution rulesets in Simon requires SQL. Updating the underlying logic may involve Simon's implementation team rather than self-serve configuration.
2. How will consent and subscription status be represented? Map every consent state from your current ESP to Simon's data model (opted in, opted out, soft bounce, hard bounce, spam complaint, never subscribed). Migrating contacts without their suppression status is a compliance violation and causes major deliverability problems.
3. How will Shopify event data be standardized? Shopify fires events for placed order, refund, fulfillment, viewed product, abandoned checkout, and abandoned cart. Define how each event maps into Simon's event schema. Include field names, data types, and any transformations needed.
4. How will offline and POS data be handled? If you're using Shopify POS, in-store transactions and customer interactions need a path into Simon. Define whether that data flows through Shopify's unified customer profiles, through your data warehouse, or through a direct integration.

Backyard Butchers, a DTC meat brand running both online and pop-up retail, faced a version of this problem. With disconnected systems across channels, customer data was fragmented and hard to act on. After unifying online and offline operations on Shopify POS, they improved their customer satisfaction score by 30% and cut ticket-resolution times by roughly 50%. The foundation was cleaner first-party data, which powered better remarketing automation and cross-channel customer relationships.

That's the kind of foundation a Simon AI migration needs to build on. Without unified, clean customer data flowing into your CDP, your downstream segmentation and personalization won't perform.

Use this data contract template to document every field before build begins:

Reporting parity

Migrations fail when the business can't trust its numbers after cutover. Achieving reporting parity means your new platform produces the same metrics, at the same granularity, from the same underlying logic, as your old one.

What parity covers:

• Campaign-tracking fields (UTM parameters, campaign IDs, variant names)
• Conversion tracking and revenue attribution methodology
• Holdout and control group logic
• Deliverability dashboards (inbox placement proxies, complaint rate, bounce rate)
• Lifecycle funnel reporting (subscriber → engaged → converted → repeat)

Simon's documentation recommends reviewing existing reporting and matching fields during data migration prep. That means screenshotting your current flow-level reports and noting every field name and value, then replicating them in the new data feed configuration before launching any test flows.

Here's a step-by-step parity test to run before go-live:

1. Pick three high-volume flows (welcome series, abandoned cart, and post-purchase are good candidates).
2. Define expected output fields for each flow. State which fields should appear in your data warehouse or analytics destination, what values they should contain, and what the conversion attribution window is.
3. Run a test send in Simon for each flow, using a seed list or internal test segment.
4. Compare the resulting warehouse tables or destination files against equivalent output from your current ESP. Field names, data types, revenue attribution, and timestamp precision should all match.
5. Reconcile any discrepancies before migrating live traffic.

Build plan and cutover strategy

With readiness work complete, the build phase covers three workstreams (templates, automations, integrations) followed by the cutover itself. Structure the build in phases so your team ships value early rather than waiting for a single launch.

Templates and modular content

Start with a template inventory. Every email your brand sends falls into one of three categories:

• Transactional: Order confirmations, shipping notifications, password resets. These are compliance-sensitive and must work from day one.
• Marketing: Campaigns, promotions, product launches. These can migrate in phases.
• Lifecycle: Welcome series, abandoned cart, post-purchase, winback. These generate ongoing revenue and need careful sequencing.

For each template, make a rebuild decision:

Simon Mail uses Jinja-based dynamic content. This gives you direct access to CDP data (CLV, purchase history, behavioral events) inside templates without a separate data sync. With other ESPs, personalization data has to be piped in through integrations or custom feeds.

Health and beauty brand Sculpted By Aimee shows how data capture feeds downstream activation. The brand struggled with inefficient in-store email capture and missing customer data for loyalty and personalization. 

After integrating Shopify POS with customer data capture, Sculpted By Aimee saw a 275% increase in email capture. Omnichannel shoppers now deliver an average lifetime value three to four times higher than online-only customers. Cleaner capture at the point of interaction made downstream email more relevant.

Journey and automation rebuild

A terminology note: Simon Data uses both “Flows” and “Journeys.” Flows are the underlying execution units that sync audiences or send messages on one-time, recurring, or triggered schedules. Journeys are the newer visual orchestration layer that coordinates multiple flows across channels. They coexist, so your migration will involve rebuilding both.

Prioritize automations by revenue contribution and volume. For most Shopify brands, the order is:

1. Welcome series (highest volume, sets the engagement baseline)
2. Abandoned cart and abandoned checkout (direct revenue recovery)
3. Post-purchase (repeat purchase, cross-sell, review collection)
4. Winback (reengaging lapsed customers)

Rebuild the logic core first: trigger events, delay timings, branching conditions, and suppression rules. Get those working and validated before optimizing creative. A welcome series with plain-text emails and correct logic is better than a beautifully designed one that fires at the wrong time or suppresses the wrong people.

Internationally scaling footwear brand Sanjo shows what strong segmentation and automation foundations can do. The brand was dealing with disconnected systems and slow personalization. After migrating to Shopify and building a stronger integration foundation, Sanjo achieved a 60% increase in retention and a 25% increase in conversion. They also saw a 50% reduction in logistics time.

Integrations

A Shopify brand's tech stack doesn’t end at the ESP. Simon AI needs to connect with the systems that feed it data and the systems that consume its outputs.

Common Shopify-connected tools to account for:

• Email/SMS providers: If you’re keeping a separate SMS tool alongside Simon Mail (like Attentive or Postscript), define which platform owns SMS orchestration and how suppression syncs between them.
• Customer service: Gorgias, Zendesk, or similar. Customer service agents need visibility into which messages a customer received and what they clicked.
• Subscriptions: Recharge, Skio, or Bold, for example. Subscription events (renewal, skip, cancel) are high-value triggers for lifecycle flows.
• Reviews and loyalty: Yotpo or LoyaltyLion, for example. The timing of review requests and loyalty point notifications often depends on ESP triggers.

For each integration, define the source of truth. Who owns the data? Shopify, the data warehouse, or the ESP? Getting this wrong creates conflicts. 

If both Shopify and Simon hold customer subscription status but sync on different schedules, you risk conflicting data. A customer who unsubscribes via your preference center might still receive a message if the sync hasn’t caught up.

The data flow pattern for most Shopify brands running Simon looks like this: Shopify feeds commerce events and customer data into a data warehouse or CDP. That data then feeds Simon AI for segmentation and orchestration, which triggers sends via Simon Mail or a connected ESP/SMS provider. Finally, results flow back to the warehouse for analytics.

Cutover models

Choose a cutover model based on your risk tolerance, team bandwidth, and the complexity of your automation program.

Flow-by-flow cutover is the safest default for most Shopify brands. Start with a low-volume, low-revenue flow to validate infrastructure (like a post-purchase review request). Then move to higher-stakes flows once you've confirmed deliverability, tracking, and reporting are working.

Scalero, a Simon Data implementation partner, recommends launching one campaign at a time during migration. Their phased approach includes assessment, data migration, template and automation setup, testing, and post-launch support.

Deliverability and compliance

Deliverability is where ESP migrations can hurt revenue, if you’re not careful. A new sending infrastructure has no established reputation with inbox providers. Without a deliberate warming and authentication strategy, your emails can land in spam, and complaint rates spike. Recovery can take weeks.

What needs to be in place before you send anything

Authentication: Set up SPF, DKIM (2048-bit key recommended), and DMARC for every sending domain before any warm-up sends. Google's bulk sender guidelines require SPF and DKIM for senders dispatching more than 5,000 messages per day, plus a DMARC record on the sending domain. The “From:” domain must align with either the SPF domain or the DKIM domain to pass DMARC.

One-click unsubscribe: RFC 8058 defines the technical standard. Every marketing email must include a List-Unsubscribe-Post header (with the exact value List-Unsubscribe=One-Click). It must also include a List-Unsubscribe header containing an HTTPS URI. The sending server must not return an HTTPS redirect, and the DKIM signature must cover both headers. Google requires this for all bulk senders.

Spam-rate monitoring: Google's target is below 0.10%. The hard limit is 0.30%, at which point Gmail restricts delivery. Monitor via Google Postmaster Tools from day one of warm-up.

IP warming approach

New IPs have no reputation. Sending full-list volume on cold IPs will result in spam-folder placement or outright blocks. Ramp up gradually, targeting engaged subscribers first:

Domain reputation now carries more weight than IP reputation for Gmail and Microsoft. If you're changing sending domains as part of the migration, warm the domain alongside the IPs. If you're keeping the same domain, the warm-up is faster, but you still need to ramp volume gradually on the new infrastructure.

Deliverability do's and don'ts

Do:

• Migrate suppression data (unsubscribes, hard bounces, spam complaints) before sending a single message from the new platform
• Run old and new ESPs in parallel during warm-up, with bidirectional suppression syncing
• Verify authentication records using Google Postmaster Tools and Microsoft SNDS before warm-up
• Monitor complaint rates daily during the first four weeks
• Use seed testing to check inbox placement across major providers

Don't:

• Send to your full list on day one from a new IP
• Skip migrating suppression lists (this creates immediate compliance risk and deliverability damage)
• Change sending domain and IP simultaneously without a warming plan
• Ignore bounce rates during warm-up (hard bounce rates above 2% signal list quality issues)
• Send from the new platform during peak promotional periods before warm-up is complete

Deliverability launch checklist

Use this checklist before sending anything from the new platform:

• SPF record published and validated for all sending domains
• DKIM configured with 2048-bit key; signatures covering List-Unsubscribe headers
• DMARC record published (policy can start at p=none during warm-up, then escalate to p=quarantine and eventually p=reject once authentication is confirmed stable)
• Google Postmaster Tools configured and monitored
• Microsoft SNDS access requested
• Suppression data (unsubscribes, hard bounces, complaints) imported into Simon before any sends
• List hygiene pass completed: remove addresses that haven't engaged in 12+ months from initial warm-up cohorts
• IP warming schedule defined with volume targets per week
• Seed list testing confirmed inbox placement at Gmail, Outlook, Yahoo
• Parallel running plan documented: which flows run on which platform during transition, and how suppression syncs between them

Post-migration optimization (first 30–60 days)

The migration isn’t complete at launch. The first 30–60 days are about confirming everything works and catching issues early. Then it’s time to improve performance.

What to monitor

Track these metrics daily during the first two weeks, then weekly through day 60:

• Inbox placement proxies: Seed test results across Gmail, Outlook, and Yahoo. Any drop below 90% inbox placement warrants investigation.
• Complaint rate: Target below 0.10%. Investigate immediately if it approaches 0.20%.
• Bounce rate: Hard bounces above 2% indicate list-quality issues that need immediate attention.
• Flow-conversion rate: Compare each migrated flow’s conversion rate against its baseline from the legacy ESP. More than a 10% drop signals a logic, timing, or targeting problem.
• Revenue per recipient (RPR): The primary metric. Track by flow and by segment. If RPR drops while open and click rates remain within 5% of baseline, the issue is segmentation or personalization quality. Investigate those areas rather than deliverability.
• Holdout results: If you’re running holdout groups, compare converted vs. holdout cohorts to validate that migrated flows are still driving incremental value.

What to improve first

Once metrics stabilize (give it two to three weeks), start optimizing:

Segmentation refinement

Your initial segments in Simon were translated directly from the legacy ESP. Now that you have CDP-level data access, rebuild segments using richer behavioral and transactional signals. Simon’s no-code audience builder supports real-time and historical conditions, nested segment references, and computed attributes.

Suppression and frequency caps

Over-sending is one of the fastest ways to damage a new sending reputation. Review frequency caps across all active flows and campaigns. A customer might be enrolled in welcome, abandoned cart, and promotional campaigns simultaneously. Make sure the suppression logic prevents message fatigue.

Personalization inputs

With direct access to CDP data in Simon Mail’s Jinja templates, you can add personalization that wasn't possible (or was overly complex) in your previous ESP. Start with high-impact, low-risk additions: product recommendations based on purchase history, dynamic content blocks based on customer segment, or location-based offers.

Apparel brand Nobull shows what scaled personalization and segmentation can deliver. After implementing Shopify Plus with partner tooling to scale personalized automated campaigns, Nobull achieved a 92% lift in conversion, a 30% increase in predicted CLV, and a 46% increase in known repeat buyers. That kind of performance is what a well-executed migration makes possible.

Tella & Stella, a pet supplies brand running both DTC and B2B, saw similar compounding effects. After unifying DTC and B2B on Shopify with lifecycle marketing powered by Klaviyo, the brand achieved a 23% year-over-year sales increase, grew their repeat customer rate to 36% (up 17% YoY), and saw 76% growth in sessions from new territories. Unified commerce data across channels made the email and lifecycle program significantly more effective.

Returns come from what you do with better data and segmentation. Improved orchestration across your tech stack after the switch will make a big difference, too.