Si tu app depende de Amazon Pinpoint para push y mensajería in-app, tienes una fecha límite dura y una migración incómoda por delante. El 30 de octubre de 2026, AWS termina el soporte de Amazon Pinpoint. Después de esa fecha, la consola y todo lo que construiste ahí (endpoints, segmentos, campañas, journeys y analítica) deja de ser accesible.
Para equipos en México, Colombia, Argentina o Chile que usaron Pinpoint como backend de push e in-app para su app de e-commerce o FinTech, el momento no podría ser peor: la fecha límite cae justo antes de Buen Fin, CyberMonday y la temporada de fin de año, las semanas de mayor volumen de notificaciones del año.
Pinpoint también dejó de aceptar nuevos registros el 20 de mayo de 2025, así que el servicio lleva tiempo con la cuenta regresiva corriendo. AWS detalla el cronograma completo en su guía oficial de fin de soporte.
El apagón es la parte fácil de entender. Lo incómodo es a dónde te manda AWS después, porque no existe un producto sucesor único. Según qué usabas de Pinpoint, tu carga de trabajo se reparte entre 4 servicios distintos de AWS. Y para las 2 cosas que más le importan a un equipo mobile, push e in-app, el camino recomendado no traslada nada de forma directa.
En esta guía: qué se apaga, a dónde te envía AWS cada pieza y por qué no es un reemplazo uno a uno, y un plan de 4 pasos para mover tu programa de push e in-app a Pushwoosh. Con números reales, para que puedas presupuestar la migración de verdad.
Qué se está apagando de verdad
Las APIs del canal de mensajería no desaparecen. Lo que desaparece es la capa de engagement, la parte donde entran tus equipos de marketing y producto.
Después del 30 de octubre de 2026, pierdes el acceso a tus recursos de Pinpoint: endpoints (tus registros de usuarios y dispositivos), segmentos (audiencias dinámicas), campañas (envíos programados), journeys (el constructor de automatización multi-paso) y los dashboards de analítica que trackeaban entregas, aperturas y engagement de journeys.
Lo que sobrevive, con otro nombre, es la capa cruda de canales. SMS, voz, push móvil, OTP y validación de números siguen funcionando a través de AWS End User Messaging, el nombre que AWS le dio a las APIs de canal de Pinpoint desde el Q3 de 2024. Así que si solo usabas Pinpoint como tubería tonta, con tu propio backend sosteniendo la lógica y llamando a la API para disparar un push transaccional, tienes menos de qué preocuparte: rediriges tus llamadas y sigues adelante.
Pero si tu equipo construyó audiencias, campañas y journeys dentro de la interfaz de Pinpoint, ese es el flujo que se rompe. Reconstruirlo dentro de AWS es donde empieza el trabajo real.
A dónde te manda AWS, y por qué no es un reemplazo 1:1
La propia guía de migración de AWS no te entrega un reemplazo. Te entrega 4, uno por capacidad:
- Engagement (endpoints, segmentos, campañas, journeys) → Amazon Connect outbound campaigns + Customer Profiles
- Eventos y analítica móvil → Amazon Kinesis
- Email → Amazon SES (Simple Email Service)
- SMS, push, voz, OTP → AWS End User Messaging
Sigue siendo un solo proveedor, técnicamente. Pero ahora son 4 productos separados, 4 consolas y 4 juegos de documentación reemplazando el único sistema que tenías. Para un equipo sin un grupo dedicado de plataforma, eso pesa mucho más de lo que suele implicar “migrar a otra herramienta”.
Y para equipos mobile, ese destino de engagement es donde se complica. Amazon Connect tiene huecos fáciles de pasar por alto hasta que ya estás a mitad de la migración.
- La mensajería in-app no está en Connect, punto. AWS lo dice directamente: la documentación de migración la lista entre las funciones no disponibles. Si el onboarding in-app, los prompts de features o los paywalls son parte de cómo funciona tu app, no hay un lugar nativo para ellos en el camino recomendado.
- El push no es un canal de campaña nativo. Push (GCM, APNS, Baidu y el resto) no está soportado nativamente en las campañas de Connect. La guía de AWS dice que puedes enviarlo igual, pero solo a través de un journey, con una acción Lambda conectada a plantillas de push de Connect. En la práctica significa que escribes y mantienes código solo para replicar lo que Pinpoint hacía de fábrica.
- Custom Channel está solo a medias. Está disponible en journeys pero no en campañas. Un parche más que Connect te deja resolver tú.
- Las plantillas comparten motor pero no sintaxis. Las plantillas de Connect usan el mismo motor de renderizado Handlebars que Pinpoint, así que tu lógica se traslada. Los placeholders de atributos, sin embargo, se escriben distinto: algo que en Pinpoint leía
{{User.UserAttributes.PurchaseHistory}}se convierte en{{Attributes.Customer.Attributes.PurchaseHistory}}en Connect. Cada plantilla hay que buscarla y reescribirla a mano. - Migrar endpoints es un trabajo de scripting. Para mover a tus usuarios, AWS te hace exportar un segmento sin filtro a S3 y luego correr un script en Python para transformar esos endpoints en Customer Profiles, donde un solo perfil tiene un límite de 3 emails y 4 números de teléfono. Funciona. También es código que escribes, pruebas y mantienes tú.
Nada de esto hace que el camino de AWS esté mal. Si ya estás totalmente comprometido con Connect para casos de contact-center, puede ser exactamente lo correcto para ti. Pero si push e in-app son la razón por la que estabas en Pinpoint desde el principio, la migración recomendada pone esos 2 canales directo en manos de tus ingenieros para reconstruirlos. Eso vale la pena saberlo antes de empezar, no 3 sprints después.
Mover tu programa de push e in-app a Pushwoosh en 4 pasos
Pushwoosh es una plataforma de engagement de clientes construida mobile-first: push, in-app y web push son los canales centrales, con email y SMS al lado. En lugar de dividir tu programa entre 4 servicios de AWS, lo reconstruyes una sola vez, en un solo lugar. Así va la migración.
-
Exporta tus datos de Pinpoint
Extrae tus endpoints, segmentos, campañas y definiciones de journeys usando las propias APIs de AWS mientras la consola sigue viva. Esperar hasta más cerca de la fecha límite solo hace más difícil la extracción, y vas a necesitar este export sin importar a dónde migres, así que hazlo temprano.
-
Redirige tus SDKs móviles
Cambia el SDK de Pinpoint o Amplify por el SDK de Pushwoosh, y confirma que los dispositivos se están registrando y los eventos fluyen antes de cortar nada de cara al usuario. Este es el paso que reconecta tu app a un backend de mensajería en vivo.
-
Reconstruye segmentos y journeys
Importa tus usuarios, mapea tus atributos de Pinpoint al modelo de tags y segmentación de Pushwoosh, y recrea tus automatizaciones en el Customer Journey Builder visual. Es trabajo equivalente: reimplementas una lógica que ya conoces en vez de diseñar desde cero. Esta es también la pieza exacta que, bajo el camino de Connect, terminaría en manos de tus ingenieros.
-
Reconecta eventos y luego pilotea
Vuelve a conectar tus eventos personalizados para que los triggers de comportamiento disparen, corre un envío piloto a un segmento pequeño para confirmar paridad, y recién entonces mueve el volumen completo. Deja tiempo de calendario real para autenticación de dominio y cualquier registro de remitente, porque nada de eso se acelera solo porque la fecha límite esté cerca.
La diferencia con la ruta de AWS se nota en los lugares aburridos. Donde la guía de AWS te hace escribir y correr un script en Python para transformar endpoints en Customer Profiles, Pushwoosh importa usuarios por interfaz o API, sin script que escribir ni mantener. Donde Connect te pide enrutar el push por un journey con Lambda, el push es simplemente un canal que eliges. La ingeniería que presupuestarías del lado de AWS mayormente se evapora.
Con Android dominando ~85%+ del parque de dispositivos en la región, vale la pena confirmar en el piloto que la entrega de push se mantiene estable incluso en conexiones intermitentes, algo que el SDK de Pushwoosh maneja de fábrica.
Cuánto cuesta
El precio es la parte que la mayoría de las guías de migración deja vaga, así que aquí está sin rodeos. Pushwoosh cobra por usuarios activos mensuales (MAU) — mira el desglose completo de precios — y para una carga de trabajo de push e in-app el punto de entrada es deliberadamente bajo:
- Push Only — $7 por 1,000 MAU. Si push e in-app son todo tu programa, este es el plan que le corresponde, sin el peso omnicanal que no vas a usar.
- Omnichannel — $13 por 1,000 MAU. Suma email, SMS y el resto del mix de canales cuando quieras todo bajo un mismo techo.
- Custom — desde $2,000/mes. Precios por volumen, soporte dedicado y términos enterprise para envíos más grandes.
Para un equipo de una startup o scaleup LATAM que principalmente necesita reemplazar el push y el in-app de Pinpoint, esa entrada de $7 pesa mucho menos que comprometerte con un plan pensado para Braze o CleverTap, cuyo pricing enterprise suele quedar fuera del alcance de un equipo en Serie A-C.
No esperes a octubre
La migración en sí es una cantidad conocida: exportar, redirigir, reconstruir, probar. El calendario es la restricción dura. El 30 de octubre de 2026 es un corte fijo, y los pasos que consumen tiempo real de reloj (corte de SDK, mapeo de eventos, configuración de dominio y remitente) corren a su propio ritmo sin importar qué tan cerca esté la fecha.
Puedes empezar con tus datos reales en un plan gratuito de 1,000 MAU, suficiente para importar un segmento real, reconstruir un journey y correr un envío piloto para ver la paridad por ti mismo antes de comprometerte con el corte completo. Nuestro consejo, después de ver correr suficientes de estas migraciones tarde: dimensiona contra tu MAU y calendario reales ahora, mientras la consola de Pinpoint sigue ahí para exportar. Los equipos que lo dejan para septiembre son los que descubren los huecos 3 semanas antes de que se apaguen las luces, justo cuando arranca Buen Fin.
