ESP Migration Data Transfer: What to Move and How to Keep Your Segments Intact

The data transfer step of an ESP migration is where most things go wrong. It is not dramatic — it does not involve crashed platforms or missing emails. It involves subtle problems that only surface weeks later: segments that are missing half their members because a custom property did not transfer cleanly, a suppression list that was not fully imported, historical engagement data that was lost and is now affecting how your new ESP scores and classifies subscribers.

Getting data transfer right is meticulous, unglamorous work. It is also the foundation that every other part of your migration depends on. If your data does not move correctly, nothing that is built on top of it will work correctly either.

This guide covers every data category you need to export from your old ESP, how to approach the mapping process, and how to verify that your data has transferred accurately before you cut over.

What to Export From Your Old ESP

Not all ESPs allow you to export the same data, and the export format varies significantly between platforms. Before you begin, run a thorough export test in your current ESP to understand what is actually available and in what format.

Contact Data and Custom Properties

Your contact export should include the email address and every custom property you have stored — first name, last name, phone number, birthday, custom tags, any behavioural properties your ESP tracks natively, and any custom properties you have created.

The most common problem at this step is discovering that your custom properties are stored in formats that do not transfer cleanly. Date fields, boolean values, and multi-value properties (tags, lists) often require conversion before they can be imported into a new ESP.

Produce a complete property inventory from your old ESP — a list of every property name, its data type, and an example value. This becomes your field mapping document, and you will use it to match every old property to its equivalent in the new ESP.

Every contact record should carry a clear subscription status: subscribed, unsubscribed, suppressed, or pending (in the case of double opt-in contacts who have not yet confirmed). This status data must transfer accurately.

If your old ESP tracks consent separately from subscription status — storing the date and method of consent capture — export this data as well. Under GDPR, you may need to demonstrate that you have valid consent for each contact, and this documentation is your evidence.

Do not assume that “subscribed” contacts in your old ESP are cleanly subscribed in the way your new ESP defines it. Review the status categories in both platforms and map them explicitly before import.

Historical Engagement Data

Historical engagement data — open history, click history, last engagement date — is not always exportable in a clean format from all ESPs. Where it is available, export it and bring it into your new platform even if the new ESP will not use it immediately.

Historical engagement data serves two purposes in your new ESP. First, it enables you to build initial engagement-based segments before you have sent a single campaign from the new platform (critical for warm-up targeting). Second, it provides context for any predictive models or engagement scoring your new ESP uses.

Purchase and Event Data

If your old ESP stores purchase events (order placed, product viewed, cart added), export this data alongside your contact records. In ESPs like Klaviyo that use purchase history to power flows, predictive analytics, and segmentation, losing this data means your automations will not have the context they need to trigger correctly for existing customers.

For Shopify + Klaviyo migrations, this data is typically re-synced directly from Shopify rather than being migrated from the old ESP — Klaviyo pulls historical order data directly when you connect your store. But for custom integrations or platforms without a native sync option, manual data transfer is required.

Migrating Your Suppression List — The Most Critical Step

The suppression list migration is the most important single step in your data transfer process. This list contains every contact who has unsubscribed, marked your emails as spam, or hard bounced — people who must not receive emails from you on the new platform.

What to Include in Your Suppression Import

Your suppression import should include all of the following categories:

Contacts who have unsubscribed via any method (email unsubscribe link, direct request, ESP interface)
Contacts who have filed a spam complaint through their email client
Hard bounce addresses — email addresses that have permanently failed delivery
Manually suppressed contacts (added to suppression by your team for any reason)

All four categories should be imported into your new ESP’s suppression list before you send a single email from the new platform.

Why This Cannot Wait

Some teams plan to import the suppression list “after” the main contact import. This is a critical mistake. If you import your active subscriber list and begin sending before the suppression data is in place, you will inevitably send to contacts who should not receive email. The consequences range from compliance violations to immediate spam complaint spikes that damage your new sender reputation at the worst possible time — when you are trying to establish it.

Import the suppression list first, before any other data, and confirm it is active and being applied before proceeding.

Mapping Old Custom Fields to New ESP Data Structure

The field mapping process is where migrations slow down most. It requires careful decision-making about how your current data architecture translates to your new platform’s structure.

Build a Field Mapping Spreadsheet

Create a spreadsheet with four columns: old field name, old field data type, new field name, new field data type. Work through every custom property in your old ESP and make an explicit decision for each one.

Some properties will map one-to-one with no transformation needed. Others will require data transformation — for example, a date stored as a text string in the old ESP may need to be converted to a date format that the new ESP can parse correctly.

Some properties may not have an equivalent in the new ESP and will need new custom fields to be created before import.

Some properties may be redundant — present in your old ESP but not used by any flow, segment, or campaign in active use. These can be left behind unless there is a specific reason to bring them forward.

Handle Multi-Value Properties Carefully

Tags, categories, and other multi-value properties (where a single contact can have multiple values assigned) are handled differently across ESPs. In some platforms, a tag like “loyalty:gold” is a flat string. In others, it is a structured property with a defined schema. Export format matters here — multi-value properties exported as comma-delimited strings in a CSV may not import cleanly into a platform that expects them in a different format.

Test your multi-value property import with a small sample batch before running the full import.

Preserving Segments — Rebuild vs. Import

You have two options for bringing your segments across to the new ESP: rebuilding them with native segment logic in the new platform, or importing a static list of the segment members as a tag or property.

When to Rebuild

Dynamic segments — those defined by rules that update automatically as contacts meet or leave the criteria — should always be rebuilt using native logic in the new ESP. A segment like “purchased in the last 90 days” should be defined as a rule in your new ESP, not imported as a frozen snapshot of who was in that segment on migration day.

Rebuilding segments in the new ESP also gives you the opportunity to improve the logic. Many segments that were built to work around limitations in your old ESP can be rebuilt more cleanly in a more capable platform.

When to Import as Tags

Static or historical segments — groups of contacts that represent a snapshot rather than an ongoing condition — can be imported as a custom property or tag. For example, “customers who purchased during our 2024 Black Friday promotion” is a historical group that will not change. Importing these as a tag in your new ESP preserves the information without requiring you to recreate the conditions that defined the segment.

Testing Data Integrity After Migration

Once your data has been imported, do not assume it is correct — verify it.

Spot-Check Key Contacts

Pull a sample of 20-30 contacts from your old ESP export and look them up individually in your new ESP. Confirm that all custom property values transferred accurately, that subscription status is correct, and that any tags or segment membership is in place.

Check Total Record Counts

Compare the total number of subscribed contacts, suppressed contacts, and total profiles between your old ESP export and your new ESP import. Significant discrepancies suggest that some records were not imported correctly or that deduplication logic has merged records it should not have.

Validate Key Segments

For your five to ten most important segments (the ones used by your highest-revenue flows), check that the member count in the new ESP is in the expected range compared to your old ESP. A segment that had 8,000 members in your old ESP and shows 2,000 in the new one indicates a data transfer or segment rebuild problem that needs to be resolved before cutover.

Data transfer is the step where experienced hands make the biggest difference. Excelohunt has managed data migrations across multiple ESPs and knows exactly where the problems hide — from suppression list gaps to custom field format mismatches to segment logic that does not translate cleanly between platforms.

Looking to implement these strategies with expert support?

ESP Migration — learn how we implement this for clients
List Management — learn how we implement this for clients Book a free strategy call with Excelohunt →

ESP Migration Data Transfer: What to Move and How to Keep Your Segments Intact