Migrating from AWS Pinpoint
AWS Pinpoint reaches end-of-life on October 30, 2026. New customer signups have already been disabled (since May 20, 2025). The recommended replacement — Amazon Connect — doesn't include Journeys, In-App Messaging, Push notifications inside Campaigns, Custom Channels, or Imported Segments. If you're using any of those Pinpoint features, you need to migrate to a different platform before the EOL date.
This guide maps Pinpoint concepts to Apex equivalents and shows you the practical migration path.
Why Apex specifically
- Keep the delivery setup you already trust. Your verified sending domain, reputation, and push credentials remain under your control.
- Strict feature parity for the Pinpoint paths Connect doesn't ship: Adaptive Journeys, in-app messaging, mobile push, webhook destinations you register.
- Better measurement than Pinpoint ever had: a global holdout, calibrated lift dashboard, council-reviewed census rules.
- Pricing transparency: your transactional sends are the same SES bill they always were; you're only paying us for the orchestration + measurement on top.
Concept mapping
| Pinpoint | Apex | Notes |
|---|---|---|
| Application | Workspace (workspaceKey) | Same scoping shape. |
| Endpoint | End-User (endUserId) | Apex unifies on a stable per-user identity rather than per-channel endpoints. The migration tool maps each endpointId to the corresponding endUserId based on shared user attributes. |
| Segment | Segment | Segments are saved predicates over events and attributes. The migration tool exports your Pinpoint dynamic segments as Apex segment predicates. |
| Imported Segment | Segment (org scope) | Larger lists go in as org-scope Segments referenced from a journey. |
| Campaign (one-shot) | Communication + Send (one-time trigger) | Most "campaigns" in Pinpoint are journey-shaped already; we model them as journeys with a single Send step. |
| Journey | Adaptive Journey | Pinpoint Journeys map 1:1 to Adaptive Journeys (docs). Multivariate "Random Split" maps to On a rule. "Multivariate Test" maps to an Experiment step. The old Adaptive Branch authoring mode is retired. |
| Yes/No split with EventCondition | Engagement Branch (event_response mode) | Pinpoint forces you to chain Yes/No splits to handle multi-event routing (Opened vs Clicked vs Bounced) and silently inserts a 1h wait before each — a frequent foot-gun. Apex's Engagement Branch lets you fan out to multiple paths at once with an explicit deadline; the migration tool auto-inserts the 1h Wait when your Pinpoint export had it implicit. |
| Email Channel | SES Engagement Set | Reuse your existing SES verified domain. |
| In-App Channel | In-App Push (web) | Same channel concept; renamed. |
| Push (APNS / FCM) | Mobile Push | Capacitor SDK ships with both adapters. |
| Custom Channel | Webhook step | Outbound HTTPS POST/PUT with HMAC-signed payload + DNS-rebinding-safe URL validation. |
| Event Stream | /api/events | The same SDK route you'd use for analytics. |
| Endpoint Authorization | Workspace API key | Per-workspace key, separately scoped from snippet keys. |
What you can leave as-is
- SES: Keep your existing domain identity, IP pools, and configuration sets. Apex sends through the SES account you connect; we don't proxy your sends through ours.
- DNS / DKIM / DMARC — already configured for your sending domain; Apex inherits.
- Event tracking — if you're already firing events into Pinpoint via PutEvents, the migration is
s/PutEvents/POST \/api\/events/. Same payload shape.
Migration steps
1. Inventory
Run the export tool against your Pinpoint application to produce:
- A JSON dump of every Segment, Journey, and Campaign
- A CSV of endpoint identities (so we can translate to
endUserId) - A list of custom event names + their schemas
The export takes ~5 minutes for a typical Pinpoint application. Larger applications (>1M endpoints) take longer; the tool checkpoints so you can resume.
2. Provision the Apex workspace
Sign up at apex.inc → workspace settings → install the snippet. The snippet is the same backbone as your tracking layer — you don't need to dual-write events.
3. Translate segments → Segments
The migration tool emits Apex Segment predicates for every dynamic segment. Static / imported segments become org-scope Segments.
Open /dashboard/customers/segments and review the translated segments. The tool flags segments it couldn't translate cleanly (e.g. segments using behaviors Pinpoint doesn't expose in the export — these are rare).
4. Translate journeys
Each Pinpoint Journey becomes an Adaptive Journey draft in Apex. The migration tool maps:
- Wait activities → Wait steps (duration mode)
- Yes/No Split → Branch (conditional, single condition)
- Multivariate Split → Branch (conditional, multiple conditions, default route)
- Holdout → Branch (conditional) with the holdout percentage as the default-route weight (note: most Pinpoint holdouts are per-journey; we recommend deleting these and using Apex's global holdout instead — it's a cleaner control)
- Send Email / Push / SMS → Send step pointing to a translated communication
- Custom Channel → Webhook step
5. Review + publish
The translated journeys land as drafts — nothing fires until you publish. Open each in /dashboard/communications/journeys/[id], walk it on the canvas, dry-run with a test subject, then publish.
6. Cut over
We recommend dual-running Pinpoint and Apex for 1-2 weeks:
- Set Pinpoint journey
Status: Closed(stops new entrants but lets in-flight finish) - Publish the Apex equivalent
- After 1-2 weeks of in-flight executions completing on the Pinpoint side, archive the Pinpoint application
What to do about in-flight Pinpoint executions
Pinpoint doesn't expose individual execution state via API, so we can't replay them in Apex. Options:
- Wait it out — most journey waits are days, not weeks; new entrants are already going through Apex.
- Send a one-shot bridge campaign — a final "we've moved" notification to the in-flight cohort, then close the Pinpoint journey.
What's NOT in the migration
- Pinpoint Analytics dashboards. Apex's calibrated-impact dashboard answers a different (better) question. If you need historical Pinpoint analytics, export them to S3 before EOL — they're gone after.
- Pinpoint custom user attributes. These have to be re-imported as end-user attributes via
/api/events(a one-time backfill).
FAQ
What happens to my existing SES warm-up? Untouched. We send through the SES account you connect; your IP reputation stays put.
Can I keep using Amazon Connect for voice/chat? Yes. Apex doesn't compete with Connect's voice/chat agent paths. We replace the Pinpoint messaging layer specifically.
Do I need to re-implement my event tracking? No. The Apex SDK accepts the same event shapes Pinpoint did. If you're already firing PutEvents, swap the URL.
What about the Pinpoint journey-status webhooks? Apex emits the same lifecycle events (execution.started, execution.exited, send.executed, etc.) into the audit log + (optionally) your webhook destination.
How long does a typical migration take? Workspaces with 5-10 journeys take a single afternoon end-to-end. Workspaces with 50+ journeys take 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 Pinpoint application export — we'll walk you through the translated graph and answer the cutover questions before you publish anything.