Migrating from Customer.io
If you're hitting Customer.io's pricing wall (Premium starts at $1,000/mo, the per-MAU billing scales unfavorably past 100k subscribers), tired of running A/B tests on workflows by hand, or want a unified bandit running across web + email + push, Apex is built for the move. This guide maps the concepts and walks the migration.
Why teams move
- Adaptive math, not just A/B. Customer.io ships split paths in workflows; you set the variant weights and read the result. Apex's Adaptive Branches Thompson-sample arms continuously, retiring losers automatically.
- Real lift number. Customer.io has no first-class global holdout; lift estimates are DIY through your own reporting. Apex ships a global holdout and a calibrated-impact dashboard per journey.
- Unified experiment engine. Apex's web A/B tests, email experiments, and journey arms share the same Thompson sampler and the same reporting. One mental model, one dashboard.
- AWS-native infrastructure. Email sends through your own SES. Push via your own APNS/FCM. No new vendor exfiltration of customer PII.
Concept mapping
| Customer.io | Apex | Notes |
|---|---|---|
| Workspace | Workspace (projectKey) | Same shape. Apex workspaces nest under an Org for cross-workspace cohorts. |
| Person | End-User (endUserId) | Apex unifies on a stable per-user identity rather than per-channel destinations. |
| Segment | Audience | Audiences are saved predicates over events + attributes + cohort references. The migration tool emits Apex audience predicates. |
| Manual Segment | Cohort | Larger lists land as org-level cohorts referenced from journey audiences. |
| Campaign (manual) | Communication + one-shot Send | Most one-shot Customer.io campaigns map cleanly to a journey with a single Send step. |
| Event-Triggered Campaign | Adaptive Journey | Same shape: trigger on event, run a workflow, exit. The migration tool maps the workflow tree directly. |
| Workflow Step: Email | Send step (channel = email) | Reuses your existing comm template via the comm picker. |
| Workflow Step: Push | Send step (channel = mobile_push) | Same. |
| Workflow Step: SMS | Webhook step → Twilio destination | Apex doesn't ship SMS native; the Webhook step + your Twilio account is the BYO path. |
| Workflow Step: Wait | Wait step (duration mode) | Direct mapping. |
| Workflow Step: Wait Until Event | Wait step (until_event mode) | Wait-for-event uses Step Functions task tokens; survives across deploys. |
| Workflow Step: Branch | Branch step (conditional mode) | Direct mapping. A/B branches map cleanly to adaptive branches if you'd like the optimizer to take over. |
| Workflow Step: A/B Test | Branch step (experiment mode) | Becomes Thompson-sampled. The migration tool flags every A/B step for upgrade review. |
| Webhook Action | Webhook step | Same shape; Apex adds HMAC signing + DNS-rebinding-safe URL validation. |
| Liquid templating | LiquidJS templating | Identical syntax. Most templates port verbatim. |
| Goal Events | Journey-level goalEventName | Set on the journey rather than per-campaign. The calibrated-impact dashboard reads from this. |
What you can leave as-is
- SES — keep your existing AWS account's SES domain identity, IPs, configuration sets. Apex sends through SES under your account.
- APNS / FCM credentials — same. Mobile push doesn't proxy through Apex's account.
- Event tracking — if you're already firing events into Customer.io via their
trackAPI, the migration is a URL swap to/api/events. Same JSON payload shape. - Liquid templates — copy-paste into Apex's comm editor. The few syntax differences (e.g. some Customer.io-specific filters) are flagged at preview time.
Migration steps
1. Export from Customer.io
Pull your workspace data via Customer.io's Track API export endpoint. The migration tool consumes:
- A JSON dump of segments + manual segments
- A JSON dump of campaigns + workflows
- A CSV of person attributes + identifiers
- (Optional) a CSV of recent event history for backfill
2. Provision the Apex workspace
Sign up at apex.inc, create your workspace, install the snippet. The snippet is the same backbone as your tracking layer — you don't need to dual-write events.
3. Translate segments
Open /dashboard/audiences and review the segments the migration tool translated. Each Customer.io segment becomes an Apex audience predicate. Static / manual segments become cohort references.
The tool flags any segment behaviors Apex doesn't fully support yet (these are rare — Apex's predicate language is roughly a superset).
4. Translate campaigns + workflows
Each Customer.io workflow becomes an Adaptive Journey draft in Apex. Walk through each one in /dashboard/communications/journeys/[id]:
- Verify the trigger contract is wired correctly
- Walk the canvas to check step routing
- For A/B-tested workflow branches, decide: keep as conditional (operator-controlled split) or upgrade to adaptive (Thompson takes over)
- For workflows with goal events, set the journey-level
goalEventNamein the toolbar - Dry-run with a test subject to verify
5. Cut over
Recommend dual-running for 1-2 weeks:
- In Customer.io: pause the source workflow (stops new entrants but lets in-flight finish)
- In Apex: publish the equivalent journey
- Wait 1-2 weeks for Customer.io in-flight workflows to drain
- Archive the Customer.io workspace
A/B branch decision matrix
When the migration tool encounters a Customer.io A/B branch, you choose:
| Choose conditional when... | Choose adaptive when... |
|---|---|
| You want the same fixed split forever (e.g. 50/50 forever) | You want continuous re-optimization |
| The split represents a known segmentation decision | You don't actually know which arm is better |
| You're testing to ship a winner once (and then disable the loser) | You want the loser to keep getting samples (cheap insurance) |
For most "test which copy converts better" branches, adaptive is the right answer — Thompson sampling is strictly better than fixed allocation once you have ≥200 subjects per arm.
What's NOT in the migration
- Customer.io email reputation. Doesn't transfer; you're sending through your own SES under your AWS account, with your own DNS records. (This is a feature — your reputation, your control.)
- In-Customer.io event history. Apex starts collecting events when the snippet installs; historical events stay in your warehouse if you want them.
- Customer.io's reporting dashboards. Apex's calibrated-impact dashboard answers a different (better) question. If you need historical Customer.io metrics, export them before sunsetting the workspace.
FAQ
Does Apex support the same trigger conditions Customer.io does? All event-name + filter conditions: yes. Schedule + time-based triggers: the runtime accepts them but the UI is event-only in Phase 1; cron-style triggers land in Phase 2.
What about Customer.io's Visual Workflow Editor? Apex's canvas editor is the equivalent. Read-only canvas for published versions; drag-drop with per-step config drawer for drafts.
Can I keep Customer.io for SMS? Yes. Use Apex for email/push/in-app journeys; route SMS sends out of journeys via the Webhook step to a Twilio-or-similar destination.
How long does a typical migration take? Workspaces with 5-15 active workflows: half a day to a day. Workspaces with 50+ workflows: a couple of days because the review step is human-in-the-loop.
Get migration help
Drop us a line at migration@apex.inc with your Customer.io workspace export — we'll walk through the translated graphs and answer the cutover questions before you publish.