What you can take out of Customer.io today
Customer.io lets you export people and their attributes as CSV, filtered by segment, and you can also export segment membership and the relationships between records. Journeys, campaign logic, message templates and the sending configuration do not come with that export, so they must be rebuilt or recreated in whatever platform you move to. If your renewal, pricing change, residency rule or plan to leave is pushing you toward a move, start by writing down which of these assets you actually need, because the people data is the part that transfers cleanly.
The export is a data handover, not a copy of the working account. It gives you a file of customer records at a point in time, and it does not reproduce the logic that acted on those records, the history of messages sent, or the triggers that feed events into the account. Before you plan a migration, confirm the current export limits, file formats, row caps and the process for requesting large exports in Customer.io's own documentation, since these can change and your timeline depends on them. Ask your Customer.io account contact whether any export is restricted by plan or role.
Treat the file as sensitive personal data from the moment it is generated. Decide which attributes the destination platform needs, remove or hash fields such as payment references, health-related attributes or free-text notes that you have no lawful purpose to carry over, and record who had access to the export and where it was stored. Some sensitive fields may also appear in segment definitions or attribute names, so review those before sharing the file with an implementation partner or an internal team.
Which Customer.io data exports, by method and format
This table lists each data type you can take out of Customer.io, the export method for it, the file format and what to confirm before you plan a migration. Read it as a checklist: every row needs a matching export, and any row without a confirmed method is a gap you must close before cutover.
| Data type | Export method | Format | What to confirm with Customer.io |
|---|---|---|---|
| People with attributes | CSV export from the People area of the Customer.io workspace | CSV | Confirm the maximum number of profiles per export, whether all attributes are included, and how nested or custom attributes are flattened into columns |
| People filtered by a segment | CSV export of people limited to one segment, run from the segment view | CSV | Confirm that the export reflects the segment's membership at the time you run it, and check whether filters on events are carried into the file |
| Segment membership | Segment membership export from each segment's details, with one row per profile in the segment | CSV | Confirm whether the file lists profile identifiers only or also includes attributes, and whether you need one file per segment |
| Relationships (objects linked to people) | Export path documented for relationships data, if available on your plan or workspace | CSV | Ask whether relationship data exports as a separate file, how it links to person identifiers, and whether it is included in the same export path as people |
| Journeys and campaigns | Not part of the people, segment or relationship exports described above | Not applicable | Plan to recreate journeys in Dittofeed from your own documentation, since their logic is not in these files |
| Message templates | Not included in the data exports above | Not applicable | Copy HTML or MJML bodies from your own source before you close the account, and confirm with Customer.io how to retrieve them |
| Sensitive fields | Review the CSV before sharing, removing or hashing fields that should not leave your control | CSV | Confirm which attributes hold personal data, and agree with your DPO or privacy lead which columns to drop before the file moves |
What does not come out with a Customer.io export
A people and attribute export gives you contact records, but not the logic, content and settings that acted on them. The cards below cover what stays behind, why each item matters for the new system, and what to record or rebuild before you cancel. Confirm each item with Customer.io before assuming it can be exported.
Journey logic and branching
A journey is a sequence of waits, conditions, branches and sends, and a people export keeps none of that structure. Each contact row carries attribute values, but nothing records which journey a person entered, which step they reached or which condition routed them. Write down every branch step by step, including delay lengths, entry rules and exit rules, before you cancel the workspace. Ask Customer.io whether journey definitions can be exported in any format, since this export does not include them.
Email and push templates
Templates hold the HTML, copy, layout and personalization variables that subscribers see, and the people export contains only the recipients. Save the source of every email and push template into version-controlled files, and note which attribute references each one uses so they map to fields in the new system. Dittofeed designs templates in HTML or MJML or with a low-code editor and keeps email templates in git, so MJML or HTML source is the most portable target. Confirm with Customer.io which template formats can be downloaded.
Broadcast and campaign settings
One-off broadcasts carry settings that the people export leaves out, including audience definitions, send schedules, sender identities, tracking options and sending limits. A finished broadcast is a record of who received what, not a recipe for resending it. Document each setting for any campaign you still plan to run, and recreate its audience as a segment in the target platform. Test the rebuilt audience against a small group before any live send.
Event history tied to workflows
The people export shows current attribute values, not the event stream that produced them or the workflow runs those events triggered. Without that history, you cannot see which contacts were mid-journey at cutover or why someone entered a segment. Before the final export, record how many contacts are active in each journey and which reporting date range you need, and archive event data in your warehouse if you have one. Event payloads often hold more personal data than the attributes you plan to share, so keep that archive separate from the migration file.
Suppression and consent state
Unsubscribes, bounces and suppression status decide who may receive messages, and their history supports consent records. Whether these flags appear as columns in your export depends on how your workspace stores them, so check a sample file for unsubscribed, bounced and suppressed fields before assuming they came across. Import suppression status as explicit fields, and never re-subscribe a contact who opted out. Ask Customer.io to confirm which unsubscribe and bounce records it can export.
Sources, providers and API keys
Data sources, sending providers, webhooks, API keys and sending domains are configured in the workspace and do not travel with a contact file. List every source that sends events, every destination, each webhook and the DNS records for your sending domain. Dittofeed takes user data from Segment, reverse ETL or its API and integrates with providers such as SendGrid and Amazon SES, so each upstream connection needs a new endpoint and new credentials. Generate new keys in the target system and retire the old ones once traffic has moved.
Clearing sensitive fields before a file leaves your hands
Review the export before it goes to anyone, whether that is a new vendor, a consultant or an internal team that does not need every attribute. A CSV of people and attributes pulled from Customer.io carries every field you have chosen to store on a profile, including fields that were added for one campaign and never cleaned up. Each column you send is a copy of personal data outside the source system, so the export should be treated as a data handling decision rather than a file transfer. Your legal and privacy team defines what counts as sensitive in your organization. DeployOpen prepares the controls and evidence for that review, but it does not issue legal or compliance determinations.
Start by deciding which attributes the new platform needs. In Dittofeed, those are the fields used to build segments, personalize templates and address messages, such as an email address, a first name, a locale or a subscription preference. Compare the attribute list in your Customer.io workspace against the segment conditions and template variables you plan to rebuild, and mark every other column as optional. For fields you must keep but cannot send in clear text, such as government identifiers, health-related attributes or payment data, choose between removing the column and replacing its value with a stable pseudonym generated by a keyed hash, so that records still join without exposing the original value. Free-text notes are the most common surprise. Read a sample of them before export, because support notes often contain details that no one intended to migrate.
Record every decision in a removal log that lists each column dropped or pseudonymized, the rule applied, the approver and the date. Keep row counts from the export and from the target import so the migration can be reconciled, and store the log alongside the export in controlled storage, not in a shared inbox. Confirm with your privacy team how long the unredacted export may exist and who may hold it. If you rely on the export as evidence in a later assessment, ask the auditor or certification body which records they expect, since the format they accept is their decision.
Run a complete export in this order and verify each step
This sequence produces a complete, checked copy of your Customer.io people, segment membership and configuration records, so nothing is lost or silently altered before you move or delete anything.
Freeze scope and the segments to export
Agree in writing which workspaces, segments and date ranges are in scope, and who owns each one. Pause any changes to segments and campaigns that would alter membership during the export window, and record the owner who approved the freeze. Done means you have a short scope list with each segment name, its ID as shown in Customer.io, and the approver's name. Verify by reading the list back to the owner and confirming each segment still exists with the same name and ID.
Record journeys, templates and campaign settings
Before exporting anything, document what the export will not carry: journeys, broadcasts, message templates, sender settings, webhooks and API keys. Capture each item by name, status and last-edited date, and save copies of template HTML and any logic text from a screen or a manual copy. Done means you have an inventory file kept outside Customer.io. Verify by checking that every journey and template listed in the account appears in your inventory, with a count that matches what the interface shows.
Export people and attributes as CSV
Using the people view filtered by the frozen segment, export people and their attributes as CSV, one segment at a time. Store each file under a naming convention that includes the segment ID and export date. Done means each file is saved with a checksum recorded in your log. Verify by comparing the row count in the file (minus the header) with the person count Customer.io shows for the same segment at the time of export.
Export segment membership and relationships
Export segment membership lists and any relationship data, such as links between people and companies or other objects, using the export options your workspace provides. Keep these files separate from the attribute files so that each can be checked on its own. Done means each membership file is saved and logged. Verify by confirming that the membership count matches the segment count from step three, and that relationship IDs in the file resolve to person records in the attribute export.
Check column headers against the attribute list
Open each CSV and compare its header row with the attribute list you captured from Customer.io. Confirm that every attribute appears once, that identifiers such as email and user ID are present, and that no column has been silently truncated or renamed. Done means you have a signed-off mapping document. Verify with a script or spreadsheet check that counts columns per file and flags any header not found in the attribute list.
Scrub sensitive fields from working copies
Make a separate working copy of each export and remove or hash fields that should not leave the controlled environment for sharing, such as payment details, government identifiers, health information and free-text notes. Keep the unredacted original in restricted storage under your retention policy. Done means you have a redacted copy and a log naming each removed field. Verify by searching the redacted files for patterns such as email formats, card-like numbers and known sensitive attribute names, and by having a second person review the field log.
Verify a sample by hand and seal the export
Pick a random sample of records from each file, including people at the edges of the segment, and check each one against its live Customer.io profile for identifiers, attribute values and segment membership. Record the results, fix any mismatch and re-run that segment. Done means the sample passes, the files and checksums are stored together, and the owner has signed the completion record. Verify the seal by recomputing checksums on the stored files and confirming they match the log.
Who on your team owns each part of the export
Marketing operations knows what the account actually contains and what the business still depends on. They can say which segments feed live campaigns, which journeys are running, and which templates are approved for use. Nothing in a CSV export tells an engineer that a segment drives a billing reminder, so this group defines the business meaning of the data before anyone pulls it.
- Segment inventory: List every segment that matters, including ones used only in journeys, and mark which are active, paused or retired.
- Journey and template map: Record which journeys and message templates must be rebuilt in the new platform, since the export does not carry them.
- Sign-off on message content: Approve the template copy, subject lines and legal footers that will be recreated outside Customer.io.
- Cut-over timing: Name the campaigns that cannot be interrupted and the send windows to avoid.
Before the export runs, confirm with marketing operations that the segment list is final, because a segment added later means a second export.
Engineering runs the export, checks the files and handles them after download. The person doing this work should know which Customer.io features are exported as CSV, how the segment filter is applied and where the files will sit while they are in transit. Engineers also decide whether a script validates row counts, column headers and encoding before anyone else opens the file.
- Export execution: Run people and attribute exports filtered by the approved segments, and record the segment name, date and row count for each file.
- Scripted checks: Compare the row count and header row against the segment size shown in the product, and flag empty or truncated files.
- File handling: Move files only to the storage location approved by security, and keep them out of email, chat and personal drives.
- Relationship exports: Capture segment membership and relationship data where the product offers it, so the destination can rebuild groupings.
- Environment access: Confirm which accounts and API keys have export rights and remove temporary access after the job.
Before the export runs, ask engineering to confirm the exact export options available on your Customer.io plan and workspace, since these determine what can be scripted.
Security and privacy owners decide what personal data may leave the platform and under what conditions. They approve the field list, so attributes such as payment details, health information, government identifiers or free-text notes are either removed or excluded before the file is created. They also set where files live, who may open them and when they are deleted.
- Field list approval: Review every attribute in the export and mark each as keep, redact or exclude, with the reason recorded.
- Storage location: Name the approved location, its encryption settings and the access group, and confirm it sits inside your own infrastructure.
- Deletion dates: Set a date by which every copy of the export, including backups and downloads on laptops, must be removed, and assign who verifies deletion.
- Lawful basis review: Confirm that moving contacts to a new processor is covered by your privacy notices and contracts.
- Audit record: Keep a log of who approved the field list, who ran the export and where each copy was stored.
Before the export runs, ask security and privacy to approve the field list in writing, because an export that includes a sensitive attribute cannot be undone once it is shared.
What to plan before the Customer.io contract ends
The export itself is the easy part. The decisions that cause trouble are the ones made before the renewal or termination date: what Customer.io will export, where those files live, which regional rules apply, and how the replacement runs alongside the old account. Work through these questions with Customer.io in writing and have your answers ready before notice is due.
Confirm the export scope in writing
Ask Customer.io to list exactly what it will provide: people and attributes as CSV, segment-filtered exports, segment membership and relationships. Ask separately whether event history, campaign metrics, journeys, templates and message logs are included. Get the answer in writing, because a verbal assurance that "everything" comes out is the most common gap. Record which items are missing so you can rebuild or archive them yourself.
Set a retention plan for exports
Decide how long the exported CSV files stay, who can open them, and where they are stored before the account closes. Exports contain personal data, so treat them like any other regulated dataset, with access limits and a deletion date. Ask Customer.io how long it keeps your data after closure and whether it can delete it on request, and make sure your own retention rule matches that answer.
Map regional and residency obligations
Confirm which region your Customer.io data sits in and whether any law, contract or customer agreement limits where copies can be stored or processed. Ask whether the region can be changed for an existing account. If data must remain in a specific jurisdiction, check that the export destination and the replacement hosting meet the same requirement before you start moving records.
Plan a parallel run
Keep Customer.io sending while the replacement receives the same events and sends test messages, then compare outputs. Ask Customer.io how long the account stays active after you give notice, and whether you can keep sending during that window. Agree the cutover point, the rollback path and the owner who signs off on message parity before the renewal date arrives.
Confirm post-closure account handling
Ask what happens to the account, its data and any integrations once it is closed. Confirm whether access ends immediately, whether there is a read-only period, and how deletion is evidenced. Also ask what happens to the API keys, Segment or other data sources connected to the workspace, so no event stream keeps writing to a closed account.
Name the owners and collect evidence
Assign one person to own the export, one to own the retention and deletion record, and one to sign off on the cutover. Keep a dated log of the export files, checksums, the vendor's written scope and the deletion confirmation. These records support your compliance team and any audit that asks how personal data left the old system.
Questions teams ask before exporting Customer.io data
How much effort does a complete Customer.io export take?
Effort depends less on the export button than on what you need to keep. The CSV export of people and attributes is quick to run, but the work grows with the number of segments you want to preserve, the count of custom attributes, how clean the source data is, and how many sensitive fields must be removed before sharing. Each segment needs its membership and rules documented, each attribute needs a mapping to its destination, and duplicates or malformed records need review. Ask any provider to break the effort into these parts so you can see which ones your team will absorb.
Can an internal team run the Customer.io export without a partner?
Yes, many teams can export the people and attributes themselves, because the export is a supported function of the product and the output is plain CSV. The harder part is deciding what must leave the platform, clearing sensitive fields, and confirming that the files are complete enough to rebuild segments elsewhere. An internal team usually needs one person who knows the data model and one who can review the files for personal data. If neither has time, a fixed-scope engagement can cover the export and documentation while your staff keep control of decisions.
What does the work need from marketing and engineering?
Marketing owns the business meaning of the data: which segments matter, which journeys are live, which templates are still used, and which consent or suppression rules must carry over. Engineering owns the technical side: how events reach Customer.io, which attributes are populated by code, and which fields contain identifiers or sensitive values. Both groups should agree on a list of required outputs before anyone runs an export, because gaps found later usually trace back to an unanswered question from one of these two teams.
How long does an export take, and what sets the timeline?
The timeline is set by the number of records, the number of segments to document, the state of the source data, and the approval path for shared files. This page does not give a duration because none was supplied for Customer.io exports, and the figure depends on your own account. Ask any provider for a schedule tied to named deliverables, with the review steps for sensitive fields written out, so the timeline reflects the work rather than a generic estimate.
What happens to journeys and templates during the export?
A CSV export of people, attributes and segment membership does not carry journeys, campaign logic or message templates. Those must be recreated or rebuilt on the destination platform. Before you start, export or copy the template content you still need and write down each journey's entry rules, branches, delays and exit conditions. Treat this as a separate workstream from the data export, because it requires product knowledge that a data file does not contain. Confirm the current export options with Customer.io directly, since its feature set may change.
How do we clear sensitive fields before sharing an export?
Start with a field inventory that marks each attribute as required, optional or sensitive, then remove or hash sensitive values before any file leaves a secured environment. Review both headers and sample rows, because free-text attributes often hold data nobody meant to store. Keep a log of what was removed and who approved it, which helps with internal privacy reviews. An independent reviewer should check a sample of the output. DeployOpen prepares these controls and evidence for compliance assessments, but it does not issue audit reports or certifications.
What should we ask for in a written quote for this work?
Ask for a fixed scope listing the segments, attributes, and channels covered, and the exact deliverables such as CSV files, a field inventory, a segment rebuild document and a sensitive-field review record. Request the assumptions behind each item, the responsibilities of your team, the acceptance criteria, and any items excluded, including journeys and templates. Also ask which costs are one-time and which recur, such as a retainer for later changes. DeployOpen does not publish a price list, and a quote follows from the written scope.
How DeployOpen scopes and supports a Customer.io data exit
DeployOpen treats a Customer.io data export as a written, fixed-scope piece of work inside your own infrastructure. We agree which people, attributes, segment memberships and relationships leave the account, where they land, and which fields are removed before anything is shared.
How we scope
- Inventory the people, attributes, segments and relationships you need to take out of Customer.io
- Confirm which journeys, templates and campaign history you will rebuild or archive separately
- Agree the sensitive fields to remove or pseudonymize before any file leaves your control
- Record the target storage location and access rules in the written scope before work starts
How we build
- Set up the export runs against your segments, filtered as your scope defines
- Apply field clearing and transformation steps so sensitive attributes never reach shared copies
- Check row counts and sample records against the source to confirm the export is complete
- Store the output in your own environment with access limited to named staff
How we hand over
- Deliver a document listing each export file, its fields, filters and the date it was produced
- Record what did not transfer, such as journeys, templates and delivery history, with the reason
- Provide a short runbook so your team can repeat the export or confirm it later
- Walk through the handover with your data owner and security contact
How we support
- Engagements are fixed-scope, and scope, deliverables and timelines are agreed in writing first
- Ongoing support, upgrades and continuous testing are available as a retainer
- Ask for a quote based on the written scope, since DeployOpen does not publish a price list
- Confirm with Customer.io which export options your plan and account include before scoping
