If your mobile app leans on Amazon Pinpoint for push and in-app messaging, you have a hard deadline and a messy migration ahead of you. On October 30, 2026, AWS ends support for Amazon Pinpoint. After that date, the console and everything you built inside it (endpoints, segments, campaigns, journeys, and analytics) stops being accessible.
Pinpoint also stopped accepting new sign-ups back on May 20, 2025, so the service has been on a countdown for a while. AWS spells out the full timeline in its official end-of-support guide.
The shutdown is the easy part to understand. The awkward part is where AWS sends you next, because there’s no single successor product. Depending on what you used Pinpoint for, your workload gets split across 4 different AWS services. And for the 2 things most mobile teams care about, push and in-app, the recommended path doesn’t carry them over cleanly.
In this guide: what turns off, where AWS routes each piece and why it isn’t a like-for-like swap, and a 4-step plan to move your push-and-in-app program to Pushwoosh instead. With real numbers, so you can actually budget the move.
What’s actually shutting down
The messaging channel APIs aren’t going away. What’s disappearing is the engagement layer, the part your marketing and product teams log into.
After October 30, 2026, you lose access to your Pinpoint resources: endpoints (your stored user and device records), segments (dynamic audiences), campaigns (scheduled sends), journeys (the multi-step automation builder), and the built-in analytics dashboards that tracked delivery, opens, and journey engagement.
What survives, under a different name, is the raw channel layer. SMS, voice, mobile push, OTP, and phone number validation keep working through AWS End User Messaging, which is what AWS renamed Pinpoint’s channel APIs back in Q3 2024. So if you only ever used Pinpoint as a dumb pipe, where your own backend holds the logic and just calls the API to fire a transactional push or text, you have less to worry about. You re-point your API calls and move on.
But if your team built audiences, campaigns, and journeys inside the Pinpoint UI, that’s the workflow that breaks. Rebuilding it inside AWS is where the real work starts.
Where AWS sends you, and why it isn’t a 1:1 replacement
AWS’s own migration guide doesn’t hand you a replacement. It hands you 4, 1 per capability:
- Engagement (endpoints, segments, campaigns, journeys) → Amazon Connect outbound campaigns + Customer Profiles
- Events and mobile analytics → Amazon Kinesis
- Email → Amazon SES (Simple Email Service)
- SMS, push, voice, OTP → AWS End User Messaging
Still one vendor, technically. But now it’s 4 separate products, 4 consoles, and 4 sets of docs standing in for the one system you had. For a team without a dedicated platform-engineering group, that’s a much heavier lift than “migrate to a new tool” usually implies.
And for mobile teams, that engagement destination is where it gets complicated. Amazon Connect has gaps that are easy to miss until you’re already mid-migration.
- In-app messaging isn’t in Connect at all. AWS says so itself: the migration docs list it under unavailable features, in writing. If in-app onboarding, feature prompts, or paywalls are part of how your app works, there’s no native home for them on the recommended path.
- Push isn’t a native campaign channel. Push (GCM, APNS, Baidu, and the rest) isn’t supported natively in Connect campaigns. AWS’s guide says you can still send it, but only through a journey, using a Lambda action wired to Connect push templates. In practice that means you write and maintain code just to replicate what Pinpoint did out of the box.
- Custom Channel is only half there. It’s available in journeys but not in campaigns. One more seam in a mobile stack that Connect leaves you to patch yourself.
- Templates share an engine but not the syntax. Connect templates use the same Handlebars rendering engine as Pinpoint, so your logic carries over. The attribute placeholders, though, are written differently: something that read
{{User.UserAttributes.PurchaseHistory}}in Pinpoint becomes{{Attributes.Customer.Attributes.PurchaseHistory}}in Connect. Every template has to be fetched and rewritten by hand. - Migrating endpoints is a scripting job. To move your users, AWS has you export a no-filter segment to S3, then run a Python script to reshape those endpoints into Customer Profiles, where a single profile caps at 3 email addresses and 4 phone numbers. It works. It’s also code you write, test, and own.
None of this makes the AWS path wrong. If you’re already all-in on Connect for contact-center use cases, it might be exactly right for you. But if push and in-app are the reason you were on Pinpoint in the first place, the recommended migration hands those 2 channels straight to your engineers to rebuild. That’s the part worth knowing before you start, not 3 sprints in.
Moving your push-and-in-app program to Pushwoosh in 4 steps
Pushwoosh is a customer engagement platform built mobile-first: push, in-app, and web push are the core channels, with email and SMS alongside them. Instead of splitting your program across 4 AWS services, you rebuild it once, in one place. Here’s how the migration goes.
-
Export your Pinpoint data
Pull your endpoints, segments, campaigns, and journey definitions using AWS's own APIs while the console is still live. Waiting until closer to the deadline only makes retrieval harder, and you'll want this exported no matter where you land, so do it early.
-
Re-point your mobile SDKs
Swap the Pinpoint or Amplify SDK for the Pushwoosh SDK, then confirm devices are registering and events are flowing before you cut over anything user-facing. This is the step that reconnects your app to a live messaging backend.
-
Rebuild segments and journeys
Import your users, map your Pinpoint attributes onto Pushwoosh's tag and segmentation model, and recreate your automations in the visual journey builder. It's like-for-like work: you're re-implementing logic you already know rather than designing from scratch. This is also the exact piece that would otherwise land on your engineers under the Connect path.
-
Reconnect events, then pilot
Wire your custom events back up so behavioral triggers fire, run a pilot send to a small segment to confirm parity, and only then move full volume. Leave real calendar time for domain authentication and any sender registration, because none of that speeds up just because the deadline is close.
The difference from the AWS route shows up in the boring places. Where AWS’s guide has you write and run a Python script to reshape endpoints into Customer Profiles, Pushwoosh imports users through the UI or API, with no script to author and maintain. Where Connect asks you to route push through a Lambda-backed journey, push is just a channel you pick. The engineering you’d budget for on the AWS side mostly evaporates.
What it costs
Pricing is the part most migration write-ups keep vague, so here it is plainly. Pushwoosh bills on monthly active users (MAU) — see the full pricing breakdown — and for a push-and-in-app workload the entry point is deliberately low:
- Push Only — $7 per 1,000 MAU. If push and in-app are the whole program, this is the tier that maps to it, with no omnichannel overhead you won’t use.
- Omnichannel — $13 per 1,000 MAU. Adds email, SMS, and the rest of the channel mix when you want everything under one roof.
- Custom — from $2,000/month. Volume pricing, dedicated support, and enterprise terms for larger sends.
For a team that mainly needs to replace Pinpoint’s push and in-app, that $7 entry is a lot less friction than committing to a full marketing-automation suite. Which is exactly the trade-off the Braze, Customer.io, and Iterable tier asks you to make.
Don’t wait for October
The migration itself is a known quantity: export, re-point, rebuild, test. The calendar is the hard constraint. October 30, 2026 is a fixed cutoff, and the steps that eat real wall-clock time (SDK cutover, event mapping, domain and sender setup) run at their own pace no matter how close the date gets.
You can start with your actual data on a free tier of 1,000 MAU, which is enough to import a real segment, rebuild a journey, and run a pilot send to see parity for yourself before committing to a full cutover. Our advice, having watched enough of these run late: scope it against your real MAU and timeline now, while the Pinpoint console is still there to export from. The teams that leave it to September are the ones discovering the gaps 3 weeks before the lights go off.
