Lo que los operadores no entienden sobre migrar de plataforma

Los operadores cambian de plataforma por buenos motivos: un proveedor que dejó de invertir, una entrada en un mercado que el stack actual no soporta, limitaciones de pago que ningún esfuerzo de marketing compensa, o una economía que ya no funciona a la escala del operador.

La decisión suele ser correcta. La planificación suele estar mal, porque la migración se discute como un movimiento técnico y se presupuesta por licencias, mientras que el costo y el riesgo se concentran casi por completo en cuatro áreas que rara vez aparecen en el alcance inicial.

Los datos de jugadores no son una exportación de base de datos

El supuesto es que los jugadores se transfieren como registros. No es así. Lo que se transfiere es un conjunto de obligaciones.

Los saldos tienen que llegar exactos y verificables: una discrepancia de cualquier tamaño es a la vez un evento regulatorio y un evento de confianza. El historial de transacciones tiene que seguir siendo consultable, tanto para los jugadores que preguntan como para los reguladores que lo exigen. El estado de los bonos es más difícil que los dos: requisitos de apuesta parcialmente completados, giros gratis otorgados y no usados, progreso de fidelidad acumulado durante años. Cada uno de ellos representa algo que el operador le prometió a un jugador concreto, y cada uno tiene que sobrevivir intacto al traslado.

El estado de verificación es la pieza que más veces causa daño visible. Si el KYC no se transfiere correctamente, a jugadores ya verificados se les pide verificarse otra vez. Algunos lo van a hacer. Muchos lo van a tomar como motivo para dejarlo.

Las integraciones de pago son relaciones, no conectores

La segunda área subestimada. Un método de pago en la plataforma vieja no es una integración técnica que se pueda reapuntar; es una relación comercial con condiciones, límites, acuerdos de liquidación y un historial que determina cómo te trata el proveedor.

En una plataforma nueva cada una de esas relaciones se restablece. Algunos proveedores exigen nueva aprobación. Otros aplican tarifas o límites distintos. Algunos sencillamente no están soportados por la nueva plataforma, lo que cambia las opciones de depósito en un mercado y por lo tanto cambia la conversión, muchas veces justo en el mercado donde el operador menos podía permitírselo.

La mitigación es poco glamorosa: auditar qué métodos concentran la mayoría del volumen de depósito por mercado, confirmar su disponibilidad en la plataforma destino antes de firmar, y tratar cualquier hueco como un costo de la migración y no como un detalle a resolver después.

La deuda de integraciones es invisible hasta que deja de serlo

Toda plataforma acumula conexiones a su alrededor con los años: un CRM, un stack de BI, seguimiento de afiliados, motores de bonos, herramientas de soporte, informes de los que depende finanzas y un conjunto de scripts internos chicos que nadie se acuerda de haber escrito.

Las migraciones se dimensionan sobre la plataforma y se olvidan en la periferia. Entonces la plataforma de afiliados deja de recibir postbacks, el informe mensual de finanzas se queda sin fuente y soporte pierde la vista del historial del jugador que usa para responder tickets.

El ejercicio útil antes de comprometerse: listar todos los sistemas que hoy leen o escriben en la plataforma, y nombrar a la persona que se va a dar cuenta si dejan de hacerlo. La lista siempre es más larga de lo esperado, y es el alcance real del proyecto.

El período en paralelo que nadie presupuesta

El error estructural más común es planificar una fecha de corte en lugar de un período de transición.

Durante algunas semanas los dos sistemas tienen que ser operativamente ciertos. Soporte necesita responder preguntas sobre actividad en cualquiera de los dos lados. Finanzas necesita conciliar entre dos fuentes. Los jugadores que todavía no se movieron tienen que seguir jugando sin notar nada.

Los equipos que planifican un único interruptor descubren igual este período, sin preparación y en el peor momento. Los equipos que lo planifican con anticipación lo tratan como una fase con su propia dotación y su propia lista de controles, y pasa sin incidentes.

Qué contiene un plan realista

• Un inventario de datos antes que nada. Saldos, historial, estado de bonos, verificación, autoexclusión y ajustes de juego responsable, con un método de verificación para cada uno.
• Disponibilidad de pagos confirmada por mercado, no por folleto de la plataforma.
• Una lista completa de integraciones periféricas con un responsable asignado a cada una.
• Una migración por etapas, normalmente por segmento o mercado, para que un problema afecte a parte de la base de jugadores y no a toda.
• Una posición de reversión que siga disponible hasta que la nueva plataforma haya manejado de forma demostrable un ciclo completo de liquidación.
• Un plan de comunicación escrito antes de que los jugadores noten algo, no después.

Cuándo no migrar

La migración es la respuesta equivocada cuando el problema real es una capacidad concreta y no la plataforma en su conjunto. Un método de pago que falta, un hueco de reporting o una única integración suelen poder resolverse sin mover nada, y mover todo para resolverlo importa muchísimo riesgo para arreglar algo angosto.

También es el momento equivocado cuando el operador está a mitad de lanzamiento en un mercado nuevo, en temporada alta, o sin capacidad interna para llevar bien un período de transición. La plataforma va a seguir siendo reemplazable dentro de tres meses; una migración fallida en plena temporada alta no se recupera en el mismo plazo.

Ideas clave

• El costo de la migración está en los datos de jugadores, las relaciones de pago, las integraciones periféricas y el período de transición, no en las licencias.
• El estado de los bonos y la verificación son los datos más difíciles de mover y los más dañinos si salen mal.
• Los métodos de pago son relaciones comerciales que hay que restablecer, y un hueco cambia la conversión en mercados concretos.
• El alcance real es cada sistema que lee o escribe en la plataforma actual, que siempre es más que la lista inicial.
• Planificá un período de transición en vez de una fecha de corte, migrá por etapas y mantené la reversión hasta que pase un ciclo completo de liquidación.

Planificar un cambio

Si estás evaluando un cambio de plataforma, la conversación útil empieza por el inventario de datos y la auditoría de pagos, no por la comparativa de funcionalidades. Ponete en contacto con nuestro equipo →

Aviso: Este blog puede incluir referencias a los servicios que ofrecemos. Nuestro equipo desarrolla plataformas profesionales de iGaming y brinda consultoría a operadores en analítica, cumplimiento y configuración de plataforma. 

Autor: Roman K
CMO en Betdevel. 12+ años de experiencia en iGaming.

Linkedin