Wenn Ihre mobile App für Push- und In-App-Nachrichten auf Amazon Pinpoint setzt, steht Ihnen eine harte Frist und eine unübersichtliche Migration bevor. Am 30. Oktober 2026 stellt AWS den Support für Amazon Pinpoint ein. Danach sind Konsole und alles, was Sie darin aufgebaut haben – Endpoints, Segmente, Kampagnen, Journeys und Analytics – nicht mehr zugänglich.
Pinpoint hat außerdem bereits am 20. Mai 2025 die Neuanmeldungen eingestellt – der Countdown läuft also schon eine Weile. Den vollständigen Zeitplan hat AWS in seinem offiziellen End-of-Support-Leitfaden veröffentlicht.
Die Abschaltung selbst ist leicht zu verstehen. Kompliziert wird es bei der Frage, wohin AWS Sie als Nächstes schickt – denn es gibt kein einzelnes Nachfolgeprodukt. Je nachdem, wofür Sie Pinpoint genutzt haben, verteilt sich Ihr Workload auf 4 verschiedene AWS-Services. Und ausgerechnet für die 2 Dinge, die den meisten mobilen Teams am wichtigsten sind – Push und In-App –, ist der empfohlene Weg kein sauberer Übertrag.
In diesem Leitfaden: was abgeschaltet wird, wohin AWS die einzelnen Teile leitet und warum das kein 1:1-Ersatz ist, sowie ein 4-Schritte-Plan, um Ihr Push- und In-App-Programm stattdessen zu Pushwoosh zu migrieren. Mit echten Zahlen, damit Sie den Umzug tatsächlich budgetieren können.
Was am 30. Oktober tatsächlich abgeschaltet wird
Die Messaging-Channel-APIs verschwinden nicht. Was wegfällt, ist die Engagement-Ebene – der Teil, in den sich Ihr Marketing- und Produktteam einloggt.
Nach dem 30. Oktober 2026 verlieren Sie den Zugriff auf Ihre Pinpoint-Ressourcen: Endpoints (gespeicherte Nutzer- und Gerätedatensätze), Segmente (dynamische Zielgruppen), Kampagnen (geplante Sendungen), Journeys (der mehrstufige Automatisierungs-Builder) und die integrierten Analytics-Dashboards für Zustellung, Öffnungsraten und Journey-Engagement.
Was unter neuem Namen überlebt, ist die reine Channel-Ebene. SMS, Sprachnachrichten, mobile Push, OTP und Rufnummernvalidierung laufen über AWS End User Messaging weiter – so hat AWS Pinpoints Channel-APIs bereits im dritten Quartal 2024 umbenannt. Wer Pinpoint also nur als reine Zustellstrecke genutzt hat, bei der die eigene Backend-Logik die API lediglich zum Versenden einer transaktionalen Push- oder SMS-Nachricht aufruft, hat weniger zu befürchten: API-Endpunkt umbiegen, fertig.
Wer dagegen Zielgruppen, Kampagnen und Journeys direkt in der Pinpoint-Oberfläche aufgebaut hat, für den bricht genau dieser Workflow weg. Der Wiederaufbau innerhalb von AWS ist dort, wo die eigentliche Arbeit beginnt.
Wohin AWS Sie schickt – und warum es kein 1:1-Ersatz ist
Der Migrationsleitfaden von AWS liefert keinen Ersatz, sondern 4 – einen pro Funktionsbereich:
- Engagement (Endpoints, Segmente, Kampagnen, Journeys) → Amazon Connect Outbound Campaigns + Customer Profiles
- Events und Mobile Analytics → Amazon Kinesis
- E-Mail → Amazon SES (Simple Email Service)
- SMS, Push, Sprache, OTP → AWS End User Messaging
Technisch bleibt es 1 Anbieter. Praktisch sind es jetzt 4 separate Produkte, 4 Konsolen und 4 Dokumentationssätze für das eine System, das Sie vorher hatten. Für ein Team ohne dedizierte Platform-Engineering-Abteilung – wie sie viele Mittelstandsunternehmen im DACH-Raum gar nicht vorhalten – ist das ein deutlich schwererer Umzug, als „Wechsel auf ein neues Tool” normalerweise bedeutet.
Und für mobile Teams wird es genau an diesem Engagement-Ziel kompliziert. Amazon Connect hat Lücken, die leicht übersehen werden – bis man mitten in der Migration steckt.
- In-App-Nachrichten gibt es in Connect gar nicht. AWS schreibt das selbst so: Die Migrationsdokumentation listet In-App explizit unter den nicht verfügbaren Features. Wenn In-App-Onboarding, Feature-Hinweise oder Paywalls Teil Ihrer App sind, gibt es auf dem empfohlenen Weg keine native Heimat dafür. Für einen Automobilzulieferer mit einer Connected-Car-App, der Service-Erinnerungen und Fahrzeugstatus-Hinweise per In-App-Nachricht ausspielt, ist das keine Randnotiz, sondern eine fehlende Kernfunktion.
- Push ist kein nativer Kampagnen-Channel. Push (GCM, APNS, Baidu und der Rest) wird in Connect-Kampagnen nicht nativ unterstützt. Laut AWS-Leitfaden lässt sich Push zwar weiterhin versenden, aber nur über eine Journey mit einer Lambda-Aktion, die an Connect-Push-Templates angebunden ist. In der Praxis bedeutet das: Sie schreiben und pflegen Code, nur um nachzubauen, was Pinpoint von Haus aus konnte.
- Custom Channel ist nur zur Hälfte da. Verfügbar in Journeys, aber nicht in Kampagnen. Eine weitere Lücke in einem mobilen Stack, die Connect Ihnen zum Selbst-Flicken überlässt.
- Templates teilen sich die Engine, nicht die Syntax. Connect-Templates nutzen dieselbe Handlebars-Rendering-Engine wie Pinpoint, die Logik lässt sich also übertragen. Die Attribut-Platzhalter sind jedoch anders geschrieben: Was in Pinpoint
{{User.UserAttributes.PurchaseHistory}}hieß, wird in Connect zu{{Attributes.Customer.Attributes.PurchaseHistory}}. Jedes Template muss von Hand geholt und umgeschrieben werden. - Endpoints migrieren ist ein Scripting-Job. Um Ihre Nutzer zu verschieben, lässt AWS Sie ein ungefiltertes Segment nach S3 exportieren und anschließend per Python-Skript in Customer Profiles überführen – wo ein einzelnes Profil auf 3 E-Mail-Adressen und 4 Telefonnummern begrenzt ist. Es funktioniert. Es ist aber auch Code, den Sie schreiben, testen und pflegen müssen.
Nichts davon macht den AWS-Weg grundsätzlich falsch. Wer ohnehin voll auf Connect für Contact-Center-Anwendungsfälle setzt, für den kann er genau richtig sein. Aber wenn Push und In-App der Grund waren, warum Sie überhaupt auf Pinpoint waren, übergibt die empfohlene Migration diese 2 Channels direkt an Ihre Entwickler zum Wiederaufbau. Das sollten Sie vorher wissen, nicht erst 3 Sprints später.
In 4 Schritten zu Pushwoosh migrieren
Pushwoosh ist eine Customer-Engagement-Plattform, die mobile-first gebaut ist: Push, In-App und Web-Push sind die Kern-Channels, E-Mail und SMS ergänzen sie. Statt Ihr Programm auf 4 AWS-Services zu verteilen, bauen Sie es einmal auf, an einem Ort. So läuft die Migration ab.
-
Pinpoint-Daten exportieren
Ziehen Sie Ihre Endpoints, Segmente, Kampagnen und Journey-Definitionen über die eigenen APIs von AWS, solange die Konsole noch läuft. Wer bis kurz vor der Frist wartet, macht sich den Export nur schwerer – und Sie brauchen diesen Export ohnehin, egal wohin Sie wechseln. Also früh anfangen.
-
Mobile SDKs umstellen
Tauschen Sie das Pinpoint- oder Amplify-SDK gegen das Pushwoosh-SDK, und bestätigen Sie, dass Geräte sich registrieren und Events ankommen, bevor Sie etwas Nutzerseitiges umschalten. Dieser Schritt verbindet Ihre App wieder mit einem produktiven Messaging-Backend.
-
Segmente und Journeys neu aufbauen
Importieren Sie Ihre Nutzer, bilden Sie Ihre Pinpoint-Attribute auf das Tag- und Segmentierungsmodell von Pushwoosh ab und bauen Sie Ihre Automatisierungen im visuellen Journey Builder neu auf. Das ist 1:1-Arbeit: Sie implementieren eine Logik neu, die Sie bereits kennen, statt von null zu entwerfen. Genau dieser Teil würde beim Connect-Weg sonst bei Ihren Entwicklern landen.
-
Events wieder verbinden, dann pilotieren
Verdrahten Sie Ihre Custom Events neu, damit verhaltensbasierte Trigger auslösen, führen Sie einen Pilotversand an ein kleines Segment durch, um die Parität zu bestätigen, und wechseln Sie erst danach auf volles Volumen. Planen Sie echte Kalenderzeit für Domain-Authentifizierung und jede Art von Absenderregistrierung ein – das lässt sich nicht beschleunigen, nur weil die Frist näher rückt.
Der Unterschied zum AWS-Weg zeigt sich an den unscheinbaren Stellen. Wo der AWS-Leitfaden Sie ein Python-Skript schreiben und ausführen lässt, um Endpoints in Customer Profiles umzuformen, importiert Pushwoosh Nutzer über Oberfläche oder API – ohne Skript, das Sie schreiben und pflegen müssen. Wo Connect Push über eine Lambda-gestützte Journey routen lässt, ist Push bei Pushwoosh einfach ein Channel, den Sie auswählen. Der Engineering-Aufwand, den Sie auf der AWS-Seite einplanen müssten, entfällt größtenteils.
Was es kostet
Preise sind der Teil, den die meisten Migrations-Guides bewusst vage lassen – hier also ganz konkret. Pushwoosh rechnet nach Monthly Active Users (MAU) ab – die vollständige Preisübersicht finden Sie hier –, und für ein reines Push-und-In-App-Programm ist der Einstiegspreis bewusst niedrig angesetzt:
- Push Only – 7 $ pro 1.000 MAU. Wenn Push und In-App das gesamte Programm sind, ist das der Tarif dafür – ohne Omnichannel-Overhead, den Sie nicht nutzen.
- Omnichannel – 13 $ pro 1.000 MAU. Ergänzt E-Mail, SMS und den Rest des Channel-Mix, wenn Sie alles unter einem Dach wollen.
- Custom – ab 2.000 $/Monat. Volumenpreise, dedizierter Support und Enterprise-Konditionen für größere Sendevolumen.
Für ein Team, das im Kern Pinpoints Push und In-App ersetzen muss, ist dieser Einstieg bei 7 $ deutlich weniger Reibung, als sich auf eine vollständige Marketing-Automatisierungs-Suite festzulegen. Genau diesen Kompromiss verlangt der Tarif von Braze, Customer.io und Iterable.
Nicht bis Oktober warten
Die Migration selbst ist eine bekannte Größe: exportieren, umstellen, neu aufbauen, testen. Der Kalender ist die harte Grenze. Der 30. Oktober 2026 ist ein fester Stichtag, und die Schritte, die echte Kalenderzeit kosten (SDK-Umstellung, Event-Mapping, Domain- und Absender-Setup), laufen in ihrem eigenen Tempo – egal, wie nah der Termin rückt.
Sie können mit Ihren echten Daten auf einer kostenlosen Stufe mit 1.000 MAU starten – genug, um ein echtes Segment zu importieren, eine Journey neu aufzubauen und einen Pilotversand zu fahren, um die Parität selbst zu prüfen, bevor Sie sich für den vollständigen Wechsel entscheiden. Unser Rat, nachdem wir genug solcher Migrationen zu spät haben laufen sehen: Planen Sie jetzt anhand Ihrer echten MAU-Zahl und Ihres Zeitplans, solange die Pinpoint-Konsole noch für den Export bereitsteht. Die Teams, die es bis September liegen lassen, sind die, die die Lücken 3 Wochen vor Abschaltung entdecken.
