AWS Pinpoint reaches end-of-life October 30, 2026: what to do now

On April 30, 2025, AWS announced that Amazon Pinpoint reaches end-of-life on October 30, 2026. New customer signups have already been disabled (May 20, 2025). After EOL, the Pinpoint API stops accepting requests and existing journeys + campaigns stop firing. If you've built lifecycle marketing on Pinpoint, you have eighteen months to migrate.

AWS's recommended successor is Amazon Connect. We are nine months into watching teams hit a wall when they try to migrate, because Connect is missing the five Pinpoint features most lifecycle teams actually use. This piece walks the timeline, the migration trap, and the path that doesn't require you to abandon AWS.

What's actually happening

Pinpoint launched in 2017 as AWS's bet on B2C lifecycle marketing — a managed service for journeys, segmentation, and multi-channel sends sitting on top of SES (email), SNS (push), and Lambda. It worked. Series B+ growth teams adopted it because it kept their PII inside their AWS account, used the same SES sending reputation they'd already warmed up, and didn't require buying a SaaS that exfiltrated customer data to a third-party vendor.

Eight years later, AWS decided the maintenance burden wasn't paying back. The official announcement points customers at Amazon Connect — AWS's contact-center product — as the migration target. The problem: Connect was never a marketing platform. It evolved out of voice-call automation, and its journey-equivalent features (Connect Journeys) cover a smaller surface area than Pinpoint's.

The five gaps

We mapped Pinpoint's feature set against Amazon Connect's, line by line. Five Pinpoint features have NO Connect equivalent:

• Pinpoint Journeys — Connect Journeys exist but are scoped narrowly to contact-center flows. They don't ship the multi-step branch + wait + multi-channel send shape Pinpoint offers.
• In-App Messaging — Pinpoint can fire in-app messages to apps using the AWS Mobile SDK. Connect can't.
• Push notifications inside Campaigns — Connect can send push, but only as transactional one-offs, not as a campaign primitive with audience targeting.
• Custom Channels — Pinpoint lets you ship a custom channel via Lambda for any HTTP-based delivery (Slack, Discord, your own webhook). Connect doesn't have this primitive.
• Imported Segments — Pinpoint accepts CSV uploads as static segments. Connect requires you to load contacts via the contact-center contact-flow, which is a wildly different mental model.

If your Pinpoint usage avoids all five of those features (rare — most lifecycle teams use at least three), Connect might work. Otherwise you need to migrate to a different platform that ships the missing features.

The two migration paths

Most teams we talk to consider one of two paths: a SaaS lifecycle vendor (Customer.io, Iterable, Braze, Klaviyo) or stay AWS-native by adopting an open-core platform that runs on the same primitives.

Path 1: Migrate to a SaaS lifecycle vendor

This path is fast to set up but introduces a new vendor in your data flow. Every customer event, every PII attribute, and every audience query now goes through the SaaS vendor's infrastructure. Your sending reputation moves to their IPs (or you pay extra for a dedicated IP that you have to re-warm). Your DPA framework expands by one vendor. Your security review expands by one vendor.

Pricing is the second wrinkle. Most SaaS lifecycle vendors charge per monthly-active end-user. The teams we've watched migrate from Pinpoint to a SaaS often find that their cost goes up 3-5x — Pinpoint's per-message pricing was effectively at-cost SES pass-through, and SaaS vendors price for their margin, not for the underlying SES bill.

Path 2: Stay AWS-native with an open-core platform

The alternative is to migrate to a platform that's built on the same AWS primitives Pinpoint uses — same SES, same SNS, same Lambda, same VPC region — but ships the missing features. Apex's Adaptive Journeys is one such platform, and the migration path is intentionally short:

1. Run our open-source CLI (tools/migration/pinpoint-export) against your Pinpoint Application. It uses the AWS Pinpoint SDK with your existing IAM credentials and dumps your segments + journeys + campaigns to a JSON file.
2. Drop the JSON into the migration UI in your Apex workspace. The translator runs server-side, produces an Apex import bundle, and shows you every translation decision side by side with a warning when something needs review.
3. Review warnings, then click Apply. Audiences and draft journeys are created in your workspace. Edit each draft journey in the canvas, dry-run it against a real user, then publish.

Email keeps using your verified SES domain — your sending reputation doesn't move. Push uses SNS through the same APNS/FCM credentials you already configured. Your customer PII never leaves your VPC region. The translator is open-source so you can read every assumption before you trust it.

What you gain by switching now

Apex ships three primitives Pinpoint never had:

• Adaptive Branches — Thompson-sampled journey arms. The runtime samples each arm's posterior conversion rate and routes the user to the highest sample. Cold-start uses deterministic round-robin until each arm has 200 subjects, then Thompson takes over. Pinpoint required you to manually declare A/B test winners and re-deploy the journey.
• Global Holdout — 5% of every workspace's end-users are deterministically held out from all journeys. The same user is held out across every journey, by design (so journey effects don't compose chaotically). Exposed-vs-holdout conversion rates give you the calibrated impact of your journey portfolio.
• Calibrated Impact dashboard — per-journey predicted-vs-observed lift, computed from real outcomes within the configured attribution window. Daily-lift trendline. Honest 'underpowered' messaging when the cohort sizes are too small to draw conclusions. Pinpoint's analytics were impression-level; this is outcome-level.

The timeline math

Eighteen months feels like a lot until you start counting backwards. Most teams we talk to follow this rhythm:

• First two weeks: scope the migration. Inventory your Pinpoint segments + journeys + campaigns. Identify the ones that use one of the five features Connect doesn't ship.
• Next 4-6 weeks: shadow the migration on the new platform. Run BOTH platforms in parallel — Pinpoint keeps firing real journeys, the new platform mirrors the same journeys against a holdout cohort, and you compare outcomes.
• Next 4-6 weeks: cut over the lower-stakes journeys (welcome, post-purchase nurture). Validate that sends land, opens track, conversions attribute.
• Next 4-6 weeks: cut over the higher-stakes journeys (cart abandonment, churn save). These are the ones with measurable revenue impact, so you want them on the new platform with the new measurement framework before EOL.
• Final 1-2 months: cut over the long-tail. Triggered transactional flows, internal admin notifications, edge cases.

That's 4-7 months of active work, plus buffer. Teams who start in Q3 2025 finish before Q1 2026 with months of cushion. Teams who wait until Q1 2026 finish in Q3 2026 with no margin for production issues. Teams who wait until Q3 2026 are running a fire drill.

What to do this week

If you're on Pinpoint and haven't started a migration, three concrete steps for this week:

1. Inventory your Pinpoint usage. Run our pinpoint-export CLI even if you don't migrate to Apex — the JSON it produces is a clean inventory of what you'll need to reproduce on whatever platform you pick.
2. Map each Pinpoint feature you use against the five gaps. If you don't use any of them, Amazon Connect might be enough. If you use one or more, you need a different platform.
3. Pick a migration target and run a 1-week shadow test on a low-stakes journey (e.g., a welcome email). Validate end-to-end before you commit to a full migration.

October 30, 2026 isn't going to move. The teams who treat it like a real deadline will land on the other side with the same SES reputation, an upgraded measurement framework, and zero customer-visible disruption. The teams who don't will spend the back half of 2026 in a war room.