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 coste 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 deben 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 ambos: 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 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 harán. Muchos lo tomarán como motivo para dejarlo.

Las integraciones de pago son relaciones, no conectores

La segunda área subestimada. Un método de pago en la plataforma antigua 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 tanto cambia la conversión, a menudo justo en el mercado donde el operador menos podía permitírselo.

La mitigación es poco glamurosa: 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 coste 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 pequeños scripts internos que nadie recuerda 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 dará cuenta si dejan de hacerlo. La lista siempre es más larga de lo esperado, y es el alcance real del proyecto.

El periodo en paralelo que nadie presupuesta

El error estructural más común es planificar una fecha de corte en lugar de un periodo 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 aún no se han movido deben seguir jugando sin notar nada.

Los equipos que planifican un único interruptor descubren igualmente este periodo, sin preparación y en el peor momento. Los equipos que lo planifican con antelación lo tratan como una fase con su propia dotación y su propia lista de comprobaciones, 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 gestionado 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 estrecho.

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 periodo de transición. La plataforma 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 coste de la migración está en los datos de jugadores, las relaciones de pago, las integraciones periféricas y el periodo 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.
• Planifica un periodo de transición en vez de una fecha de corte, migra por etapas y mantén 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. Ponte en contacto con nuestro equipo →

Aviso: Este blog puede incluir referencias a los servicios que ofrecemos. Nuestro equipo desarrolla plataformas profesionales de iGaming y ofrece 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