Cambiar de software escolar sin perder los datos: interoperabilidad, APIs y portabilidad

Hay una pregunta que casi nunca aparece en las demostraciones comerciales y que decide más contratos de los que parece: qué pasa con mis datos el día que me quiera ir. La mayoría de equipos directivos no la formula porque suena a desconfianza, y la mayoría de proveedores no la aborda porque la respuesta rara vez favorece la venta. El resultado es que muchos centros descubren la respuesta cuando ya no tienen margen para negociarla.

Por qué la pregunta importa ahora

El asunto se ha vuelto más urgente en el último año. El análisis del mercado escolar para 2026-2027 apunta en la misma dirección en varios países: el software sin inteligencia artificial nativa, sin cumplimiento sólido de protección de datos y sin interoperabilidad documentada será sustituido o parcheado con herramientas de terceros. Y cuando llega el momento de sustituir, la fricción no es el precio: es el miedo a perder quince años de expedientes.

Las cuatro preguntas que hay que hacer por escrito

Antes de firmar con cualquier proveedor —incluido el que ya tenéis, en la próxima renovación— conviene pedir por escrito la respuesta a cuatro cosas. Por escrito significa en el contrato o en un anexo, no en un correo de un comercial:

• ¿Qué puedo exportar, en qué formato y con qué periodicidad? La respuesta buena es concreta y por entidad: alumnos, tutores legales, matrículas por curso, calificaciones, asistencia, recibos y su estado, documentos adjuntos. La respuesta mala es «te damos un volcado», porque un volcado puede ser un PDF de mil páginas.
• ¿Existe una API documentada y accesible para el cliente? No hace falta que el centro la use directamente; hace falta que exista, porque es la prueba objetiva de que los datos son extraíbles sin depender de la buena voluntad de nadie.
• ¿Con qué se integra de forma nativa? Sed específicos y preguntad por lo que realmente usáis, no por una lista genérica de logotipos.
• ¿Qué ocurre a la terminación del contrato? Plazo concreto para entregar la exportación, formato comprometido, coste si lo hay, y cuánto tiempo se conservan los datos antes de suprimirlos.

Por qué el bloqueo de proveedor no suele ser malicioso

Conviene entender el mecanismo, porque ayuda a evaluar respuestas. Muy pocos proveedores retienen datos deliberadamente. El bloqueo se produce por acumulación: durante años se han ido creando campos personalizados, documentos subidos, plantillas, históricos de comunicaciones y configuraciones que no tienen un equivalente exacto en ningún otro sistema.

Lo estructurado y lo que nadie exporta

Eso significa que la portabilidad real no es binaria. Se puede exportar el 100 % de los datos estructurados —alumnos, notas, recibos— y aun así perder el 100 % de lo no estructurado, que es a menudo lo que más trabajo costó construir. Preguntar específicamente por los documentos adjuntos y el histórico de comunicaciones es lo que distingue una evaluación seria de una superficial.

Interoperabilidad no es lo mismo que integración

La distinción importa porque los proveedores usan las dos palabras como sinónimos y no lo son. Una integración es una conexión concreta con un sistema concreto, construida y mantenida por alguien: funciona bien mientras las dos partes la mantengan. La interoperabilidad es la capacidad de intercambiar datos con cualquier sistema mediante formatos y estándares abiertos, sin necesidad de que exista una conexión específica.

Para un centro pequeño, las integraciones nativas resuelven el día a día y la interoperabilidad es un seguro. Para un grupo con varios centros y sistemas heredados, la interoperabilidad deja de ser un seguro y pasa a ser un requisito, porque ningún proveedor va a construir integraciones a medida para cada caso.

Con qué debe integrarse un ERP escolar

Cuando preguntéis por integraciones, preguntad por estas cinco y no por una lista genérica:

• La plataforma de vuestra comunidad autónoma: Séneca, Rayuela, ITACA, GESTIB o la que corresponda.
• El entorno de aprendizaje: Google Classroom, Moodle o Microsoft Teams, según lo que use el claustro.
• La gestoría o el software de contabilidad: para no reintroducir a mano las facturas del mes.
• La pasarela de pagos y el banco: domiciliaciones, devoluciones y conciliación.
• El correo institucional y el directorio de usuarios: para no gestionar dos listas de altas y bajas.

Lo que de verdad alarga una migración

La expectativa habitual es que migrar sea un problema técnico. En la práctica, para un centro de tamaño medio son entre cuatro y ocho semanas de trabajo real, y la mayor parte no se dedica a mover datos sino a limpiarlos. Los tres culpables son casi siempre los mismos:

• Duplicados: el mismo alumno dado de alta dos veces, familias con dos fichas, hermanos con tutores repetidos.
• Campos libres sin normalizar: direcciones escritas de cinco maneras, teléfonos con y sin prefijo, cursos nombrados de forma distinta según quién los creara.
• Documentación que solo existe en papel: o en la carpeta local de alguien. No está en ningún sistema y por tanto no se puede migrar de ninguna manera.

La limpieza se puede empezar hoy

De ahí sale una consecuencia práctica muy útil: la limpieza de datos no depende del proveedor que elijáis. Se puede empezar antes de decidir nada, y hacerlo acorta el proyecto sea cual sea la decisión final. Si además acabáis quedándoos donde estáis, habréis mejorado igualmente lo que tenéis.

Cuándo cambiar

El corte natural es entre el cierre del curso y el inicio del siguiente: matrícula ya renovada, calificaciones cerradas y clases sin empezar. Ese es el único momento en que el sistema antiguo puede quedarse congelado como archivo mientras el nuevo arranca limpio.

Si no queda otra que cambiar a mitad de curso

Es posible, pero implica convivir con dos sistemas durante semanas, con el riesgo de que un dato se actualice en uno y no en otro. La regla es clara y no admite matices: un sistema es el oficial desde el día uno y el otro es solo consulta, sin excepciones ni casos especiales. En cuanto se permite una excepción, aparecen dos versiones de la verdad.

Caso práctico (España)

Un grupo con cuatro centros llevaba tres años queriendo unificar plataformas y no lo hacía por una razón concreta: nadie sabía si podría recuperar los expedientes históricos del sistema más antiguo, en uso desde 2009.

Antes de negociar con ningún proveedor nuevo, pidieron por escrito al actual una exportación de prueba. Tardó cinco semanas en llegar y vino en un formato que contenía alumnos, matrículas y calificaciones, pero no los documentos adjuntos ni las comunicaciones. Esa respuesta, incómoda pero clara, fue lo que permitió planificar de verdad.

La decisión fue migrar lo estructurado al sistema nuevo y conservar el antiguo en modo consulta durante dos cursos para la documentación adjunta, con un calendario de descarga manual de los expedientes que legalmente había que conservar. No fue elegante, pero fue previsible, y evitó descubrir el problema con el contrato ya rescindido.

Conclusión

La pregunta sobre la salida no es un gesto de desconfianza, es parte de una evaluación seria. Un proveedor que responde con formatos concretos, API documentada y plazos escritos os está dando la mejor señal posible sobre cómo tratará vuestros datos mientras seáis clientes. Uno que responde con generalidades os está diciendo algo también.

En Edena publicamos API documentada, exportación completa por entidad en formatos abiertos y condiciones de salida escritas en el contrato, porque preferimos que os quedéis por el producto y no porque no podáis iros. Pide una demo y te enseñamos exactamente qué sale y en qué formato.