¿Migrando desde OneSignal? 9 herramientas para una migración segura del SDK de push en apps grandes

En una app pequeña, migrar el SDK de OneSignal significa cambiar 1 llamada de inicialización y un click handler. En una app grande, OneSignal está en decenas de lugares: tags que se asignan en el módulo de perfil, un external user ID en la autenticación, click handlers en la navegación, triggers in-app en algún punto del checkout.

Si se te escapa 1 de esas llamadas, nada se rompe. Los segmentos se desvían en silencio, los deep links abren la pantalla de inicio y el push que hacía volver a los usuarios deja de llegar. En una app de e-commerce o FinTech en LATAM, si eso pasa justo antes de Hot Sale o Buen Fin, se nota en los ingresos.

Esta guía reúne 9 herramientas que hacen segura la migración, agrupadas en los 5 pasos de una migración: mapear, reemplazar, probar, lanzar y monitorear.

Para la parte del proveedor, consulta nuestra guía completa de migración de OneSignal a Pushwoosh.

Por qué las migraciones de SDK de push fallan en apps grandes

Un SDK de push toca más partes del código que la mayoría de las librerías de terceros. Normalmente fallan 4 cosas:

• Llamadas dispersas. Tags, external user IDs y click handlers viven en módulos distintos, a veces en repositorios distintos. Una búsqueda de texto de “OneSignal” encuentra las llamadas obvias y se salta los wrappers.
• Dependencias ocultas. Eventos de analítica, deep links y pruebas A/B suelen colgar de callbacks del SDK. Quitas el callback y un dashboard más adelante se queda plano.
• 2 SDKs, 1 build. 2 SDKs de push en 1 app compiten por los mismos callbacks de notificaciones. Por eso la guía de migración de Pushwoosh indica quitar el SDK de OneSignal en el mismo release que agrega el nuevo.
• Fallas silenciosas. Un push no entregado no lanza ningún error. Los reportes de crashes siguen limpios.

El flujo de migración, paso a paso

Cada paso tiene su propio modo de fallar y sus propias herramientas.

9 herramientas para una migración segura del SDK de OneSignal

Paso 1. Mapea cada llamada a OneSignal

1. CodeAlive: ideal para mapear llamadas del SDK en codebases grandes y multi-repo

CodeAlive da a los agentes de IA para programación un contexto preciso de todo el codebase y reduce los tokens que gastan buscándolo. Es un motor de contexto pensado para codebases de más de 1M de líneas: búsqueda semántica más un grafo de relaciones entre archivos, símbolos, llamadas, dependencias y tests, servido por MCP y API.

Qué hace en la migración: antes de que alguien edite el código, le preguntas a CodeAlive dónde se usa OneSignal y qué depende de él. El grafo de relaciones muestra llamadas más allá de las obvias: wrappers, callbacks de los que cuelga la analítica, tests que mockean el SDK. El mismo contexto llega al agente de IA que hace el reemplazo.

Funcionalidades clave:

• Recuperación híbrida: búsqueda semántica, coincidencia léxica y recorrido del grafo en 1 sola consulta
• Índice actualizado en cada push, así el mapa sigue al día mientras avanza la rama de migración
• Herramientas MCP, incluidas semantic_search, grep_search y chat, para Cursor, Claude Code, Codex, Windsurf, Zed, Continue y Cline
• Revisión de pull requests con IA que toma en cuenta todo el sistema
• Proveedores de Git: GitHub, GitLab, Bitbucket, Azure DevOps, Gitea. IDEs: VS Code y JetBrains

Ventajas:

Paso 2. Reemplaza el SDK y mueve la audiencia

2. Pushwoosh: ideal como plataforma de destino con importación de audiencia

Pushwoosh es una plataforma de engagement de clientes con push, in-app, email, SMS y WhatsApp. En una migración, el equipo de Pushwoosh importa tu audiencia mientras tus desarrolladores publican el nuevo SDK.

Qué hace en la migración: los tokens de push de iOS, Android y Huawei se importan y siguen funcionando, porque los tokens pertenecen a tu app y a tus llaves. Los suscriptores de email y SMS también pasan en la importación. El external_user_id se mapea al User ID de Pushwoosh (pide esa columna en tu exportación de OneSignal, no viene en la exportación por defecto), y los tags se recrean a partir de tu exportación. El web push es la excepción: ningún proveedor puede transferir suscripciones del navegador, así que el Web SDK de Pushwoosh vuelve a suscribir a los visitantes de forma silenciosa.

Funcionalidades clave:

• SDKs para iOS y Android, además de React Native, Flutter, Unity, Capacitor, Cordova, MAUI, Expo y más
• Importación de audiencia que corre en paralelo al release del SDK, así los dispositivos son alcanzables antes de que los usuarios actualicen
• Dispositivos de prueba para previsualizar pushes en un dispositivo real antes de enviar

Ventajas:

Precios: el plan solo push cuesta $7 por cada 1,000 MAU, con los primeros 1,000 MAU gratis. Compara tu factura actual con la calculadora de costos de OneSignal.

Paso 3. Prueba el registro y la entrega

3. Apple Push Notifications Console: ideal para probar la entrega en iOS por APNs

Push Notifications Console es la herramienta web de Apple para enviar notificaciones de prueba por APNs. Es una forma rápida de descartar al proveedor cuando un push de iOS no llega.

Qué hace en la migración: envías un push directo a un token de dispositivo y revisas si APNs lo aceptó y lo entregó. Si llega desde aquí pero no desde tu nuevo proveedor, revisa primero la configuración del proveedor.

Funcionalidades clave:

• Notificaciones de prueba a un dispositivo, con reenvío después de cambiar atributos
• Logs de entrega que muestran el recorrido de una notificación por APNs, para el entorno de desarrollo
• Validación de tokens para un entorno y tipo de push específicos
• Métricas de entrega para notificaciones de prueba y de producción

Ventajas:

4. Firebase Cloud Messaging: ideal para probar pushes de Android por token

Los pushes de Android en dispositivos con Google Play services pasan por Firebase Cloud Messaging (los dispositivos Huawei sin Google services usan HMS Push Kit); en LATAM, donde Android supera el 85% del mercado, es el canal que más vas a probar. La consola de Firebase puede enviar un mensaje de prueba a 1 token de registro, lo que la convierte en un tester de notificaciones push sencillo para builds de Android.

Qué hace en la migración: después de que el nuevo SDK registra un dispositivo, pegas su token FCM en la consola y envías una prueba. Si llega, el token y la configuración de Firebase están bien.

Funcionalidades clave:

• Envío de mensaje de prueba a un token de registro FCM específico desde la consola
• Sin código para una revisión rápida, más allá de leer el token del dispositivo

Ventajas:

5. Proxyman: ideal para inspeccionar el tráfico y los payloads del SDK

Proxyman es un proxy de depuración HTTP para macOS, Windows y Linux. Muestra lo que el SDK de push realmente envía: llamadas de registro, actualizaciones de user ID, solicitudes de tags.

Qué hace en la migración: ejecutas la app con el nuevo SDK y observas sus solicitudes. Si un tag nunca sale del dispositivo, lo ves aquí, mucho antes de que un segmento salga vacío.

Funcionalidades clave:

• Captura de tráfico HTTPS de apps en dispositivos, simuladores y emuladores
• Captura en un clic de iOS Simulator y Android Emulator en los planes pagos
• Breakpoints y Map Local/Remote para editar solicitudes y respuestas

Paso 4. Lanza por etapas

6. fastlane: ideal para automatizar releases por etapas

fastlane es una plataforma open source para automatizar el despliegue en iOS y Android. Para una migración, su valor está en 2 parámetros que puedes incluir en el script de tu release lane.

Qué hace en la migración: upload_to_app_store acepta phased_release: true, que publica la actualización a lo largo de 7 días. upload_to_play_store acepta un valor de rollout, la fracción de usuarios que recibe el build (0.1 para 10%; 1 completa el rollout). El release de la migración sigue siempre el mismo camino por etapas, y nadie olvida marcar la casilla.

Funcionalidades clave:

• deliver / upload_to_app_store con phased_release
• supply / upload_to_play_store con rollout y release_status (incluido halted)
• 1 sola lane para ambas tiendas

Ventajas:

7. Phased release de App Store y staged rollouts de Google Play: ideal para limitar el impacto

Ambas tiendas pueden publicar una actualización primero para una parte de tus usuarios. Sin importar qué herramientas de release uses, esta es la red de seguridad para cambiar el SDK de push.

Qué hace en la migración: el nuevo build con Pushwoosh llega a una pequeña parte de los usuarios. Si las entregas o la tasa de crashes se ven mal, detienes el rollout antes de que llegue a todos. Mientras tanto, OneSignal sigue enviando a los usuarios que no han actualizado, así nadie se pierde una campaña.

Funcionalidades clave:

• App Store: publica a lo largo de 7 días al 1%, 2%, 5%, 10%, 20%, 50% y luego al 100% de los usuarios con actualizaciones automáticas. Puedes pausar hasta 30 días en total o publicar para todos en cualquier momento
• Google Play: defines el porcentaje y lo subes manualmente. Puedes detener y reanudar el rollout, y los usuarios que ya actualizaron conservan el build
• Muestreo aleatorio de usuarios en ambas tiendas

Ventajas:

Paso 5. Monitorea crashes y entregas

8. Firebase Crashlytics: ideal para detectar crashes después del cambio

Firebase Crashlytics reporta crashes y errores no fatales de apps Android, Apple, Flutter y Unity. Mantenlo activo durante todo el rollout y compara el build nuevo con el anterior.

Qué hace en la migración: un crash en un handler de notificaciones o durante la inicialización del SDK aparece aquí primero. Los eventos no fatales ayudan con los problemas más silenciosos: registra un evento no fatal cuando falla el registro de push, y lo verás por build.

Funcionalidades clave:

• Reportes de crashes agrupados en issues, filtrables por build
• Eventos no fatales, registrados en el dispositivo y enviados en el siguiente inicio de la app
• SDKs oficiales para Android, Apple, Flutter y Unity

9. Estadísticas de mensajes de Pushwoosh: ideal para detectar caídas silenciosas en la entrega

Los reportes de crashes no te van a decir que los pushes dejaron de llegar. Las estadísticas de push de Pushwoosh sí.

Qué hace en la migración: para cada push ves el funnel desde la audiencia hasta los envíos, las entregas y las aperturas, por plataforma, además de una pestaña separada de errores. Compara las primeras campañas después del cambio con tus números de OneSignal de antes. Si las entregas en iOS van por detrás de las de Android, revisa las credenciales antes de revisar el código.

Un plan de migración en 5 pasos para apps grandes

Haz un inventario de cada llamada a OneSignal antes de tocar el código

Lista cada llamada al SDK, wrapper, callback y test, en todos los repositorios. Esta lista se convierte en la checklist para el reemplazo y para el code review.

Encapsula el push detrás de 1 interfaz interna

Pasa cada llamada de push por un único servicio interno: login, logout, tags, manejo de notificaciones. Así la migración cambia 1 implementación en lugar de 50 puntos de llamada, y el próximo cambio de proveedor también será más fácil.

protocol PushService {
    func login(userId: String)
    func setTags(_ tags: [String: Any])
    func handleNotificationOpen(_ payload: [AnyHashable: Any])
}

Cambia los SDKs en 1 solo release

Agrega el SDK de Pushwoosh y quita el SDK de OneSignal en el mismo build. 2 SDKs de push en 1 app compiten por los callbacks de notificaciones. Mientras el nuevo build se distribuye, sigue enviando desde OneSignal a los usuarios con la versión anterior.

Lanza por etapas y compara las métricas de entrega

Empieza con una pequeña parte de los usuarios mediante phased release o staged rollout. Revisa los crashes en Crashlytics y las entregas en las estadísticas de Pushwoosh, y luego amplía el rollout.

Deja de enviar desde OneSignal solo después de verificar la entrega

Hasta que dejes de enviar desde OneSignal, hacer rollback significa seguir enviando desde OneSignal. Córtalo cuando la entrega con Pushwoosh y la importación de audiencia estén confirmadas.

Preguntas frecuentes