1. GeoServer 3: renovación estructural y tecnológica
La publicación de GeoServer 3 es la primera versión mayor del servidor de mapas desde la serie 2.x. El cambio más visible está en la propia interfaz web de administración, pero también cambian las tecnologías sobre las que está construida la aplicación, es decir, el ecosistema Java actual, los servidores de aplicaciones y varias extensiones. Esta actualización afecta a la arquitectura sobre la que funcionan la gran mayoría de las Infraestructuras de Datos Espaciales (IDE) de organismos públicos y empresas.

En el siguiente artículo haremos un repaso a los principales cambios a partir de la experiencia contrastada mediente una prueba técnica de actualización real llevada a cabo por el Área de SIG y Desarrollo de Geoinnova.
2. Requisitos del sistema y pila tecnológica
GeoServer 3 no solo actualiza la versión de Java: cambian también el servidor de aplicaciones, la API Servlet, el marco de trabajo interno y el mecanismo de autenticación. Estas son las las versiones de las tecnologías admitidas en la version 2.28 y en la 3:
| Componente | GeoServer 2.28 | GeoServer 3 |
| Java | Java 17 o 21 | Java 17 o 21; Java 25 en fase de pruebas |
| Servidor de aplicaciones | Tomcat 9.x o Jetty 9.4 | Tomcat 11.0.x o Jetty 12.1 |
| API Servlet | Java EE Servlet API 4 con Tomcat 9; Servlet API 3.1 con Jetty 9.4 | Jakarta EE Servlet API 6.1 |
| Base tecnológica | Plataforma Java EE de la rama 2.28 | Spring Framework 7 y Jakarta EE |
| Autenticación mediante proveedores de identidad | Extensiones Keycloak y OAuth2 | Extensión oficial OpenID Connect (OIDC) |
Otra cuestión a destacar en este lanzamiento es la reducción del número de componentes incluidos en el núcleo. El soporte de los servicios WCS 1.0 y 1.1, el formato KML y los almacenes ráster World Image y ArcGRID pasan a distribuirse como extensiones. La base de datos relacional escrita en Java H2 deja de incluirse en la distribución.
3. Entorno de pruebas: dos instancias sobre el mismo Data Directory
El Data Directory es la carpeta de configuración donde GeoServer almacena el catálogo del servicio: espacios de trabajo, conexiones a datos, capas, estilos, servicios publicados y reglas de seguridad. Comprobar que GeoServer 3 puede cargar una copia procedente de la versión anterior es uno de los primeros pasos de una migración

Para las pruebas se ha reproducido un escenario de una migración real. Se han desplegado dos contenedores Docker independientes de GeoServer, 2.28 y 3. Ambas consultan la misma base PostgreSQL/PostGIS, con tablas geográficas de información catastral y de OpenStreetMap del municipio alicantino de El Verger.
Los objetivos principales de los test era los siguientes.
- Comprobar si GeoServer 3 accedía al Data Directory generado por la versión 2.28 y cargaba todos sus recursos: conexiones, espacios de trabajo, catálogo de capas y estilos.
- Revisar cómo cambian las tareas habituales de administración una vez cargado el catálogo: localizar un recurso, editar una capa y revisar su representación.

4. Resultados
Continuidad del catálogo
Al montar el Data Directory de la version 2.28 en el contenedor de GeoServer 3, el catálogo aparece completo sin ninguna operación de importación: los espacios de trabajo, el almacén PostGIS, las capas y los estilos SLD se leen tal como los dejó la instalación de partida.
Revisando una de las capas del catálogo gs_comparativa:edificios_poblacion podemos comporbar que los formularios conservan los parámetros de publicación, el sistema de referencia, los encuadres y los estilos asociados. La previsualización devuelve la misma representación en las dos ramas: el resultado depende de la capa y del SLD publicados, no de la versión de la consola.


Cambios en la apariencia y en la experiencia de usuario
Las capturas siguientes recorren en las dos instancias las tareas enunciadas en el apartado 3: localizar un recurso, editar una capa y revisar su representación.
- Navegación contextual: la distribución de elementos reorganiza los accesos según el recurso seleccionado (workspace, store o layer), con lo que se reducen los desplazamientos por el menú lateral.

- Búsqueda lateral de recursos: un buscador global integrado en la barra lateral permite localizar capas, servicios, espacios de trabajo y estilos sin recorrer los listados, algo de gran utilidad para catálogos de datos con muchos recursos.

- Sistema de navegación y menús contextuales: la parte superior de la consola muestra el recurso seleccionado y facilita el acceso a las acciones relacionadas, como volver desde una capa a su almacén de origen.

- Diseño adaptable y modo oscuro: los formularios reorganizan su contenido según el ancho disponible y la consola permite activar el modo oscuro desde el menú de usuario.

- Previsualización de capas: el visor integrado, basado en OpenLayers, aprovecha toda la pantalla para revisar la representación cartográfica y los formatos de salida disponibles. El acceso a la configuración de opciones como cambio de estilo o filtros es más intuitivo.

| Test | Evidencia | Resultado |
| T01- Continuidad del catálogo de datos | Data Directory de 2.28 montado en GeoServer 3 | Capas, estilos y parámetros de publicación disponibles sin rehacer el catálogo |
| T02 – Acceso a la administración de recursos | Capturas de ambas versiones | Los mismos formularios, con los accesos reorganizados por recurso |
| T03 – Localización de recursos | Buscador y árbol lateral | GeoServer 3 incorpora navegación por contexto |
| T04 – Edición de una capa | Formulario de «edificios_poblacion» | Los parámetros del formulario se mantienen |
| T05 – Previsualización | Misma capa y estilo | GeoServer 3 amplía el área de mapa y renueva los controles |
La migración de seguridad, las extensiones específicas y las integraciones REST dependen de cada instalación y deben comprobarse por separado antes de trasladar conclusiones a producción.
5. Checklist de migración a GeoServer 3
Como hemos comentado que GeoServer 3 lea el Data Directory de la versión 2.28.x es factor fundamental para valorar una migración entre versiones. Pero hay sin duda más aspectos a tener en cuenta que deben ser analizados antes de ejecutar los trabajos de actualización también conocido como upgrade.
La siguiente lista de tareas es una propuesta base que ordena esa revisión en la secuencia en que puede ejecutarse sin tocar el servicio activo, e indica en cada punto el criterio que permite darlo por cerrado.
- [ ] Inventariar la versión de partida, las extensiones instaladas, los estilos y las aplicaciones que consumen el servicio.
- [ ] Copiar el Data Directory y dejar intacta la instalación de origen.
- [ ] Preparar Java 17 o 21 y un servidor de aplicaciones compatible, Tomcat 11.0.x o Jetty 12.1, según la tabla del apartado 2.
- [ ] Montar la copia del Data Directory en una instancia aislada de GeoServer 3 y revisar en ella las capas, los estilos y la previsualización.
- [ ] Comprobar los módulos que ahora se distribuyen como extensiones, y la migración de la autenticación hacia OIDC cuando proceda.
- [ ] Validar el catálogo, los estilos, GeoWebCache y las peticiones WMS y WFS que utilizan las aplicaciones cliente.
- [ ] Definir la ventana de intervención y el procedimiento de vuelta atrás antes del cambio definitivo.
Los pasos 2 a 4 pueden realizarse íntegramente en un entorno aislado, sin intervenir sobre la instalación de GeoServer en producción, siguiendo el método descrito en el apartado 3.
Las comprobaciones finales —extensiones, autenticación, aplicaciones cliente y plan de intervención— deben adaptarse a cada instalación. Su alcance se determina a partir del inventario inicial, ya que depende de los componentes utilizados, de las integraciones existentes y de los requisitos de continuidad del servicio. Solo cuando estas validaciones se hayan completado debería programarse la actualización del entorno de producción.
6. Evaluar la migración antes de intervenir en producción
El cambio de versión afecta a la plataforma tecnológica, pero mantiene el modelo general de publicación de los datos geográficos: los estándares OGC, el catálogo y los estilos continúan siendo reconocibles. Una vez comprobada la compatibilidad del Data Directory, la decisión de actualizar depende de aspectos propios de cada instalación: las extensiones utilizadas, el proveedor de identidad, las aplicaciones que consumen los servicios y el comportamiento del sistema bajo carga, que no se ha evaluado en este laboratorio.
En Geoinnova hemos aplicado esta metodología en nuestro entorno de pruebas para evaluar la migración de GeoServer 2.28 a GeoServer 3. Este procedimiento puede adaptarse a la infraestructura de otras organizaciones para detectar incompatibilidades antes de intervenir en producción y planificar la actualización con criterios objetivos. Desde el Área de SIG y Desarrollo podemos acompañar el proceso desde la auditoría inicial hasta las pruebas, el despliegue definitivo y la definición del procedimiento de vuelta atrás.
7. Recuersos y fuentes consultadas
- Anuncio oficial de publicación de GeoServer 3.0.0: https://geoserver.org/announcements/vulnerability/2026/06/11/geoserver-3-0-0-released.html
- Notas de lanzamiento de GeoServer 3.0.0 en GitHub: https://github.com/geoserver/geoserver/releases/tag/3.0.0
- Manual de usuario de GeoServer 3.0: https://docs.geoserver.org/3.0.x/en/user/
- Repositorio de imágenes Docker oficiales de GeoServer: https://github.com/geoserver/docker
- Centro de descargas oficial de GeoServer: https://geoserver.org/download/
- GeoServer 3 Crowdfunding https://geoserver.org/sponsor/gs3-crowdfunding
¿Quieres comentarnos algo? Adelante!