Migrate from Customer.io to Dittofeed: what the move involves
Whether the trigger is a renewal, a pricing change, a data residency requirement or lock-in, the move from Customer.io to Dittofeed is a rebuild of the data flow, segments, journeys and templates, not a file transfer. A CSV export of people and attributes is only one input. Event tracking has to be repointed so that Dittofeed receives user data through Segment, reverse ETL or the Dittofeed API, and every segment, journey and template has to be recreated and checked against what the old account was actually doing. Dittofeed is MIT licensed and runs in your own infrastructure, which is why the work is best treated as an engineering project with a marketing sign-off, not a configuration task.
Platform or infrastructure engineering usually owns the deployment, database, secrets, backups and the event pipeline. Engineering owns the data mapping and the Dittofeed API calls. Marketing operations owns the journey logic, templates and the acceptance criteria, and whoever manages the email provider owns sending domains, SendGrid or Amazon SES configuration and suppression handling. The main risks are silent gaps in event data, duplicate or missed sends during cutover, and consent or suppression status that does not carry over cleanly. Ask for an inventory of every active journey, trigger event and broadcast before you agree on scope, and confirm with the Dittofeed project which features your target version supports, since its recent GitHub releases are still pre-release tags.
DeployOpen plans, implements and hardens a self-hosted Dittofeed deployment in your cloud account, data center or private network, under a written, fixed scope. DeployOpen prepares the controls and evidence that a compliance assessment may need, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Plan for both systems to run in parallel until message content, timing and recipient counts match on the same test population, and agree that acceptance criteria in writing before the Customer.io account is shut down.
Which Customer.io capabilities map to Dittofeed, and what needs rework
This table maps each Customer.io capability to its nearest Dittofeed equivalent and marks it as clean, needs rework or gap. Read each row against the features you actually use, and confirm any channel or feature you depend on in your own environment before you commit to a cutover date. The main takeaway is that people, segments and core messaging move with modest rework, while reporting history and some journey logic need planning.
| Capability | Dittofeed equivalent | Status |
|---|---|---|
| People and attributes | User records fed from Segment, reverse ETL or the Dittofeed API, loaded from your CSV export | Needs rework |
| Segments | User segments built with multiple operators; rebuild each Customer.io segment and check membership counts | Needs rework |
| Event-driven journeys | Automated user journeys triggered by events; rebuild each campaign as a journey and retest the trigger logic | Needs rework |
| Email delivery | Email through an integrated provider such as SendGrid or Amazon SES, not sent by Dittofeed itself | Clean |
| Mobile push | Mobile push notifications are supported; confirm the providers and device setup you need | Needs rework |
| SMS | SMS is supported; confirm the provider, sender registration and country coverage you require | Needs rework |
| In-app messages | Confirm in your environment whether in-app messaging matches your current use before planning | Gap |
| Templates | HTML or MJML templates, or the low-code editor; email templates can be kept in git | Needs rework |
| Reporting and delivery history | Confirm which delivery and engagement history can be carried over; plan to archive Customer.io reports separately | Gap |
Which data moves by export, which needs event re-collection
Customer.io gives you people and attributes as CSV, plus segment membership, but journeys, templates and event history do not come with that export. The cards below separate what you can carry over from what must be rebuilt, re-collected through a live event path or archived before the account closes.
People and attributes CSV
The people and attributes export is the base of the move. Export each segment you need as CSV, then check that identifiers such as the customer ID and email address are present in every file and map cleanly to fields in Dittofeed. Confirm the export covers all profiles you intend to keep, since a filter on one segment will leave others out. Keep a dated copy of each file in your own storage so you can re-import if a mapping goes wrong.
Segment membership exports
Segment membership tells you who was in each audience at export time, but it is a snapshot, not a rule. Dittofeed rebuilds segments from user traits using its own operators, so export the membership lists as a cross-check and recreate each condition by hand. Record the segment logic in your migration notes, because the membership file alone will not reproduce how a segment updates as profiles change.
Journeys, templates and history
Journeys, email templates and historical message logs do not come out of Customer.io in the people export. Journeys must be redesigned as Dittofeed user journeys, and templates should be re-created in HTML, MJML or the low-code editor, ideally kept in git. Export or screenshot the Customer.io templates and a log of past sends for your records, because sent history may be needed for complaint handling, legal holds or audit evidence.
Event path through Segment, reverse ETL or API
Historical events do not move in the people export, so new events must reach Dittofeed from the point you cut over. Dittofeed takes user data from Segment, reverse ETL or its own API. Choose one path before cutover, point your application tracking at it, and confirm that identify and track calls arrive with the same user identifiers that appear in your imported profiles. Test a sample of events end to end before you switch production traffic.
SendGrid or Amazon SES connection
Dittofeed does not send email itself. It connects to an email service provider such as SendGrid or Amazon SES, so you need an account, verified sending domain and credentials with that provider before messages can leave. Confirm that your sending domain, DKIM and bounce and complaint handling are configured for the new sender, and check whether existing suppression lists can be imported so unsubscribed people are not mailed again.
Clear sensitive fields before sharing
Before any CSV leaves your control, including an export shared with a consultant or a test environment, remove or hash fields you do not need for messaging, such as payment data, health details or government identifiers. Keep the migration file set in a restricted location with an access log. Ask your compliance lead whether the export itself is a processing activity that needs recording, and whether sensitive fields should stay in the source system.
How the migration runs from inventory to decommission
This sequence moves Customer.io programs to Dittofeed without a switch-over day. Each stage produces a written artifact, so the team can see what has been moved, what matches and what is safe to turn off.
Inventory segments, journeys, templates and events
Someone who owns the messaging program lists every segment, journey, broadcast, template and tracked event in the Customer.io workspace, with its channel, trigger and the attributes it reads. Engineers confirm which events come from the product and which come from integrations, since those sources decide how Dittofeed will receive data. The output is an inventory and mapping document that pairs each Customer.io object with a Dittofeed equivalent or a note that it must be rebuilt. The step is done when every active program has an owner and a target.
Export people, attributes and segment membership
Export people and attributes as CSV, filtered by segment where needed, and capture segment membership exports as a separate record. Remove or hash sensitive fields that the new system does not need, and store the files in an access-controlled location. Confirm with Customer.io which journeys, templates and relationships are excluded from the export, since those must be rebuilt by hand. The output is a dated export set and a list of the fields carried over, which the team checks against the inventory.
Repoint event tracking to Dittofeed
Engineers route events to Dittofeed through Segment, reverse ETL or the Dittofeed API, depending on what already feeds Customer.io. Connect the email provider, such as SendGrid or Amazon SES, because Dittofeed hands sending to it. Send test events from staging and confirm that user records and attributes appear with the same names the segments expect. The output is a data flow diagram and a test log showing each event type arriving correctly.
Rebuild segments and templates in Dittofeed
The messaging owner rebuilds each segment with the operators used in the inventory, then recreates templates in HTML, MJML or the low-code editor. Where the team wants version control, templates and campaigns can be kept in git and checked with the testing SDK in CI. The output is a segment and template register with a reviewer sign-off for each item, and any gap between the two systems is recorded as an open decision.
Pilot one journey end to end
Choose one low-risk journey, ideally one with a single channel and a clear success metric, and run it in Dittofeed for a limited audience. Compare send counts, timing, personalization and suppression rules with the Customer.io version of the same journey. The output is a pilot report listing each difference, its cause and its fix, and a clear go or no-go decision from the owner before any other journey moves.
Run both systems in parallel until messages match
Keep the Customer.io journeys live while Dittofeed runs the same programs for a set audience, and compare what each system sends, when, to whom and with which content. Investigate every mismatch in event data, suppression lists, unsubscribe handling and provider logs before changing anything. Run the comparison for as long as it takes to produce a stable match rate that the owner accepts in writing. The output is a parallel run log and a sign-off that each program produces equivalent messages.
Cut over channel by channel
Move one channel at a time, such as email first, then push, SMS or in-app, pausing Customer.io sends for that channel only after the parallel run is signed off. Keep the rollback path open by retaining the Customer.io program in a paused state until the next check passes. Confirm that consent records and opt-outs were carried across for every channel moved. The output is a cutover checklist per channel with the date, the owner and the rollback steps recorded.
Decommission Customer.io with archived exports
After all channels run in Dittofeed and the retention period agreed with your compliance team has passed, deactivate Customer.io programs and remove its event sources. Archive the final exports, the inventory, the parallel run logs and the sign-off records in your own storage. Ask your auditors or privacy team which records they need to keep and for how long. The output is a decommission record that lists what was turned off, what was archived and where each archive is held.
How event tracking is repointed without losing triggers
Dittofeed cannot start a journey from an event it never receives, so the first decision is which event source will feed it. Every event that currently triggers a Customer.io campaign or broadcast must also reach Dittofeed, either through a Segment connection or by calling the Dittofeed API from the application or from the data pipeline that already emits events. Inventory each trigger event name, its properties and the code path that fires it, because a journey built on a missing or renamed event will simply never enter. Confirm in the Dittofeed repository's documentation which event ingestion route your deployment supports and which version of the API you will call, since the project is still publishing pre-release tags.
During the parallel run, both platforms will need the same events, so the application or Segment configuration should fan out to Customer.io and Dittofeed at once rather than migrating event by event. The hardest part is identity. Customer.io identifies people by its own IDs, and those values must be carried into Dittofeed as the user identifier so that a person keeps one record across both systems, and so that the people exported from Customer.io in the earlier step can be matched to the events arriving in Dittofeed. Test this with a small set of known test accounts, and check that duplicate profiles are not created when an identifier is sent in a different case or format. Ask your team to document the mapping in a single table that both the import and the event code reference.
Templates and campaign logic should live under version control from the start. Dittofeed supports branch-based git workflows for campaign version control and keeps email templates in git, which lets you review a changed message in a pull request, compare it with the Customer.io version and roll it back if a send goes wrong. Its testing SDK can run campaign checks in continuous integration, so you can assert that a welcome journey fires on the expected event before it reaches a live audience. Assign one owner for the template repository and agree a rule for who may merge to the branch that sends production messages, because a Git history only protects you if changes actually pass through it.
What drives migration cost and duration
This table breaks migration cost into its components, marks which ones are paid once and which recur, and names the drivers that raise or lower each. Use it to shape a written scope and to ask every bidder for the same line items before you compare quotes.
| Cost component | Who is paid or who spends time | One-time or recurring | What drives it |
|---|---|---|---|
| Internal staff time | Your engineers, marketers and data owners for export, event mapping and sign-off | One-time during migration | Number of journeys, custom event types and how many people approve templates |
| DeployOpen fixed-scope implementation | DeployOpen, if engaged, under a written scope and deliverables | One-time | Journey count, event sources, channels in use and the number of provider changes agreed in scope |
| Dittofeed hosting and databases | Your cloud account or data center bills for compute and the database Dittofeed uses | Recurring | Profile and event volume, environment count (staging and production) and backup retention |
| Email and SMS provider fees | Your SendGrid, Amazon SES or SMS provider, paid directly by you | Recurring | Message volume, SMS destinations and whether you keep your current sending provider or switch |
| Engineers who run Dittofeed | Your platform or DevOps team for upgrades, monitoring and incident response | Recurring | Upgrade cadence, alpha-stage release risk and whether you hold a support retainer |
| Testing and parallel running | Your QA staff and any testing support, while both platforms send | One-time | Number of message templates, channels and segment logic that must match Customer.io output |
| Data export and clean-up | Your team, to pull people and attributes as CSV and remove sensitive fields | One-time | Profile count, attribute count and how much history you need to keep versus rebuild |
Questions buyers ask before moving from Customer.io to Dittofeed
How much effort and cost does moving from Customer.io to Dittofeed involve?
The effort depends on how many people, attributes, segments, journeys and templates you carry over, and on how many channels and email providers are involved. Dittofeed's license is free under the MIT license, so the cost is in the components around it: the servers and database that run it, your email and SMS provider fees, the migration work, and the engineers who keep it running. Migration work is largely one-time, while hosting, provider fees and maintenance recur. Ask any partner for a written quote that lists each component separately, including who performs each task and what is excluded. For a fixed-scope engagement, DeployOpen agrees scope, deliverables and timelines in writing before work starts.
How long does a Customer.io to Dittofeed migration take?
No supplied source gives a duration for this migration, so the timeline depends on your scope. The main drivers are the volume of people and attributes to export, how many segments and journeys must be rebuilt, the number of channels in use, the complexity of your event tracking, and how long you run both systems in parallel until messages match. Teams often underestimate the parallel-run period, which is where most of the verification happens. Ask for a timeline tied to specific deliverables, and confirm which of your own teams must approve each stage.
What does the migration need from our internal team?
Expect to provide people who know your data and your messaging rules. Typically that includes an engineer who owns event tracking and can repoint it through Segment, reverse ETL or the Dittofeed API, someone who understands your segment logic and journeys, and a marketing owner who can confirm that messages match what customers expect. Your security or privacy lead should also review which fields leave Customer.io and where they land. Confirm access to your email provider accounts, DNS for sending domains, and your cloud environment before the work begins.
Can an internal team migrate to Dittofeed without outside help?
Yes, an internal team can do it, provided it has engineering capacity for deployment, data export and event tracking, and marketing capacity to rebuild and verify journeys. Dittofeed is MIT licensed and its source is public, so there is no license barrier. The questions to answer honestly are whether anyone on the team has run this kind of stack in production, who handles upgrades and backups afterward, and who is on call when a journey misfires. Many teams split the work: they keep event tracking and data ownership in-house, and bring in a partner for deployment, hardening or the parallel-run checks.
Does Dittofeed's alpha-stage release status affect support?
Yes, it is a factor you should weigh before committing. The Dittofeed GitHub releases page lists pre-release tags, with v0.24.0-alpha.21 published on October 4, 2026, so the project is not yet at a stable release line. Plan for upgrades to change behavior, test each upgrade in a staging environment, and pin the version you deploy. Ask any implementation partner how it handles upgrades, rollback, backups and vulnerability response for pre-release builds, and whether those are covered by a retainer. DeployOpen offers ongoing support, upgrades and continuous testing as retainers.
Do templates, journeys and message history transfer from Customer.io?
Not automatically. The Customer.io data you can export is people and attributes as CSV, filtered by segment, plus segment membership exports. Journeys, templates and campaign configuration must be rebuilt in Dittofeed. Dittofeed supports templates in HTML or MJML and a low-code editor, and it can keep email templates in git, so rebuilt templates can be version controlled from the start. Message history stays with Customer.io and your email provider, so keep those records for audit and suppression purposes. Confirm the exact export options in Customer.io before you plan the scope.
How does DeployOpen scope a fixed-scope migration engagement?
DeployOpen scopes the engagement from a written inventory of your environment: the people and attribute data to move, segments and journeys to rebuild, channels and email or SMS providers to connect, event sources to repoint, and the security and hosting requirements. Scope, deliverables and timelines are agreed in writing before work starts. DeployOpen plans, implements, integrates, hardens, backs up and documents the Dittofeed deployment inside your own infrastructure, and prepares it for parallel-run verification. It does not publish a price list, so a quote follows from that written scope. Ask for the scope document to list what is excluded, such as template redesign or third-party provider configuration.
What usually goes wrong and how to prevent it
Most failed moves from Customer.io to Dittofeed come from gaps between the two systems rather than from the software itself. The cards below cover the points where data, events and sends can drift, and each one names a check to run before cutover.
Missed event triggers after repointing
Journeys in Dittofeed only start when the events they listen for arrive. If the Segment source, reverse ETL job or API calls are repointed but one event name or property differs from what Customer.io received, a journey can sit idle without any error. Before cutover, compare event counts per name for the same day in both systems and confirm that each journey entry event fires in Dittofeed.
Duplicate or suppressed sends during parallel runs
Running both platforms until messages match means two systems can message the same person. Without a shared suppression list, a contact may get the same welcome or reminder twice, or receive a message that Customer.io had already suppressed for an unsubscribe or bounce. Export suppression state first, load it into Dittofeed, and keep sends in one platform per journey during the overlap window.
Unmapped attributes and wrong types
A Customer.io CSV export carries people and attributes, but field names and data types rarely line up one to one. A date stored as text, a plan name renamed in one system, or a boolean written as a string can break segment conditions silently, so contacts fall into the wrong group. Build a field mapping sheet, convert types before import, and check a sample of segment counts against the Customer.io numbers.
Provider limits and domain reputation after switching
Dittofeed hands sending to SendGrid or Amazon SES, so the sending account, verified domains and rate limits belong to you. A new sending IP, a domain without warmed history, or a sudden jump in volume can trigger throttling or spam filtering. Confirm domain authentication records, ask your provider about account sending quotas, and ramp volume gradually while watching bounce and complaint rates.
Lost journey and template history
A people and attributes export does not include journeys, templates or the history of who was in which step. Teams often discover this after cutover, when they need to explain a past message or rebuild a flow from memory. Document every active journey and template from Customer.io before shutdown, store the template HTML or MJML in git, and keep a read-only record of the original configuration.
Pre-release versions in production
Dittofeed's recent GitHub releases are pre-release tags, and v0.24.0-alpha.21 was published on October 4, 2026. Running an alpha build in front of customers without a tested upgrade path can expose you to breaking changes and fixes you did not plan for. Pin a specific version, test upgrades in a staging environment, back up the database before each change, and ask whether a stable release is planned before committing.
How the move differs by team size and starting point
A small team with a handful of journeys and Segment already sending events usually has the simplest path. The main work is repointing the existing Segment destination so user data reaches Dittofeed, then rebuilding a small number of segments and journeys by hand. Because the volume of people and templates is limited, a manual rebuild is often easier to verify than a large import script, and the team can review each journey against its Customer.io original.
- Scope: Limit the first pass to the journeys that send revenue or account-critical messages, and retire the rest after review.
- Event path: Add Dittofeed as a second Segment destination so events flow to both tools during testing.
- Parallel run: Keep both systems live for a period set by your own message cadence, long enough to cover your slowest journey.
- Cutover: Switch one journey at a time, starting with low-risk onboarding messages.
- Provider setup: Connect SendGrid or Amazon SES once and reuse the sending domain for every journey.
Before cutover, confirm with your engineers that Segment's destination configuration can be added and removed without affecting Customer.io.
A team with many journeys and custom event schemas faces a larger inventory problem. Each journey depends on specific event names, properties and attribute calculations, and some of these may exist only in Customer.io's configuration. The migration starts with an inventory that maps every journey to its triggering events, segments and templates, then sequences the rebuild so the highest-volume flows are verified first.
- Inventory: Export and document every event name, property and segment before writing any Dittofeed configuration.
- Schema decisions: Decide whether custom events are sent through Segment, reverse ETL or the Dittofeed API, and keep one path per event type.
- Templates in git: Move templates into version control so changes are reviewed and tested before they reach users.
- Parallel run: Compare message counts and delivery outcomes per journey, and extend the run for flows with long delays.
- Cutover: Move journeys in groups by owner or business line, with a rollback plan for each group.
Confirm which of your events and attributes Dittofeed can receive without custom code, since some schemas may need adjustment on either side.
A regulated team has data handling constraints that often shape the plan more than the feature list does. Dittofeed is designed to run inside the operator's own VPC, which keeps personal data in the infrastructure you control, but the email and SMS providers you connect still process message data. The migration therefore needs an early review of where each provider processes data, how the export from Customer.io is handled and who approves the data flows.
- Data flows: Map each step where personal data moves, including the CSV export, Segment, the Dittofeed API and the sending provider.
- Export handling: Limit exported fields to what the journeys need and store the files in approved locations only.
- Provider review: Confirm with SendGrid or Amazon SES where message data is processed and retained for your region.
- Parallel run: Run longer and document message comparisons as evidence for internal change control.
- Cutover: Plan a change window agreed with the data protection and security owners, not only the marketing team.
Check the regional position of Customer.io's EU option and your provider choices with your own legal and compliance advisers before you commit to a timeline.
How DeployOpen scopes, runs and supports the migration
DeployOpen plans and runs the move from Customer.io to a Dittofeed instance inside your own cloud account or data center. We start with a written scope that names the people, events, segments, journeys and sending providers in play, then build and test in parallel with your current messaging so nothing reaches customers untested.
How we scope
- Inventory every Customer.io segment, campaign, journey and template that must move, and mark which ones will be rebuilt rather than copied.
- Agree in writing which event sources feed Dittofeed, whether through Segment, reverse ETL or the Dittofeed API.
- Confirm the email provider (SendGrid or Amazon SES), SMS and push channels, and the hosting target before work starts.
How we build
- Deploy Dittofeed in your infrastructure, with Docker Compose or Helm, and connect it to your chosen sending provider.
- Export people and attributes from Customer.io as CSV, load them through a repeatable import, and check record counts against the source.
- Rebuild segments and journeys as code-reviewed templates in git, with tests run in CI through the Dittofeed testing SDK.
How we hand over
- Run both platforms in parallel and compare the messages each sends to the same recipients until outputs match.
- Document the event mapping, segment logic, template structure, provider settings and cutover steps in a runbook your team can keep.
- Walk your engineers and marketing operators through the handover, then decommission Customer.io access only after your sign-off.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after cutover, sized to your written scope.
- Dittofeed publishes pre-release tags, so ask us to agree in writing how version pinning, upgrade testing and rollback will work.
- Confirm with your team which backup, access control and data retention policies apply to the Dittofeed database and export files.
