Se o seu app depende do Amazon Pinpoint para notificações push e mensagens in-app, você tem um prazo fixo e uma migração nada trivial pela frente. Em 30 de outubro de 2026, a AWS encerra o suporte ao Amazon Pinpoint. Depois dessa data, o console e tudo que você construiu nele — endpoints, segmentos, campanhas, jornadas e analytics — deixa de estar acessível.
O Pinpoint também parou de aceitar novos cadastros em 20 de maio de 2025, então o serviço já vinha nessa contagem regressiva há um tempo. A AWS detalha o cronograma completo no guia oficial de fim de suporte.
Para o mercado brasileiro, esse prazo pega mal timing: cai um mês antes da Black Friday, o maior evento de e-commerce do país. Se o seu app está no varejo, delivery ou fintech e usa push e in-app para campanhas sazonais, você não vai querer estar no meio dessa migração quando as campanhas de novembro começarem a ser montadas.
O desligamento em si é fácil de entender. A parte incômoda é para onde a AWS te manda depois, porque não existe um produto substituto único. Dependendo do que você usava no Pinpoint, sua carga de trabalho é dividida entre 4 serviços diferentes da AWS. E para as 2 coisas que a maioria dos times mobile mais usa — push e in-app — o caminho recomendado não migra de forma direta.
Neste guia: o que é desligado, para onde a AWS direciona cada parte e por que não é uma troca 1:1, e um plano de 4 passos para mover seu programa de push e in-app para a Pushwoosh. Com números reais, para você conseguir orçar a migração de verdade.
O que realmente vai parar de funcionar
As APIs do canal de mensageria não vão desaparecer. O que some é a camada de engajamento — a parte em que seu time de marketing e produto faz login.
Depois de 30 de outubro de 2026, você perde o acesso aos recursos do Pinpoint: endpoints (seus registros de usuários e dispositivos), segmentos (audiências dinâmicas), campanhas (envios agendados), jornadas (o construtor de automação multi-etapas) e os dashboards nativos de analytics que rastreavam entregas, aberturas e engajamento nas jornadas.
O que sobrevive, com outro nome, é a camada bruta de canais. SMS, voz, push mobile, OTP e validação de número de telefone continuam funcionando através do AWS End User Messaging, nome que a AWS deu às APIs de canal do Pinpoint lá no Q3 de 2024. Então, se você só usava o Pinpoint como um “cano burro” — onde seu próprio backend guarda a lógica e só chama a API para disparar um push ou SMS transacional (por exemplo, confirmação de pagamento via PIX) — você tem menos com que se preocupar. Só reaponta as chamadas de API e segue em frente.
Mas se o seu time construiu audiências, campanhas e jornadas dentro da interface do Pinpoint, é esse fluxo de trabalho que quebra. Reconstruir isso dentro da AWS é onde o trabalho de verdade começa.
Para onde a AWS te manda, e por que não é uma substituição 1:1
O próprio guia de migração da AWS não te entrega um substituto. Ele te entrega 4, um para cada capacidade:
- Engajamento (endpoints, segmentos, campanhas, jornadas) → Amazon Connect outbound campaigns + Customer Profiles
- Eventos e analytics mobile → Amazon Kinesis
- Email → Amazon SES (Simple Email Service)
- SMS, push, voz, OTP → AWS End User Messaging
Tecnicamente, ainda é um único fornecedor. Mas agora são 4 produtos separados, 4 consoles e 4 conjuntos de documentação no lugar do sistema único que você tinha. Para um time sem uma área dedicada de platform engineering, isso é um esforço bem maior do que “migrar para uma ferramenta nova” costuma significar.
E para times mobile, esse destino de engajamento é onde a coisa complica. O Amazon Connect tem lacunas fáceis de não perceber até você já estar no meio da migração.
- Mensagens in-app não existem no Connect. A própria AWS diz isso: a documentação de migração lista in-app entre os recursos indisponíveis, por escrito. Se onboarding in-app, prompts de funcionalidade ou paywalls fazem parte de como seu app funciona, não existe um lar nativo para eles no caminho recomendado.
- Push não é um canal de campanha nativo. Push (GCM, APNS, Baidu e o resto) não é suportado nativamente nas campanhas do Connect. O guia da AWS diz que ainda dá para enviar, mas só através de uma jornada, usando uma ação Lambda ligada a templates de push do Connect. Na prática, isso significa escrever e manter código só para replicar o que o Pinpoint fazia de fábrica.
- Custom Channel só existe pela metade. Está disponível em jornadas, mas não em campanhas. Mais uma costura que o Connect deixa para você mesmo remendar num stack mobile.
- Os templates compartilham o motor, mas não a sintaxe. Os templates do Connect usam o mesmo motor de renderização Handlebars do Pinpoint, então a lógica se mantém. Mas os placeholders de atributo mudam: algo que era
{{User.UserAttributes.PurchaseHistory}}no Pinpoint vira{{Attributes.Customer.Attributes.PurchaseHistory}}no Connect. Cada template precisa ser buscado e reescrito na mão. - Migrar endpoints é trabalho de script. Para mover seus usuários, a AWS pede para exportar um segmento sem filtro para o S3 e depois rodar um script Python para transformar esses endpoints em Customer Profiles, onde cada perfil tem limite de 3 emails e 4 telefones. Funciona. Mas é código que você escreve, testa e mantém.
Nada disso torna o caminho da AWS errado. Se você já está todo comprometido com o Connect para casos de uso de contact center, pode ser exatamente certo para você. Mas se push e in-app são o motivo pelo qual você estava no Pinpoint desde o início, a migração recomendada entrega esses 2 canais direto para seus engenheiros reconstruírem. Isso vale saber antes de começar, não 3 sprints depois.
Como migrar seu programa de push e in-app para a Pushwoosh em 4 passos
A Pushwoosh é uma plataforma de engajamento de clientes construída mobile-first: push, in-app e web push são os canais principais, com email e SMS ao lado. Em vez de dividir seu programa entre 4 serviços da AWS, você reconstrói tudo de uma vez, num só lugar. É assim que a migração acontece.
-
Exporte os dados do Pinpoint
Puxe seus endpoints, segmentos, campanhas e definições de jornada usando as próprias APIs da AWS enquanto o console ainda está no ar. Esperar até mais perto do prazo só torna a extração mais difícil, e você vai precisar disso exportado independentemente de para onde for, então faça isso cedo.
-
Reaponte seus SDKs mobile
Troque o SDK do Pinpoint ou do Amplify pelo SDK da Pushwoosh, depois confirme que os dispositivos estão se registrando e que os eventos estão fluindo antes de cortar qualquer coisa visível ao usuário. É esse passo que reconecta seu app a um backend de mensageria ativo.
-
Reconstrua segmentos e jornadas
Importe seus usuários, mapeie os atributos do Pinpoint para o modelo de tags e segmentação da Pushwoosh, e recrie suas automações no construtor visual de jornadas. É um trabalho equivalente: você está reimplementando uma lógica que já conhece, não desenhando do zero. Essa também é exatamente a parte que, no caminho do Connect, sobraria para seus engenheiros.
-
Reconecte eventos e rode um piloto
Reative seus eventos customizados para que os gatilhos comportamentais disparem, faça um envio piloto para um segmento pequeno para confirmar a paridade, e só depois mova o volume total. Reserve tempo real de calendário para autenticação de domínio e qualquer registro de remetente, porque nada disso acelera só porque o prazo está perto.
A diferença em relação à rota da AWS aparece nos detalhes chatos. Onde o guia da AWS te faz escrever e rodar um script Python para transformar endpoints em Customer Profiles, a Pushwoosh importa usuários pela interface ou pela API, sem script para escrever e manter. Onde o Connect pede para você rotear push através de uma jornada com Lambda, push é só um canal que você escolhe. A engenharia que você orçaria do lado da AWS praticamente evapora.
Quanto custa
Preço é a parte que a maioria dos guias de migração deixa vaga, então aqui está sem rodeios. A Pushwoosh cobra por usuários ativos mensais (MAU) — veja o detalhamento completo de preços — e para uma carga de push e in-app, o ponto de entrada é propositalmente baixo:
- Push Only — US$ 7 por 1.000 MAU. Se push e in-app são todo o programa, esse é o plano que corresponde a isso, sem custo extra de omnichannel que você não vai usar.
- Omnichannel — US$ 13 por 1.000 MAU. Adiciona email, SMS e o resto do mix de canais quando você quer tudo debaixo do mesmo teto.
- Custom — a partir de US$ 2.000/mês. Preço por volume, suporte dedicado e termos enterprise para envios maiores.
Para startups e scaleups brasileiras em fase de crescimento, esse preço por MAU escala junto com o negócio em vez de exigir um contrato fechado desde o primeiro dia — e, como o Brasil é um mercado dominado por Android (mais de 85% dos smartphones), o plano de entrada já cobre exatamente o cenário mais comum por aqui. Para um time que precisa basicamente substituir o push e o in-app do Pinpoint, esse ponto de entrada de US$ 7 é bem menos fricção do que se comprometer com uma suíte completa de automação de marketing.
Não espere até outubro
A migração em si é uma incógnita conhecida: exportar, reapontar, reconstruir, testar. O calendário é a restrição de verdade. 30 de outubro de 2026 é um corte fixo, e as etapas que consomem tempo de calendário de verdade (troca de SDK, mapeamento de eventos, configuração de domínio e remetente) andam no próprio ritmo, não importa o quão perto o prazo esteja.
Você pode começar com seus dados reais num plano gratuito de 1.000 MAU, suficiente para importar um segmento de verdade, reconstruir uma jornada e rodar um envio piloto para ver a paridade com seus próprios olhos antes de se comprometer com uma virada completa. Nosso conselho, depois de ver o suficiente desses processos atrasarem: dimensione contra seu MAU e cronograma reais agora, enquanto o console do Pinpoint ainda está de pé para exportar. Os times que deixam para setembro são os que descobrem as lacunas 3 semanas antes de as luzes apagarem — e, no Brasil, isso é 3 semanas antes da Black Friday.
