How to migrate an enterprise GIS platform to an open-source viewer

To migrate an enterprise GIS platform to an open-source viewer, inventory your installation’s workflows, separate data and rules from the interface, build a pilot around complete tasks and verify equivalence before retiring components. A map that loads does not demonstrate that permissions, editing, reporting or integrations have been replaced.

This path covers modernization of ArcGIS Enterprise and Online, VertiGIS/Geocortex, M.App Enterprise, GeoMedia, Precisely Spectrum Spatial, SuperMap, CARTO, GIS Cloud, MapGIS and custom applications. Scope depends on installed versions, modules and integrations. A maps or routing provider requires a different assessment from an enterprise suite.

To visualize the result, explore our selection of geospatial viewers and open experiences. Terraes illustrates search and territorial lookup; kepler.gl, analytical exploration; Digital Earth Australia, comparison; NASA Worldview, temporal navigation. These are product and design references. They do not prove those organizations replaced a proprietary platform.

Before starting: identify what you are migrating

The migration must cover the system behind the task. Use this matrix to scope a pilot; these are assessment questions, not guarantees of automatic conversion.

The comparison with vendor sources explains these differences. For a specialist network or engineering system, publishing a read-only copy may be viable while the editing system stays operational. Do not count its licenses as eliminated if you still depend on it.

1. Define what completing the migration means

Start with three tasks people actually perform. For example: find a parcel and inspect its record; intersect a location with a restrictions layer; export a report containing authorized fields. Identify the owner, input data, rules and expected result for each task.

Record a decision for every workflow: retain, upgrade, decouple, replace or retire because it is no longer used. Document the reason and the user who will verify the result. An infrequently used module may be essential to an annual process; click frequency alone is insufficient evidence for retirement.

Build the inventory from the installation and its contracts. A commercial demo or vendor website cannot replace that inspection. The GIS platform comparison identifies dependencies to review by product family.

2. Separate the viewer from data and rules

The target architecture needs clear interfaces between storage, publication and application. One possible combination is PostGIS for data, GeoServer for cartography and OGC services, pygeoapi for collections published through OGC API, and MapLibre or OpenLayers for the web experience. You do not need to install every component.

Capabilities are documented by MapLibre, OpenLayers, Lizmap, TerriaJS and deck.gl. The final choice requires a trial with representative project data.

ArcGIS or other vendor services can remain during the transition where their access and terms permit. If the new viewer still depends on them, retain their cost in the budget. Decoupling the interface does not eliminate that dependency.

3. Make information portable before cutover

Export a sample with geometries, attributes, identifiers and relationships. Include records without geometry, null values, accented characters, documents and dates. Compare counts, uniqueness, spatial extents and attachment correspondence. Verify the coordinate reference system and transformation, especially when combining Colombian cartography with a web basemap.

Styles, forms, queries, rules and permissions do not necessarily travel with a geometry export. Maintain an explicit correspondence between each source element and its destination. Where automatic equivalence does not exist, include reconstruction in scope and cost.

Define how the copy stays current during the pilot. This may be a periodic extract or controlled synchronization, depending on the available system. Identify the master source, acceptable delay and detection of rejected records. Avoid enabling writes in two systems without a reconciliation rule.

4. Design an experience people can use

An attractive viewer needs hierarchy: visible search and primary task; secondary layers on demand; readable legends; recognizable selection; and a record panel connected to the selected object. Color should explain data or state. Reserve 3D for questions where height or volume improves understanding.

Terraes is a relevant reference for giving the map priority and displaying contextual information. Its reviewed viewer uses MapLibre. We do not present it as a fully open-source application, evidence of replacing a proprietary platform or evidence of uniform coverage or valuation in every location.

On mobile, let search, results and records work without competing for the entire screen. Test keyboard navigation, visible focus, enlarged text and contrast. Provide a list or table when a task cannot rely on the map alone. Distinguish loading, no data, denied access and an unavailable source.

5. Accept the pilot through complete tasks

Use authorized data and a sample containing difficult cases. The pilot should cover the path from search through inspection and export. If the workflow includes editing, test validations, conflicts and traceability as well.

Agree thresholds before measurement. An average loading time on a fast laptop does not prove phone or concurrent-user performance. The Open GIS lab supports publication and validation practice with synthetic data; it does not certify a production installation.

6. Compare total cost, beyond licenses

For an agreed time horizon, compare the cost of continuing against transition plus operating the new architecture. Include retained licenses, construction, data migration, training, temporary coexistence, cloud, storage, basemaps, imagery, geocoding, backups, security, support and improvements.

Net savings = total cost of continuing − total cost of migrating and operating. An open-source component can have zero license cost and still require significant installation and maintenance work. Avoiding per-user licenses does not eliminate infrastructure or support. The result can be negative.

Use the Open GIS cost calculator with your figures. Separate confirmed costs from assumptions. Test sensitivity to operating and transition costs. Avoid universal percentages or attributing unpublished savings to Terraes or an external portal.

7. Switch traffic when operations are ready

Plan the final copy, checks, change window, owners and rollback. Keep the source available under the approved plan until the new operation is verified. If public record or map URLs exist, preserve useful identifiers and links or prepare redirects to equivalent destinations.

Delivery includes code and configuration under the contract, a dependency and license inventory, API documentation, deployment and restoration procedures, training and support owners. Practical independence is demonstrated when another authorized team can deploy and operate the system.

To begin, assemble your platform name and version, three priority tasks, sources, integrations and current costs. Request a geoportal assessment and use the viewer gallery to agree on the experience you need to build.

GeoSAT provides an independent assessment of the options. Mentioned trademarks belong to their owners. External references illustrate capabilities and patterns; they do not imply endorsement, a commercial relationship or functional equivalence with your installation.

To assess vendors and categories before choosing an architecture, read GIS platforms and open-source alternatives: ArcGIS, VertiGIS, CARTO and other options are compared by scope.