Skip to content
GEOSAT
Volver al blog
SIG
SIG2026-07-17Daniel Marulanda13 min lectura

MapGIS: modernizar, integrar o migrar con evidencia

Qué demuestran las fuentes públicas sobre MapGIS Flex 3, MapGIS5, MapGIS9 y MapGIS10, y cómo auditar una implementación antes de renovar o migrar.

modernizar MapGISmigrar MapGISMapGIS QGIS PostGISarquitectura geoespacial Colombiageoportal MapGIS

Revisión de fuentes: 17 de julio de 2026. GeoSAT no está afiliada con H&G Consultores ni con MapGIS. MapGIS pertenece a su respectivo titular. Este análisis diferencia hechos publicados, afirmaciones del proveedor e inferencias técnicas; no califica una instalación que no haya sido inspeccionada.

La conclusión corta es que no existe una sola arquitectura MapGIS. Una entidad puede conservar una versión histórica con dependencias acumuladas, operar MapGIS9 o estar evaluando MapGIS10. El nombre del producto no revela por sí solo qué runtime está instalado, dónde viven los datos, qué servicios consume, quién puede modificar el código o cuánto cuesta evolucionarlo.

Por eso no es defendible descalificar todo MapGIS por la edad de una versión histórica. Sí es defendible una idea más útil: el modelo en el que el geovisor concentra los datos, las integraciones y los procesos pertenece a una generación anterior de arquitectura. Para nuevas inversiones, la entidad debe comprobar si su implementación sigue ese modelo o si ya evolucionó hacia datos, APIs y componentes desacoplados.

GeoSAT ofrece una auditoría de modernización MapGIS para responder esa pregunta antes de renovar, actualizar o migrar.

Qué significa “legado” en este análisis

Legado no califica por sí solo la utilidad, seguridad o vigencia comercial. Es una condición de arquitectura y operación: cambiar una pieza resulta costoso porque el sistema depende de tecnologías, contratos, código o conocimiento acumulado que afectan otras capas.

Un sistema puede seguir prestando un servicio crítico y ser legado al mismo tiempo. También puede tener muchos años y no serlo, si sus datos son portables, las interfaces están documentadas, los componentes siguen soportados y distintos equipos pueden operarlo.

La prueba no es la fecha de compra. La prueba es cuánto control conserva la organización sobre:

  • Datos, históricos, metadatos y permisos.
  • APIs, servicios de mapas y consumidores.
  • Reglas de negocio e integraciones.
  • Código fuente, despliegues y pruebas.
  • Actualizaciones, soporte y recuperación.
  • Capacidad de contratar a otro equipo.
  • Costo total durante los próximos años.

2009–2024: la trayectoria documentada por Medellín

Un documento contractual publicado por Colombia Compra Eficiente registra que la primera adquisición de MapGIS por parte del Distrito de Medellín fue una licencia corporativa de MapGIS Flex versión 3.0, fechada el 16 de septiembre de 2009.

El mismo documento corresponde a un contrato iniciado en marzo de 2024 para adquirir suscripción, soporte, mantenimiento y actualización de MapGIS 9.0. Describe entonces continuidad tecnológica, no una plataforma detenida en Flex 3: para esa contratación, Medellín reportó una suite Server/Java con frontend HTML5 y CSS3 integrada con ArcGIS.

El documento también explica que el Distrito contaba con licenciamiento perpetuo para usuarios ilimitados. Señala que las aplicaciones misionales pertenecían al Distrito y podían ser intervenidas por terceros, siempre que esos terceros no utilizaran el código fuente específico de la plataforma MapGIS.

Esta fuente demuestra una historia contractual y tecnológica concreta en Medellín. No demuestra qué versión está instalada hoy, ni que otras entidades tengan las mismas condiciones de licencia, propiedad intelectual o mantenimiento. Tampoco permite usar la referencia a Flex 3.0 para describir MapGIS 9.0 o MapGIS 10.

La distinción sobre código sí sugiere una pregunta verificable para cualquier renovación: ¿qué parte puede mantener un tercero con los entregables de la entidad y qué parte requiere código o conocimiento reservado de plataforma? La respuesta debe salir del contrato, los repositorios y una prueba técnica, no de una acusación genérica de dependencia.

MapGIS5: una ficha histórica alojada en el directorio de Esri

La ficha de MapGIS5 en el directorio de socios de Esri describe una aplicación web RIA sobre Java y Adobe Flex, con servicios de mapas de ArcGIS Server y motores de datos como Oracle o SQL Server.

La ficha continúa accesible, pero no presenta una fecha de publicación visible. Debe leerse como descripción de MapGIS5, no como documentación de MapGIS9, MapGIS10 o de toda instalación activa.

La matriz oficial de soporte de Adobe registra que el soporte extendido de Adobe Flex 3 terminó en febrero de 2015. Esto no prueba que una instalación MapGIS actual utilice ese componente. Significa que, si el inventario encuentra una dependencia real de Flex 3, debe existir una ruta documentada para retirarla o aislarla.

Java tampoco permite inferir la condición técnica actual de una aplicación. Puede operar sobre versiones vigentes, recibir parches y tener una arquitectura mantenible. Lo relevante es la versión exacta del runtime, sus dependencias, el ciclo de soporte y la capacidad de desplegar y probar cambios.

2024 y 2025: MapGIS9 seguía en despliegues institucionales

La Circular 317 de 2024 del Municipio de Itagüí informó que su Geoportal SIGMI estaba basado en la suite MapGIS versión 9.0. La fuente contradice cualquier afirmación de que el producto hubiera dejado de utilizarse antes de ese momento.

El Informe de Gestión del primer semestre de 2025 de Cornare documentó el desarrollo, configuración e integración de módulos MapGIS dentro de una nueva arquitectura de servicios. El informe estimaba tener la nueva versión MapGIS9 con sus módulos en funcionamiento al finalizar agosto de 2025.

La redacción importa: el informe de primer semestre describe trabajo en curso y una fecha estimada. No prueba por sí solo que todo el alcance hubiera quedado terminado en esa fecha.

La intranet de Cornare, actualizada el 6 de mayo de 2026, ya identificaba por separado un “Geoportal Interno MapGIS 8.0” y un “(Nuevo) Geoportal Interno MapGIS 9.0”. Esto confirma continuidad e incorporación pública de V9, pero no cuantifica ahorro ni demuestra por sí solo la terminación de todos los módulos previstos.

2026: MapGIS10 cambia la conversación

En una publicación de H&G consultada en julio de 2026, el proveedor presentó MapGIS V10 como una evolución desde el mapa como centro hacia un ecosistema de datos, procesos y toma de decisiones. La publicación menciona IA integrada, múltiples mapas, división de pantalla, mejoras de rendimiento e integración con la versión más reciente del SDK de ArcGIS.

La página actual de la suite MapGIS también afirma que la solución funciona en ambiente web y dispositivos móviles, es personalizable, compatible con múltiples plataformas y facilita la interoperabilidad.

Esri también publicó en ArcNews Winter 2026 un caso de MapGIS-POT en Medellín integrado con ArcGIS Enterprise, ArcGIS Pro, ArcGIS Online y ArcGIS Dashboards.

Estas publicaciones demuestran actividad comercial y evolución anunciada en 2026. No verifican independientemente rendimiento, portabilidad, costo, disponibilidad general de cada capacidad ni el esfuerzo de actualización de una instalación concreta.

El anuncio de V10 refuerza la pregunta correcta: ¿la entidad ya opera esa arquitectura nueva o conserva una instalación anterior? Que el proveedor anuncie una versión reciente no significa que el despliegue instalado haya heredado automáticamente sus capacidades, ni que la actualización sea gratuita o transparente para todas las aplicaciones existentes.

Cornare: modernización híbrida, no sustitución total

El caso Cornare exige especial precisión porque combina varias capas.

En su Informe de Gestión 2024, la entidad documentó bases migradas a PostgreSQL y reportó el cambio de ArcGIS a QGIS. El alcance contractual también incluía adecuaciones de MapGIS Data y una plataforma MapGIS CMS. El informe de 2025 describió la integración de módulos MapGIS9 dentro de la nueva arquitectura de servicios y la intranet de 2026 publicó enlaces a los entornos 8.0 y 9.0.

La lectura defendible es esta:

  • Cornare modernizó la base y reportó el cambio de ArcGIS a QGIS.
  • Mantuvo MapGIS y estaba integrando módulos MapGIS9; en 2026 publicaba enlaces a ambos entornos.
  • La fuente no publica un ahorro financiero realizado antes y después.
  • El contrato agrupó soporte, mantenimiento, evolución e integración; no es un precio universal de migración.

Por tanto, Cornare no demuestra que todas las entidades deban reemplazar MapGIS. Muestra que una modernización puede cambiar ArcGIS por QGIS y bases por PostgreSQL mientras conserva módulos que todavía aportan valor. Consulte el análisis completo del caso Cornare.

El cambio arquitectónico que sí debe evaluarse

Una arquitectura centrada en el geovisor tiende a concentrar integraciones, reglas y experiencia operativa alrededor de la plataforma de presentación. Una arquitectura centrada en datos y procesos busca que el visor sea un consumidor sustituible.

El objetivo no es instalar PostGIS o publicar un WMS y declarar que el sistema quedó abierto. La prueba es que los activos críticos funcionen con contratos claros entre capas.

Datos

  • Modelo y diccionario documentados.
  • Acceso directo autorizado sin pasar por una interfaz específica.
  • Exportación de geometrías, atributos, históricos, adjuntos y relaciones.
  • Roles, auditoría, copias y recuperación probados.

Servicios e integraciones

  • APIs REST u OGC documentadas.
  • Autenticación, límites, versionado y consumidores inventariados.
  • Reglas de negocio fuera de componentes imposibles de probar de forma independiente.
  • Capacidad de sustituir un consumidor sin migrar la base completa.

Aplicaciones

  • Código, dependencias y proceso de despliegue identificados.
  • Pruebas de regresión para los flujos misionales.
  • Interfaces que no concentran la única copia de una regla o dato.
  • Accesibilidad y experiencia móvil verificadas con usuarios reales.

Operación

  • Componentes dentro de soporte.
  • Monitoreo, alertas, SLA y responsables.
  • Restauración probada, no solo copias declaradas.
  • Documentación suficiente para transferir la operación.

Ocho preguntas antes de renovar

  1. ¿Qué versión exacta de MapGIS y qué módulos están en producción?
  2. ¿Qué versiones de Java, .NET, ArcGIS SDK, servidor, sistema operativo y base de datos utilizan?
  3. ¿Qué datos y reglas pueden operar sin la interfaz MapGIS?
  4. ¿Qué servicios están documentados y qué aplicaciones los consumen?
  5. ¿Qué código y repositorios recibió la entidad?
  6. ¿Qué puede mantener un tercero bajo el contrato actual?
  7. ¿Qué corrige una actualización y qué aplicaciones deben adaptarse?
  8. ¿Cuál es el TCO de conservar, actualizar, desacoplar o migrar durante cinco años?

Sin estas respuestas, una renovación repite el estado actual sin saber qué riesgo o costo está comprando. Una migración inmediata sería igualmente irresponsable: podría retirar una capacidad crítica sin sustituto aceptado.

Cuatro rutas, no una sola conclusión

1. Conservar y documentar

Si la implementación cumple los requisitos funcionales, tiene componentes soportados y su costo es razonable, conservarla puede ser la mejor decisión. La inversión se concentra en documentación, pruebas, recuperación y reducción de conocimiento tácito.

2. Actualizar con el proveedor

Una versión nueva puede resolver dependencias antiguas y mejorar la experiencia. La evaluación debe separar licencia, infraestructura, adaptación de módulos, migración de datos, pruebas y soporte. También debe comparar lo prometido con un piloto sobre los flujos reales de la entidad.

3. Desacoplar por capas

Los datos pueden pasar a PostgreSQL/PostGIS, los servicios a APIs u OGC y algunas reglas a componentes documentados mientras la organización conserva temporalmente el visor o módulos especializados. Esta ruta reduce riesgo y permite medir el costo operativo antes de ampliar el cambio.

4. Migrar después de validar

QGIS, GeoServer, QGIS Server, MapLibre, OpenLayers o una aplicación propia pueden reemplazar componentes cuando los flujos sustitutos ya pasaron criterios de aceptación. Una marca abierta no garantiza una arquitectura mantenible; también se deben presupuestar soporte, seguridad, infraestructura y evolución.

Qué no prueban las fuentes públicas

Las fuentes citadas no permiten afirmar:

  • Qué versión usa hoy cada cliente de MapGIS.
  • Que MapGIS10 conserve la arquitectura de MapGIS5.
  • Que una instalación sea insegura o lenta.
  • Que los datos estén bloqueados o sean totalmente portables.
  • Que el costo sea mayor o menor que una alternativa.
  • Que actualizar sea más conveniente que migrar.
  • Que Cornare haya eliminado todos los módulos MapGIS.

Esas respuestas requieren acceso técnico, contratos, facturas, pruebas y entrevistas con responsables. Cualquier conclusión anterior a ese trabajo es marketing, no arquitectura.

Próximo paso

Para nuevas inversiones, audite antes de renovar. La auditoría de modernización MapGIS de GeoSAT entrega inventario técnico, mapa de dependencias, matriz de portabilidad, escenarios de costo total y una ruta con criterios de aceptación.

La conclusión puede ser conservar MapGIS, actualizarlo, integrarlo con PostGIS y APIs, o migrar componentes. La evidencia decide.

Artículos relacionados