Quick answer: AWS's own documentation puts Amazon Pinpoint on a deprecation path: the public Pinpoint console and developer guide frame new campaign work as moving elsewhere, and AWS's published guidance redirects the service's two halves — targeted campaigns and basic message sending — toward Amazon Connect outbound campaigns on one side and the SNS / End User Messaging publishing lane on the other. Neither replacement is a drop-in for the whole product; each is a re-assembly of part of it. The honest third shape is leaving the estate entirely for one omnichannel CPaaS — SMS, MMS, WhatsApp, RCS, voice, and email on one account, with the customer data platform the segments re-home into — and that is the shape this runbook executes on Devotel Orbit. The joined AWS stack comparison carries the full evaluation; this post is the staged execution: export the event stream, port the segments, map campaign parity, dual-run, cut over.
If you run Pinpoint today, the question is not "is my campaign tool going away" — it is "which of the three replacement shapes fits my program, and what does the move sequence look like?" That is the frame this runbook applies.
What AWS publicly documents about Pinpoint's posture — and no more
This section cites only what AWS publishes, in the customer vocabulary AWS uses. No speculation, no rumored dates.
- The AWS Documentation page for Amazon Pinpoint (the public developer guide at docs.aws.amazon.com/pinpoint) frames Pinpoint as a campaign and messaging service and routes the getting-started story through the current-generation messaging surfaces. The page AWS maintains for the service is the primary public statement of its posture: readers should check that page directly, because AWS updates it and this runbook does not paraphrase a specific retirement date AWS has not published in a form we can cite.
- AWS End User Messaging is the lane AWS positions as the destination for SMS origination and number provisioning — the surface the AWS trio comparison records as the successor for Pinpoint's SMS side.
- Amazon SES is where AWS's published guidance points the email side of Pinpoint workloads.
Two governance notes fall out of the public documentation alone. First, a service on a documented deprecation path is a real budgeting event even without a hard date: the correct response is a planned move, not a panic. Second, everything AWS publishes points the migration at other AWS services — staying inside the AWS estate is the shape AWS writes down, by construction. Whether that estate shape is the right destination for your program is a decision AWS's documentation deliberately does not make for you.
The two replacement shapes AWS points at, honestly
AWS's own guidance splits Pinpoint's surface into two lanes, and each lane is a part-replacement.
Amazon Connect outbound campaigns. This is the campaign-targeting successor: customer engagement (SMS and voice campaigns) runs as outbound campaigns inside Amazon Connect, with the SMS numbers imported from End User Messaging over an IAM role handoff. As the Amazon Connect head-to-head records, Connect's contact-center core is genuine — queues, omnichannel routing, agent desktop score parity — but as a Pinpoint replacement it inherits Connect's provisioning shape: SMS and WhatsApp numbers arrive through End User Messaging, one number cannot carry both voice and SMS, and everything around the campaign core (AI, analytics, wider channels) compounds onto separately billed AWS services. For a team whose Pinpoint usage is campaign-heavy and already AWS-native, this is the shape AWS intends — and it is an honest fit this runbook does not pretend away.
The SNS / End User Messaging publishing lane. This is the message-sending successor: pub/sub fan-out on SNS for push and notifications, End User Messaging for SMS, SES for email. As the Amazon SNS head-to-head records, SNS delivers raw publish with per-request metering — and what it does not deliver is the campaign layer: no journeys, no segment-driven orchestration, no template-scoped multichannel sending. A team replacing Pinpoint with this lane rebuilds the campaign brain (segmentation, scheduling, quiet-hours logic, channel selection) on its own side of the SNS boundary, then owns that rebuilt brain forever.
Both shapes are assemblies: part-replacement plus per-service wiring plus per-service billing. For a deliberately AWS-only program, that posture is a choice, and this post scores it as parity, not a defect — the joined trio guide treats it the same way.
The third shape: consolidate onto one omnichannel CPaaS
The third shape reconsiders the estate entirely. Instead of splitting Pinpoint's two halves back into two AWS lanes, the program lands on one platform where the whole surface ships: SMS and MMS, WhatsApp, RCS, email, programmable voice, and video on one account; a native customer data platform the segments import into; a campaign journey builder that replaces the orchestration SNS never carried; and one pay-as-you-go bill with a published price page. On Devotel Orbit that is the shipped surface: SMS API, WhatsApp Business API, programmable voice, email API, and the native CDP the Orbit vs AWS Pinpoint head-to-head scores cell by cell.
The capability claims in that paragraph resolve to shipped, checkable surface: the three AWS head-to-heads (aws-pinpoint, amazon-sns, amazon-connect) publish the matrix rows with per-row notes, and the joined guide scores the accumulated AWS trio against the consolidated shape on five criteria. Read that comparison first if the shape decision is still open; this runbook assumes the decision is made and executes the move.
The staged runbook: Pinpoint to Orbit in five phases
Phase 0 — export the event stream and inventory before anything moves
Pinpoint's event stream (campaign events delivered to Kinesis or S3) is the historical record, and the first artifact to secure. Export the event history, then export the segment definitions and the campaign catalog: which segments are static versus dynamic, which campaigns are recurring versus one-off, which templates the sends actually use, and which numbers and sender identities the estate owns. Save the export untouched; the import wizards below read the groomed form, and a partial edit before import is a messy history.
Phase 1 — port the segments into the native CDP
Pinpoint segments are static or dynamic lists computed next to the campaign service; on Orbit they become audiences on the native customer data platform — identity resolution, golden records, and computed traits as platform core, not a Side-by-side segment store. Port the segments first so every later family — templates, campaigns, numbers — has its targeting layer live before it moves. Dynamic segment logic re-expresses as CDP traits and filters; endpoints (push tokens, phone numbers, emails) attach to unified customer profiles rather than per-campaign endpoint records.
Phase 2 — map campaign parity, one family at a time
Walk the campaign catalog and map each Pinpoint campaign to its Orbit surface:
- Recurring journeys (welcome series, drip cadences, re-engagement) rebuild on the visual journey builder — a canvas of trigger, condition, wait, channel-send, and branch nodes the campaign journey builder guide documents node by node.
- Reusable campaign copy re-authors once in the content-templates library, with channel-scoped variants (SMS body, WhatsApp rich variant, subject-bearing email variant) under one logical template — the templates API reference carries the layer, and the rendered-preview endpoint shows what each channel's recipient receives before any send.
- Transactional sends (OTP, receipts, alerts) move to the programmable channel APIs directly — SMS API, email API — on the endpoints your application already calls.
The parity gate for each family closes before the next moves: segments ported and matching counts, templates rendered and previewed, journeys validated against test traffic.
Phase 3 — port numbers and sender identities in two waves
Numbers are the regulated gate. SMS numbers and sender IDs re-register through the import contacts and numbers guides path and the number porting mechanics the phone number porting guide describes; 10DLC campaign registration in the US re-applies per tenant. Port in two waves — an after-hours or test identity first, the customer-facing identity second — so the second wave validates against the first before real traffic routes through it. Outbound voice and SMS terminate on Devotel's own wholesale network once cut over; the routing rules stay tenant-local.
Phase 4 — dual-run, then cut over on explicit criteria
Run both estates in parallel only as long as the plan names. The dual-run watches three signals on the new surface before cutover: delivery and engagement parity per segment cohort against the last exported Pinpoint baselines, template render correctness per channel, and journey completion rates per entry cohort. Cut over when those three hold for the plan's window; roll back to the still-running Pinpoint estate if one of them breaks. The consent register moves as part of the segment port — tenant-owned consent state, quiet hours, and retention are tenant-configurable controls on Orbit, set at rollout and enforced at send time, so a dual-run never sends to a contact the source estate had suppressed.
Frequently asked questions
Has AWS announced an end-of-life date for Pinpoint?
AWS's public documentation puts Pinpoint on a deprecation path and redirects the getting-started story to the replacement lanes (Connect outbound campaigns for the campaign side; SNS / End User Messaging, and SES for the sending side). This runbook cites only what AWS publishes; check the Amazon Pinpoint documentation page directly for the current posture, and treat the documented deprecation path as the planning trigger regardless of a specific date.
Should I follow AWS's own replacement guidance — Connect campaigns plus SNS/End User Messaging?
If your program is deliberately AWS-only and the missing campaign brain (journeys, segment orchestration, multichannel templates) is a rebuild your team wants to own, the two AWS lanes are the shape AWS intends and an honest fit. If the program spans more than the assembled lanes — wider channels, AI agents, a native customer record — the consolidated third shape is what the joined AWS comparison scores.
What does the migration actually move, in order?
Five phases: export the event stream and catalog first; port segments into the native CDP; map each campaign family (journeys, templates, transactional sends); port numbers and sender identities in two waves; dual-run on explicit parity criteria, then cut over. Each family's gate closes before the next family lands.
How do segments and consent records move?
Pinpoint segments re-express as audiences on Orbit's native CDP — identity resolution and computed traits as platform core — and consent state moves as tenant-owned controls: consent, quiet hours, and retention are tenant-configurable settings set at rollout and enforced at send time. A contact the source estate suppressed never sends on the new estate.
Where is the full feature comparison before I commit to the third shape?
The cell-by-cell matrix with per-row notes lives on Orbit vs AWS Pinpoint, and the joined evaluation of the accumulated AWS trio — Pinpoint, SNS, Connect — lives on the AWS communications stack comparison. This runbook is the execution once that evaluation closes.
The takeaway
AWS documents Pinpoint's deprecation path publicly and points the two halves of the product at two in-AWS lanes — Connect outbound campaigns, and SNS / End User Messaging plus SES. Both are assemblies: part-replacement plus wiring your team owns. The third shape consolidates the whole surface onto one omnichannel platform, and the move runs in five staged phases — export, segments, campaign parity, numbers, dual-run — with an explicit cutover gate at the end. Start with the joined comparison if the shape decision is open; start with Phase 0 above if it is closed.
Published 15 September 2026.