Moving Pinpoint email to Amazon SES requires more than changing the sending API. Export the data and workflow definitions, preserve suppression and subscription decisions, verify the destination account, and rebuild campaign orchestration separately. Pinpoint reached end of support on October 30, 2026, so the export steps apply only to data you exported before then; if you have no export, ask AWS Support what can be recovered and start from your SES setup. The steps below distinguish documented AWS operations from migration decisions.

Updated October 30, 2026.

Confirm the affected workloads first

According to AWS’s end-of-support notice, Pinpoint stopped accepting new customers on May 20, 2025. Since October 30, 2026, customers cannot access its console or resources: endpoints, segments, campaigns, journeys and analytics. AWS recommends Amazon Connect engagement solutions for applicable engagement workloads, Kinesis for event collection and mobile analytics, and Amazon SES for email.

AWS says the communication channels were renamed AWS End User Messaging in 2024. APIs for SMS, voice, mobile push, OTP and phone-number validation are not affected by this retirement. Continuing delivery APIs do not preserve the Pinpoint journeys or audiences that invoke them. Map those dependencies separately.

Step 1: inventory the source and destination

Record the AWS account, Region and Pinpoint application ID for each workload. List active campaigns, segment definitions, journeys, template versions, event streams, API-triggered sends and reporting consumers. Preserve the source definition and its operational meaning, including timezone, entry rules, delays and exits.

Check whether the email identity, configuration sets, suppression configuration and IP arrangement already exist in the relevant SES account and Region. Do not recreate resources or assume reputation will transfer simply because the email address stays the same. Follow the email offboarding section in the official AWS migration guide.

Step 2: export endpoint data through a documented path

AWS documents creating a segment without filters to encompass endpoints, then exporting that segment. For a programmatic export, the real CLI operation is aws pinpoint create-export-job. Its request includes the export job settings such as the IAM role ARN and S3 destination, with optional segment scope. Creating the job writes exported data and requires an approved destination and permissions. Have the technical owner confirm the request parameters and export destination before running it.

There is no documented “aws pinpoint get-endpoints” command for exporting a segment. Do not substitute the singular get-endpoint operation as a bulk export. Select the documented export method, wait for successful completion, and reconcile record counts and required fields before accepting the output.

• Protect the destination with least-privilege access and your required encryption and retention controls. Do not delete migration records automatically at cutover.
• Preserve endpoint identifiers, user associations, attributes, channel and opt-out state. Capture consent source and timestamps from the systems that actually hold them.
• Reconcile segment definitions separately from segment members. A snapshot of members does not reproduce a dynamic rule.
• Retain exclusion records rather than simply deleting invalid addresses from the export. The destination needs enough information to avoid reactivating a suppressed recipient.

Step 3: retrieve templates and journey definitions

Use the documented get-email-template operation for an identified email template and get-journey for an identified journey. The response includes the journey’s configuration and settings. Keep a human-readable flow alongside the exported definition to review behavior.

These operations retrieve the specified resources without changing them. Verify the exact required identifiers and template version in the official CLI reference. Do not assume an exported definition imports directly into SES or another platform.

Review HTML, plain text, subject, substitutions, defaults, links and hosted assets. Test representative data and missing-value cases in the destination. Inspect unsubscribe links and endpoint-specific permissions. Template syntax and hosted assets need separate checks in the destination.

Step 4: preserve suppression and subscription decisions

SES provides an account-level suppression list for bounce and complaint reasons. Review the actual account and Region, settings and configuration-set overrides. This is distinct from all marketing preferences, contact-list subscriptions and your legal basis for sending.

Do not promise a downloadable global suppression list or treat address validation as consent. Reconcile the suppression and opt-out records available to your organization. Test that unsubscribes and complaints reach the destination’s decision logic before introducing traffic.

Step 5: verify SES readiness without weakening authentication

Check production access and sending quotas in the destination Region; do not assume a new account is ready or promise a fixed approval time. Validate the verified identity, DKIM, configuration sets, event destinations and bounce/complaint handling required by your architecture.

For SPF, follow AWS’s custom MAIL FROM documentation. SES’s default MAIL FROM and a custom MAIL FROM have different alignment implications. If you use a custom MAIL FROM domain, publish the exact MX and SPF records specified for that configuration. Do not choose an SPF record by shared versus dedicated IP or add IP addresses blindly.

Keep an existing enforced DMARC policy unless the responsible security and email owners approve a justified change. Migration is not a reason to downgrade every domain to p=none. Verify aligned DKIM or SPF and review authentication reports. Never remove DNS records solely because a provider name appears related to Pinpoint.

Step 6: rebuild the workflow layer and validate IP assumptions

SES supports email operations but does not recreate Pinpoint journeys. Choose a managed platform or an owned architecture and implement entry criteria, state, retries, scheduling, exits and reporting. CampaignHQ is a customer retention automation platform for email and WhatsApp, and a Meta Business Partner. AWS supports its infrastructure. For teams retaining SES, assess CampaignHQ as the marketing workflow layer. Confirm data mapping, event integrations, security requirements and support responsibilities during discovery. Agree the migration scope, channel support, timetable and cutover responsibilities before committing.

Do not select dedicated IPs using a universal daily-volume threshold or publish a fixed warmup schedule. Confirm the actual pool, transfer support and warmup requirements with AWS for your account and sending pattern. Preserving an identity does not guarantee unchanged inbox placement.

Step 7: pilot without duplicate production sends

• Obtain approval for test recipients and test data. Verify authentication, rendered messages, links, preferences, event delivery and failure alerts. Use designated test addresses before introducing production recipients.
• Assign each recipient and event to one sending owner. Parallel validation must not produce two copies of a campaign or restart the same journey.
• Compare delivery, bounces, complaints, exclusions and business outcomes against the recorded baseline. Opens alone do not prove migration success.
• Agree stop conditions and a rollback owner. Expand only after the pilot passes the criteria appropriate to your workload.

Step 8: cut over and hand over operations

Switch approved event and application integrations, confirm that retired Pinpoint workflows no longer send, and reconcile final preference changes. Keep the necessary exports, evidence and operating runbooks under the agreed retention policy. Do not treat an archived project as a substitute for the exports made before access ended.

Use the retention platform migration checklist for acceptance and handover. Keep platform selection on the Pinpoint alternatives guide and deadline ownership on the end-of-support guide.

Frequently asked questions

Can I export all contacts with get-endpoints?

No. That command is not a documented Pinpoint CLI operation. Use the official segment export or create-export-job path with approved permissions and destination.

Can journey definitions be retrieved?

Yes. AWS documents get-journey. The response is useful migration input, not an automatically runnable workflow in the destination.

Do suppression records prove permission?

No. Bounce and complaint suppression, unsubscribe preferences and consent are related but separate controls. Preserve and enforce each applicable source of truth.

Will the same domain guarantee the same reputation?

No. The IP pool, authentication, sending pattern, audience and recipient behavior also matter. Verify the supported account-specific migration path.

Must SMS and push move to SES?

No. SES is for email. The AWS notice identifies continuing messaging APIs under AWS End User Messaging; replace any Pinpoint engagement logic that calls them.

Written by CampaignHQ Team