Un puente entre plataformas de aprendizaje

Tenía varios WordPress con LearnDash —cursos en varias instalaciones— y había que llevarlo todo a un único Moodle. No era una migración puntual: además de migrar, había que seguir sincronizando. De esa necesidad salió un puente entre las dos plataformas, y el proyecto más serio que he hecho por cuenta propia.

El problema de verdad no eran los cursos

Migrar cursos es mecánico. El problema eran las personas: el mismo alumno existía en varias instalaciones con el mismo correo, y si no lo tratabas bien acababas duplicando cuentas o, peor, perdiendo el progreso que ya tenía. Por eso la decisión central del proyecto es que el correo es la identidad única, y la deduplicación (averiguar cuándo dos fichas son la misma persona) se hace en un sistema canónico propio: el WordPress es el origen de datos, el puente es el sistema canónico, y el Moodle es la plataforma final de formación.

Cómo está hecho

Un plugin propio de WordPress (un complemento que se le añade para ampliarlo) expone los datos de LearnDash por REST, una manera estándar de pedir datos a otro programa: cursos, usuarios, matrículas y progreso, con paginación y filtros por fecha para la sincronización incremental (solo lo que ha cambiado desde la última vez). Las matrículas se detectan tres veces para no perder ninguna: las órdenes de WooCommerce, las nativas de LearnDash y la tabla de actividad. En medio, un panel de control con FastAPI, React y PostgreSQL, y Celery con Redis (una cola de tareas) para que las operaciones largas corran en segundo plano: la API nunca se bloquea, y cada ejecución queda registrada con sus logs y se puede repetir si ha fallado. Mover datos entre sistemas no me era nuevo —ya había automatizado documentos entre Excel y XML, como conté en Automatización de documentos: Excel y XML— pero esta era otra escala.

Lecciones que aprendí por las malas

La primera: idempotencia o muerte. Repetir una importación no debe generar nunca duplicados (eso es la idempotencia: repetir la operación no cambia el resultado), porque en la práctica siempre se repite. La segunda: nunca confiar en el orden de las cosas; el mapeo es por slug o por ID, nunca por posición. Y la tercera: dry-run antes de escribir (simular sin tocar nada). Todo cambio contra el Moodle de producción se simula primero, se valida en el panel y solo entonces se aplica. Cuando trabajas con el progreso real de alumnos, la simulación no es una opinión de diseño: es la diferencia entre un incidente y un trabajo tranquilo.

Qué haría distinto hoy

Empezaría por el plan de fases, que fui escribiendo a medida que el proyecto crecía, y sería más estricto cerrando el alcance inicial: las suscripciones y el SSO (un solo inicio de sesión para todos los sistemas) los dejé fuera por una buena razón y habría sido más honesto aún. Y pondría pruebas de integración contra un Moodle de pruebas desde el primer día, porque la API oficial también te da sorpresas.