AWS quietly changed its AWS Pinpoint product strategy in 2024. What used to be a bundled email, SMS, and push messaging platform is now squarely focused on mobile and multichannel engagement, while its email capabilities have been effectively deprecated for new workloads. If you are running email campaigns on Amazon Pinpoint today, you have probably already felt the squeeze: slower feature releases, increasingly stale documentation, and a growing sense that the platform is not heading where you need it to go.

The natural destination for Pinpoint email users is AWS SES (Simple Email Service). SES gives you direct access to the underlying infrastructure that powered Pinpoint all along. But the migration is not a flip-of-the-switch migration. Pinpoint abstracts away a lot of infrastructure complexity that SES exposes to you as an operator. This guide walks you through every step of the process, from auditing what you have running today to completing a cutover with confidence.

Before You Start: Prerequisites and Planning

A migration without a plan is a migration that will surprise you. Before touching any exported data or creating any new AWS resources, spend time on the following.

Audit your current Pinpoint usage. Log into the AWS Pinpoint console and document everything you are using: active campaigns, transactional email templates, contact segments, journey automations, and any event-triggered messages. Pinpoint does not offer a bulk export of your full configuration, so you will need to pull this data manually or via the Pinpoint API. Set up a spreadsheet or a shared doc to track each artifact: its name, its type, its last-modified date, and the estimated volume it handles.

Identify your sending volume and patterns. Pull at least 90 days of sending data from Pinpoint. You need to know your average daily volume, peak volume, bounce and complaint rates, and unsubscribe volumes. This data serves two purposes: it tells you what warmup schedule to plan for in SES, and it establishes the baseline you will compare against after cutover.

Choose your destination architecture. SES is a raw sending service. It does not have contact lists, campaign management, journey builders, or analytics dashboards built in. After migration you have two broad paths: build the missing layers yourself using Lambda, Step Functions, DynamoDB, and CloudWatch, or deploy a platform that sits on top of SES and provides those layers for you. CampaignHQ is one such platform, and it is worth knowing about because it is a Meta Tech Partner that offers email and WhatsApp marketing automation on AWS, purpose-built for teams migrating away from Pinpoint.

Set up a migration workspace. Create a dedicated S3 bucket in your AWS account to hold exported data during the migration. Use a clear naming convention like pinpoint-export-prod-2026. Restrict access to the migration team. This bucket is temporary; you will delete it after successful cutover.

Step 1: Export Your Contact Lists and Segments

Amazon Pinpoint stores contact data and segment definitions in its own managed database. There is no one-click export that gives you everything, so this step requires API work or manual console export depending on your volume.

Exporting contacts via the Pinpoint API

Use the GetEndpoint and GetSegments API operations to pull your data. If you have more than a few thousand contacts, script this with the AWS SDK. Here is the general approach using the AWS CLI:

aws pinpoint get-endpoints \
  --application-id your-app-id \
  --segment-id segment-id

Repeat this for each segment. If you are exporting all contacts without segmentation, you may need to work with the GetUsers operation or use the Pinpoint streaming export feature.

What to capture for each contact

At minimum, capture these fields for every contact:

• Email address
• Subscription status (opted-in, unsubscribed, bounced)
• Creation date and last updated date
• Custom user attributes and user traits
• Tags and segment memberships

Do not assume that Pinpoint has already applied unsubscribe and bounce suppressions to your export. You need to export the raw address state and then validate each address before importing into SES or your new platform.

Segment definitions

Pinpoint segment definitions are JSON objects that describe filter rules. Export the raw segment JSON for each segment you want to recreate in your new system. You will need to translate these into whatever query syntax your new platform uses.

Data cleaning before import

Run your exported contact list through a validation step before importing anywhere. At minimum:

• Verify email address format
• Remove addresses that Pinpoint marks as invalid or blocked
• Deduplicate across segments
• Check for addresses that appear in the global suppression list

If you are moving to CampaignHQ, their import tooling handles most of this validation automatically. If you are building on raw SES, you will want to use a validation service like ZeroBounce or AWS SES email validation before importing.

Schedule a Migration Consultation

Step 2: Export and Audit Your Email Templates

Pinpoint stores email templates in two forms: campaign templates (used in recurring campaigns) and transactional message templates (used in API-triggered sends). Both need to be exported and reviewed.

Exporting templates

In the Pinpoint console, navigate to Templates, select each template, and use the Export option. Pinpoint exports templates as JSON files. For high-volume transactional templates, use the Pinpoint GetEmailTemplate API operation to pull the full template payload, including subject line, HTML body, text body, and any template variables.

Audit each template for these common issues

• Hardcoded content: If the template embeds recipient-specific data via hardcoded substitutions rather than dynamic template variables, flag it for rewrite.
• Variable syntax differences: Pinpoint template syntax differs from SES template syntax. Every template will need variable syntax updated from Pinpoint format to SES format.
• Images hosted on Pinpoint CDN: Pinpoint allows you to upload images for use in email templates. These are stored on Pinpoint-managed infrastructure and will break after migration. Export any images and re-host them on your own CDN (S3 + CloudFront, or a dedicated image hosting service).
• Sender identities: Note the from-name, from-address, and reply-to address used in each template. These must be verified in SES before you can send from them.
• Links to Pinpoint unsubscribe pages: If your templates link to Pinpoint’s built-in one-click unsubscribe handling, those links will stop working after migration. You need to implement your own unsubscribe handling.

Step 3: Document Your Journey Automations

Journey automations in Pinpoint are where the complexity hides. They combine audience selection, timing rules, branching logic, wait conditions, and action triggers into multi-step flows. Pinpoint does not offer a structured export of journey definitions. This step is documentation work, not data extraction.

Map every active journey

For each active journey, document the following:

• Journey name and ID
• Entry trigger (what starts the journey: a campaign send, an API event, a segment import)
• Audience definition (which contacts enter, and when)
• Steps and branching logic (draw it out as a flowchart if it is complex)
• Action at each step (email send, tag update, wait, conditional branch)
• Timing rules (send time preferences, wait durations between steps)
• Exit conditions (when a contact leaves the journey)
• Associated email templates used in each email action

Identify journeys that require complete rebuild versus simple

A journey that sends a single welcome email 30 minutes after sign-up is straightforward. A journey that branches based on email opens, waits 48 hours, sends a reminder only if the first email was not opened, then escalates to SMS if still unengaged after seven days, is a significant rebuild effort. Knowing which category each journey falls into lets you prioritize and sequence your build work correctly.

Note API-triggered sends

Pinpoint supports transactional email sending via its API (direct send without a campaign). Identify every API call pattern in your application that sends email through Pinpoint. For each one, document the API endpoint, the payload structure, the triggering event, and the template used. After migration, these API calls will need to point to SES or your new platform’s API instead.

Step 4: Set Up AWS SES

With your exports complete and your journey logic documented, it is time to set up the SES infrastructure. This step covers identity verification, production access, and initial configuration.

Create your SES identity

In the AWS SES console, navigate to Verified Identities and create an identity for each domain and address you plan to send from.

For domain-level sending (recommended), add a domain identity and use the DKIM verification method. SES will give you three CNAME records to add to your DNS configuration. Add these to your DNS provider (Route 53, Cloudflare, or whoever hosts your DNS). DKIM verification typically takes 15 minutes to 72 hours depending on your DNS propagation speed.

For individual email addresses (for testing or dedicated sender addresses), add them as email identities. SES will send a verification email to each address, and you must click the link to complete verification before sending.

Request production access

New SES accounts start in sandbox mode. In sandbox mode, you can only send to verified email addresses and domains. To send to any recipient, you must request production access.

In the AWS console, go to SES Account Settings and request production access. AWS will ask you about your sending use case, estimated volume, how you handle bounces and complaints, and your unsubscribe process. Be specific and honest. Describe your migration from Pinpoint, your expected volume, and how you will handle suppression. Production access requests typically take 24 to 48 hours, though complex cases can take longer.

See CampaignHQ Pricing

Step 5: Configure Sending Infrastructure

SES requires you to configure sender authentication to get reliable inbox placement. This is not optional. Without proper authentication, mailbox providers will reject or bulk-folder your messages.

DKIM setup

DKIM proves that email coming from your domain was actually sent by you (or someone you authorized). SES makes DKIM setup straightforward through the console. When you verify a domain identity, SES generates three DKIM records for you. Add these to your DNS as CNAME records. Then enable DKIM signing in the SES console for that identity.

SPF setup

SPF specifies which mail servers are authorized to send email on behalf of your domain. For SES, add an SPF record to your domain’s DNS that includes SES’s sending infrastructure. The exact record depends on whether you use shared or dedicated IPs:

• For shared IPs: include the SES default SPF record
• For dedicated IPs: include your dedicated IP addresses in your SPF record

DMARC setup

DMARC tells mailbox providers what to do with email that fails DKIM or SPF checks. Start with a monitoring-only DMARC record (p=none) during your migration and warmup. Once you confirm that DKIM and SPF are passing consistently, upgrade to a quarantine or reject policy. DMARC also gives you aggregate reports (via the rua tag) that show who is sending email as your domain, which helps detect unauthorized sending.

Dedicated IP addresses

If you send more than 50,000 emails per day consistently, consider requesting dedicated IP addresses in SES. Dedicated IPs give you full control over sender reputation. But they require warmup: you cannot start sending high volumes on a fresh dedicated IP without triggering reputation penalties. Plan a 2 to 4 week warmup where you gradually increase daily volume while monitoring bounce and complaint rates.

Step 6: Rebuild Your Journey Logic

SES does not have a journey builder. You need to implement journey logic yourself or through a platform. Here are the main options.

Option A: Build with Lambda and Step Functions

If you have engineering capacity and want full control, implement journeys using AWS Lambda for email sending logic and Step Functions for orchestration. Store contact data in DynamoDB. Use EventBridge for triggering journeys based on application events.

This approach gives you maximum flexibility but requires significant development effort. Estimate 2 to 4 months of engineering work for a basic journey system with contact management, scheduling, and basic analytics.

Option B: Deploy CampaignHQ on SES

CampaignHQ runs on top of SES and provides the marketing layer that Pinpoint offered: contact lists, segments, journey builder, templates, and analytics. As a Meta Tech Partner, CampaignHQ also adds native WhatsApp integration, which Pinpoint never provided.

For teams migrating from Pinpoint, CampaignHQ offers migration support including template translation, journey recreation, and contact import with validation. This path reduces migration time from months to weeks and eliminates ongoing maintenance burden.

Step 7: Test and Warm Up Your Sending

Before cutting over production traffic, test your new sending infrastructure thoroughly.

Functional testing

Send test emails to accounts you control across major mailbox providers: Gmail, Outlook, Yahoo, and any regional providers your recipients use (T-Online in Germany, GMX in Austria, etc). Verify:

• Email arrives in inbox (not spam)
• Images load correctly
• Links work
• Unsubscribe link functions
• Authentication headers pass (check with MXToolbox or similar tools)

Warmup for new IPs or domains

If you are using new dedicated IPs or sending from a domain that has not sent significant volume before, follow a warmup schedule:

• Week 1: 500 to 1,000 emails per day
• Week 2: 2,000 to 5,000 emails per day
• Week 3: 10,000 to 25,000 emails per day
• Week 4: Scale toward your target volume

Monitor bounce and complaint rates daily. If bounce rate exceeds 5% or complaint rate exceeds 0.1%, pause and investigate before continuing warmup.

Step 8: Run Parallel and Cut Over

For most teams, the safest migration is a parallel running period where you send some traffic through the old system and some through the new, comparing results before full cutover.

Parallel running

Select a subset of your list (10 to 20%) and route their traffic through SES while the remainder stays on Pinpoint. Compare delivery rates, open rates, click rates, and bounce rates between the two groups. If SES performance matches or exceeds Pinpoint, expand the percentage gradually over 1 to 2 weeks until all traffic flows through SES.

Final cutover

Once you are confident in SES performance, update any application code that sends via Pinpoint API to use SES API or your new platform’s API instead. Update DNS SPF records to remove Pinpoint if they were previously included. Archive your Pinpoint project for reference but do not delete it immediately in case you need to reference historical data.

Talk to Our Team

Decision Framework: Raw SES vs CampaignHQ on SES

After infrastructure setup, you have a choice: build your own marketing layer on SES, or deploy CampaignHQ as that layer.

Choose raw SES if:

• You have dedicated engineering resources for building and maintaining marketing tooling
• You need highly custom sending logic that existing platforms cannot support
• You want full control over every aspect of the infrastructure
• You are comfortable with ongoing maintenance and feature development

Choose CampaignHQ on SES if:

• You want to migrate quickly without months of engineering work
• You need a visual journey builder that marketing teams can use
• You want email and WhatsApp in a single platform
• You prefer ongoing feature development and support from a Meta Tech Partner
• You want Indian payment options and regional support

Frequently Asked Questions

How long does a Pinpoint to SES migration typically take?

For a mid-sized team with 100,000 to 500,000 contacts and 3 to 5 active journeys, expect 6 to 10 weeks from planning to full cutover. If you use CampaignHQ, you can reduce this to 3 to 5 weeks since the marketing layer is already built and their team handles migration support.

Will my sender reputation transfer from Pinpoint to SES?

Sender reputation is tied to your domain and IP, not the platform. If you migrate with the same sending domain and use dedicated IPs in SES, your reputation generally transfers. If you switch to shared IPs or a new sending domain, you start fresh and need warmup time.

Can I keep using Pinpoint during the migration?

Yes, parallel running is recommended. You can send test traffic through SES while your production traffic flows through Pinpoint until you are confident enough to cut over.

What happens to my SMS and push campaigns?

SES does not handle SMS or push notifications. For SMS, you can use AWS End User Messaging or a third-party provider. For push, use Firebase Cloud Messaging or a similar service. If you migrate to CampaignHQ, they handle WhatsApp but SMS and push require additional integrations.

Do I need engineering resources to migrate?

It depends on your destination. Migrating to raw SES requires significant engineering work to rebuild journey logic, contact management, and analytics. Migrating to CampaignHQ requires minimal engineering since the platform provides those capabilities out of the box and their team offers migration support.

Written by CampaignHQ Team