अगर आपका mobile app push और in-app messaging के लिए Amazon Pinpoint पर depend करता है, तो एक hard deadline आपके सामने है। 30 अक्टूबर 2026 को AWS, Amazon Pinpoint के लिए support बंद कर देगा। उसके बाद console और उसके अंदर बनाई गई हर चीज़ — endpoints, segments, campaigns, journeys, analytics — access से बाहर हो जाएगी।
Pinpoint ने 20 मई 2025 से नए sign-ups लेना पहले ही बंद कर दिया था, तो ये countdown नया नहीं है। AWS ने पूरी timeline अपने official end-of-support guide में दी है।
Shutdown समझना आसान है। मुश्किल हिस्सा ये है कि AWS आपको आगे कहाँ भेजता है — क्योंकि कोई single successor product नहीं है। आपने Pinpoint जिस भी काम के लिए इस्तेमाल किया, वो workload 4 अलग AWS services में बंट जाता है। और भारतीय mobile teams जिन 2 चीज़ों की सबसे ज़्यादा परवाह करती हैं — push और in-app — उनके लिए recommended path एक clean carry-over नहीं है।
इस guide में: क्या बंद हो रहा है, AWS हर हिस्से को कहाँ route करता है और ये like-for-like क्यों नहीं है, और आपके push-and-in-app program को Pushwoosh पर move करने का 4-step plan — असली numbers के साथ, ताकि आप budget बना सकें।
असल में क्या बंद हो रहा है
Messaging channel APIs कहीं नहीं जा रहे। जो गायब हो रहा है वो engagement layer है — वो हिस्सा जिसमें आपकी marketing और product टीमें log in करती हैं।
30 अक्टूबर 2026 के बाद आप अपने Pinpoint resources खो देंगे: endpoints (stored user और device records), segments (dynamic audiences), campaigns (scheduled sends), journeys (multi-step automation builder), और वो built-in analytics dashboards जो delivery, opens और journey engagement track करते थे।
जो अलग नाम से बचता है वो raw channel layer है। SMS, voice, mobile push, OTP, और phone number validation AWS End User Messaging के ज़रिए काम करते रहेंगे — यही वो नाम है जो AWS ने Q3 2024 में Pinpoint के channel APIs को दिया था। तो अगर आपने Pinpoint को सिर्फ एक dumb pipe की तरह इस्तेमाल किया, जहाँ आपका backend खुद logic रखता है और सिर्फ transactional push या text भेजने के लिए API call करता है, तो आपकी चिंता कम है। API calls re-point करें और आगे बढ़ें।
लेकिन अगर आपकी team ने Pinpoint UI के अंदर audiences, campaigns, और journeys बनाई हैं — जैसे कि FinTech ऐप्स में UPI transactional alerts के लिए journeys, या EdTech ऐप्स में course-completion reminder sequences — तो यही workflow टूटता है। इसे AWS के अंदर rebuild करना ही असली काम है।
AWS आपको कहाँ भेजता है, और ये 1:1 replacement क्यों नहीं है
AWS की अपनी migration guide एक replacement नहीं देती। वो 4 देती है, एक-एक capability के लिए:
- Engagement (endpoints, segments, campaigns, journeys) → Amazon Connect outbound campaigns + Customer Profiles
- Events और mobile analytics → Amazon Kinesis
- Email → Amazon SES (Simple Email Service)
- SMS, push, voice, OTP → AWS End User Messaging
Technically अभी भी 1 vendor है। लेकिन अब 4 अलग products, 4 consoles, और 4 sets के docs उस 1 system की जगह ले रहे हैं जो आपके पास था। बिना dedicated platform-engineering team वाली छोटी या mid-market टीम के लिए ये “नए tool पर migrate करो” से कहीं भारी काम है।
और mobile teams के लिए, वो engagement destination ही असली problem है। Amazon Connect में gaps हैं जो migration के बीच में ही पता चलते हैं।
- In-app messaging Connect में है ही नहीं। AWS खुद यही कहता है — migration docs इसे unavailable features में लिखकर list करते हैं। अगर आपके app में in-app onboarding, feature prompts, या paywalls चलते हैं, तो recommended path पर उनका कोई native घर नहीं है।
- Push एक native campaign channel नहीं है। Push (GCM, APNS, Baidu, बाकी सब) Connect campaigns में native support नहीं करता। AWS की guide कहती है कि आप फिर भी push भेज सकते हैं, लेकिन सिर्फ journey के ज़रिए, एक Lambda action से जो Connect push templates से wire होता है। मतलब आप वो code खुद लिखते और maintain करते हैं जो Pinpoint out-of-the-box देता था।
- Custom Channel सिर्फ आधा वहाँ है। ये journeys में available है लेकिन campaigns में नहीं। एक और seam जो Connect आपके ऊपर छोड़ देता है patch करने के लिए।
- Templates engine शेयर करते हैं, syntax नहीं। Connect templates Pinpoint जैसा ही Handlebars rendering engine इस्तेमाल करते हैं, तो logic carry over होता है। लेकिन attribute placeholders अलग तरीके से लिखे जाते हैं: जो Pinpoint में
{{User.UserAttributes.PurchaseHistory}}था वो Connect में{{Attributes.Customer.Attributes.PurchaseHistory}}बन जाता है। हर template हाथ से fetch और rewrite करना पड़ता है। - Endpoints migrate करना एक scripting job है। Users move करने के लिए AWS आपसे एक no-filter segment S3 में export करवाता है, फिर एक Python script चलवाता है जो endpoints को Customer Profiles के shape में ढालती है, जहाँ 1 profile की limit 3 email addresses और 4 phone numbers है। ये काम करता है। लेकिन ये code है जो आप लिखते, test करते, और own करते हैं।
इसका मतलब ये नहीं कि AWS path गलत है। अगर आप पहले से contact-center use cases के लिए Connect पर all-in हैं, तो शायद यही सही choice है। लेकिन अगर push और in-app ही वो वजह थे जिनके लिए आप Pinpoint पर थे, तो recommended migration वो 2 channels सीधे आपके engineers को rebuild करने के लिए दे देता है। ये वो हिस्सा है जो शुरू करने से पहले जानना ज़रूरी है, 3 sprints अंदर घुसने के बाद नहीं।
Push-and-in-app program को Pushwoosh पर 4 steps में move करना
Pushwoosh एक mobile-first customer engagement platform है: push, in-app, और web push core channels हैं, email और SMS साथ में। 4 AWS services में program बाँटने के बजाय, आप इसे एक बार, एक जगह rebuild करते हैं। Android-heavy user base के लिए यही सबसे सीधा रास्ता है, क्योंकि push delivery और in-app दोनों एक ही platform, एक ही SDK से चलते हैं। Migration ऐसे होगा:
-
Pinpoint data export करें
Console अभी live रहते हुए AWS की अपनी APIs से endpoints, segments, campaigns, और journey definitions निकाल लें। Deadline के पास तक wait करने से retrieval ही मुश्किल हो जाता है, और ये export आपको हर हाल में चाहिए होगा — इसलिए जल्दी कर लें।
-
Mobile SDKs re-point करें
Pinpoint या Amplify SDK को Pushwoosh SDK से swap करें, फिर कोई भी user-facing cutover करने से पहले confirm करें कि devices register हो रहे हैं और events flow कर रहे हैं। यही step आपके app को एक live messaging backend से दोबारा जोड़ता है।
-
Segments और journeys rebuild करें
Users import करें, अपने Pinpoint attributes को Pushwoosh के tag और segmentation model पर map करें, और visual journey builder में अपने automations recreate करें। ये like-for-like काम है — आप वो logic re-implement कर रहे हैं जो आप पहले से जानते हैं, scratch से design नहीं कर रहे। Connect path पर यही exact हिस्सा आपके engineers पर जाकर गिरता।
-
Events reconnect करें, फिर pilot चलाएं
अपने custom events दोबारा wire करें ताकि behavioral triggers fire हों, एक छोटे segment पर pilot send चलाकर parity confirm करें, और तभी full volume पर जाएं। Domain authentication और किसी भी sender registration के लिए असली calendar time छोड़ें — deadline पास होने से वो तेज़ नहीं होता।
AWS route से फर्क boring जगहों पर दिखता है। जहाँ AWS की guide आपसे endpoints को Customer Profiles के shape में ढालने के लिए Python script लिखवाती और चलवाती है, वहाँ Pushwoosh users को UI या API से import करता है — कोई script लिखने या maintain करने की ज़रूरत नहीं। जहाँ Connect push को Lambda-backed journey से route करवाता है, वहाँ push सिर्फ एक channel है जो आप pick करते हैं। AWS side पर जो engineering budget करनी पड़ती, वो ज़्यादातर evaporate हो जाती है।
कीमत क्या है
ज़्यादातर migration write-ups pricing को vague रखते हैं, तो यहाँ साफ़ बताते हैं। Pushwoosh monthly active users (MAU) पर bill करता है — पूरी pricing breakdown देखें — और push-and-in-app workload के लिए entry point जानबूझकर कम रखा गया है:
- Push Only — $7 प्रति 1,000 MAU। अगर push और in-app ही पूरा program है, तो यही tier उससे map होता है, बिना किसी omnichannel overhead के जिसका इस्तेमाल नहीं होगा।
- Omnichannel — $13 प्रति 1,000 MAU। पूरा channel mix एक ही जगह चाहिए तो email, SMS, और बाकी सब add करता है।
- Custom — $2,000/महीना से शुरू। बड़े sends के लिए volume pricing, dedicated support, और enterprise terms।
जिस team को मुख्यतः Pinpoint का push और in-app replace करना है, उसके लिए वो $7 entry पूरे marketing-automation suite को commit करने से कहीं कम friction वाला है — Braze, Customer.io, और Iterable के tier जो trade-off मांगता है, ठीक उसके उलट।
अक्टूबर का इंतज़ार मत करिए
Migration खुद एक known quantity है: export, re-point, rebuild, test। Calendar ही असली constraint है। 30 अक्टूबर 2026 एक fixed cutoff है, और जो steps असली wall-clock time खाते हैं (SDK cutover, event mapping, domain और sender setup) वो अपनी ही speed पर चलते हैं, चाहे date कितनी भी पास आ जाए।
आप अपने असली data के साथ 1,000 free MAU के tier से शुरू कर सकते हैं — इतना काफ़ी है कि एक real segment import करें, एक journey rebuild करें, और full cutover commit करने से पहले खुद parity देखें। हमारी सलाह, ऐसे कई migrations देर से भागते देखने के बाद: अभी अपने real MAU और timeline के हिसाब से scope करें, जब तक Pinpoint console export के लिए मौजूद है। जो teams इसे September तक टाल देती हैं, वही 3 हफ्ते पहले gaps discover करती हैं जब lights बंद होने वाली होती हैं।
