Amazon SES provides email infrastructure. Amazon Pinpoint’s engagement features reach end of support on October 30, 2026. CampaignHQ provides a marketer-facing platform supporting Email, WhatsApp, SMS and RCS. Choose by who will own audiences, journeys, approvals and reporting, not by whether each service can send a message to a customer.

Last updated: October 14, 2026

For a marketing or CRM team moving off Pinpoint, the hard question is what happens between receiving a customer event and sending the right message. Someone must maintain the audience rules, stop messages after a conversion, honor opt-outs and explain the results. A sending API solves only part of that job.

AWS’s official AWS migration guidance separates engagement features from messaging channels. Pinpoint stopped accepting new customers on May 20, 2025. After October 30, 2026, its console and engagement resources, including endpoints, segments, campaigns, journeys and analytics, will no longer be accessible.

This comparison helps you choose an operating model. For the detailed work, use the deadline and end-of-support guide, the Pinpoint to SES technical migration guide, or the broader Pinpoint replacements and alternatives shortlist.

Quick comparison: choose the owner of the work

• Amazon SES: consider it when your application needs email sending and your engineering team will own the surrounding customer-engagement system. SES is an email service, not a replacement for every Pinpoint journey.
• Amazon Pinpoint: treat it as the source system to migrate from, not a new long-term investment. Identify which workloads use its engagement resources and which use channel APIs that continue elsewhere in AWS.
• CampaignHQ: evaluate it when marketing needs a workspace for campaigns, audiences, automation and reporting. Its product channels include Email, WhatsApp, SMS and RCS. Validate your required workflow and channel configuration before committing.

The choice is not simply AWS versus non-AWS. A managed engagement platform can use AWS infrastructure while changing who operates campaigns. Likewise, staying with AWS messaging services does not require rebuilding every capability from scratch: AWS also documents an engagement migration path through Amazon Connect.

Amazon SES: when an engineering-owned stack fits

Amazon SES supports marketing and transactional email, including newsletters and order confirmations. Applications can send through its API or SMTP interface. AWS also documents authentication, sending-event publishing and access controls.

Do not dismiss SES as having no contact or reporting capabilities. It has contact-list and topic management, subscription features and sending-event tools. The real evaluation question is whether those building blocks give your marketing team the workflow it needs, or whether engineers must assemble and maintain that workflow.

Choose this route when

• Your application already controls audience selection and message triggers.
• Engineers can maintain integrations, retries, consent rules and operational monitoring.
• You need custom behavior that is important enough to justify owning it.
• Marketing has a workable way to review content and change campaigns without creating an unmanageable ticket queue.

Ask the engineering owner to demonstrate a routine campaign change. Can a marketer change a segment, preview recipients, review a template and stop an unsuitable send? If the answer involves several custom systems, include their maintenance and support in the decision.

Compare total operating work, not a sending rate

List the work your team will retain: event integration, audience updates, template review, suppression handling, campaign scheduling, reporting and incident response. Then name the person responsible for each task. There is no useful universal estimate for how many months this will take; an existing internal platform and a new build are different projects.

SES does not itself become an SMS or WhatsApp platform. If your journey needs other channels, evaluate the relevant services and the orchestration between them. Keep your email requirements separate from your cross-channel requirements so neither gets lost in a low-level API comparison.

Amazon Pinpoint: separate retirement from channel continuity

Pinpoint’s end of support is not an instruction to abandon every AWS messaging service. AWS recommends SES for email and Amazon Connect’s proactive engagement solutions for engagement workloads. Its migration guidance says APIs related to SMS, voice, mobile push, OTP and phone-number validation are not affected by this change and are supported by AWS End User Messaging.

That distinction changes the migration plan. A team using a channel API directly has a different problem from a team using Pinpoint segments and journeys to decide who receives a message. A continuing delivery API does not preserve the retiring audience and campaign layer.

Inventory the dependencies before selecting a destination

1. Engagement: list active segments, journey conditions, schedules and message templates.
2. Delivery: identify the actual API, sending region, identities and channel resources used by each workload.
3. Data: record where customer attributes, events, consent and suppressions originate.
4. Reporting: decide which history must remain available after the console is gone.

Keep this inventory focused on the business workflows that must continue. An onboarding sequence needs entry rules, timing, exit rules and opt-out behavior, not just an exported email template. Detailed export and implementation steps belong in your technical migration plan.

CampaignHQ: when marketers need the operating layer

CampaignHQ is a customer-engagement platform and Meta Business Partner. It supports Email, WhatsApp, SMS and RCS. Email + WhatsApp journeys remain a useful starting point for retention teams, but they are not the platform’s complete channel scope. AWS infrastructure supports the platform; it is not the main reason to choose a marketing workspace.

The CampaignHQ migration offering covers assessment, planning and rebuilding engagement workflows. It explicitly avoids presenting the product as a one-to-one clone of every Pinpoint API. AWS-account alignment depends on the customer configuration, so verify your account, region and access requirements during evaluation.

Bring a real workflow to the demo

For example, bring an onboarding journey you already run. Ask the team to show how a customer enters, how an audience is selected, where a marketer reviews the message, and what stops follow-ups after the customer completes onboarding. Treat this as a demonstration requirement, not an assumption that every branch transfers unchanged.

• Audience ownership: who imports or updates customer data, and how are consent and suppression records handled?
• Channel fit: which steps use email, WhatsApp, SMS or RCS, and which account-specific prerequisites apply?
• Operator control: who can edit, approve, launch and stop the workflow?
• Delivery support: which issues does CampaignHQ handle, and which require your engineers or an upstream provider?
• Reporting: can the team distinguish messages sent from the customer action the journey is meant to produce?

CampaignHQ’s SMS product page describes campaigns, segmentation and triggered messaging. For RCS, confirm the formats, destinations, onboarding and billing that apply to your account. Product-level channel support is not a promise of every carrier, device, integration or automatic fallback path.

If push, in-app messaging or a specialized application workflow is essential, list it explicitly and ask how it would be handled. Do not infer support from the phrase “multichannel,” or reject CampaignHQ on the outdated premise that it supports only email and WhatsApp.

Decision framework: test continuity before cutover

Choose an SES-centered stack when the engineering ownership is deliberate and sustainable. Shortlist CampaignHQ when marketer self-service and accountable workflow support matter more than maintaining your own campaign layer. Evaluate Amazon Connect when its engagement model fits your AWS operating requirements. Pinpoint itself is the migration source, not the destination.

Before signing off, require a test that covers an eligible recipient, an opted-out recipient, a failed delivery and a customer who completes the desired action before the next message. Agree on acceptance criteria, a rollback decision and responsibility for incidents. Do not let both systems send the same live journey merely to prove that they work in parallel.

Delivery continuity also needs its own plan. Keeping a sending domain does not guarantee unchanged inbox placement. AWS explains that new dedicated IP addresses need warming. Review identities, authentication, sending history and volume changes with the delivery owner rather than assuming reputation transfers with a platform switch.

Use the retention-platform migration checklist to turn these requirements into an evaluation brief. Compare implementation work and ongoing responsibilities alongside subscription and delivery usage. A lower sending rate alone does not settle the operating-model decision.

Frequently asked questions

Can SES replace all of Amazon Pinpoint?

No. SES can provide email delivery and related capabilities, but moving email does not recreate Pinpoint endpoints, segments, journeys and analytics. Map those workloads separately to your chosen engagement platform or AWS architecture.

Can we keep transactional email on SES and use CampaignHQ for marketing?

Evaluate that split with both operating teams. Confirm sending identities, suppression updates, event flows and reporting boundaries. The important test is whether the two systems respect customer preferences and avoid duplicate sends, not whether they share an infrastructure provider.

Does CampaignHQ support SMS and RCS as well as email and WhatsApp?

Yes. Those are supported product channels. Validate the specific channel setup and workflow you need; do not assume every channel has identical features, coverage or billing. A four-channel platform description is not a guarantee of automatic fallback between channels.

Will our IAM roles and journey logic transfer unchanged?

Do not assume so. Review permissions and integrations against the destination configuration. Rebuild and test journey behavior, including entry, exit, timing and consent rules. A migration offering is not proof of drop-in API or security-policy compatibility.

How long should we allow for migration?

Scope it from your dependencies rather than a generic timeline. Data quality, integrations, channel approvals, reporting history and delivery testing affect the work. Ask for a staged plan with named owners and tested milestones before agreeing to a cutover date.

Supporting reading

For operational detail, use the AWS SES dos and don’ts and email and WhatsApp marketing guides. Refer to the Amazon SES documentation and Amazon Pinpoint documentation for service-specific implementation details.

Written by CampaignHQ Team