When ArcGIS Isn't an Option: A Decision-Grade Map of Geoportal Alternatives to Esri

For a great many organisations the geoportal question has one answer by default: Esri. ArcGIS Enterprise, Portal for ArcGIS, the desktop and the field apps around them – a single, deeply integrated stack that most GIS teams grew up inside. The world, though, is larger than one vendor, and sooner or later someone asks the question this piece is about: what else is there, and how good is it?

We will answer it honestly, and the honest answer has an uncomfortable shape. The alternatives to Esri for a geoportal are real, numerous, and in some cases excellent – but as a like-for-like replacement for the ArcGIS Enterprise envelope, most of them are a step down, not a step sideways. That is not a reason to ignore them. It is the reason the question matters: the thing that makes Esri hard to leave is exactly the thing that makes depending on it a risk, and the day you discover you have to leave – for whatever reason, commercial, contractual, or because access simply disappears – is the worst possible day to start.

So this is not a cheerful “ditch ArcGIS, go open-source” piece. It is a decision-grade map: what you are actually replacing, what the field looks like by archetype, what the alternatives really cost once you count past the licence, where the lock-in genuinely bites (it is your data, not your software), and how to buy independence before you are forced to spend it in an emergency.

What “leaving Esri” actually means – the envelope you have to replace

Before comparing alternatives you have to be honest about what an Esri geoportal actually does, because “geoportal” is a word people use for very different things. In the enterprise sense – Portal for ArcGIS on top of ArcGIS Enterprise – it is not one capability but a bundle: it serves data as services, catalogues and searches it, lets non-specialists build viewers and apps, supports editing and dashboards, runs analysis, and wraps the whole thing in user management, permissions and security. The catalogue (find the data) and the public hub (show it to stakeholders) are facets of that bundle, not separate products.

That bundle is the bar. An alternative is only an alternative to the extent it covers it, and the first thing you learn looking at the field is that very few single products cover all of it. Some replace the whole bundle, more modestly; some replace one slice brilliantly; and some are not portals at all but the parts you would assemble one from. Keeping the envelope in view is what stops a comparison turning into a list of logos.

ArcGIS alternatives by archetype – from drop-in portal to a box of parts

The cleanest way to hold the field is by archetype: by how much of the envelope a thing intends to cover, and how much assembly it leaves to you.

Open-source, portal-in-a-box. The closest open-source analogues to Portal for ArcGIS are GeoNode, MapStore and NextGIS Web. GeoNode is a geospatial content-management framework built on proven parts – Django, GeoServer, PostGIS and the pycsw catalogue – that serves data, catalogues it to the OGC CSW standard with ISO 19115 metadata, and gives users maps and permissions out of the box; it is a full OSGeo project under a GPL licence. MapStore, from GeoSolutions, is a web-GIS framework for maps, dashboards and “GeoStories” with 2D and 3D (OpenLayers, Leaflet, Cesium) and native OGC support – and it is also the map client GeoNode now builds on, so the two are less separate than a list of names suggests. NextGIS Web is a Web GIS server built around QGIS-centred workflows – publish a QGIS project, edit server-side data from the desktop, and, through the NextGIS Connect sync workflow, version and roll back changes, all served as unlimited web maps through a REST API with fine-grained permissions. A step toward the enterprise end sits geOrchestra: a modular open-source spatial-data infrastructure built for INSPIRE compliance that wires GeoServer, GeoNetwork and a viewer into one administered platform. These come closest to “install it and you have a portal”, which is also why they are the honest reference for how far short of ArcGIS Enterprise a single open-source product still falls on the harder capabilities: advanced analysis, the app-building ecosystem, imagery, 3D at scale.

Open-source, a box of parts. Underneath the portals sits the stack you can assemble yourself: GeoServer, MapServer or QGIS Server to publish OGC services (WMS, WFS, WMTS, WCS), PostGIS as the spatial database, GeoNetwork as the metadata catalogue, pygeoapi to expose the modern OGC API (Features, Tiles, Coverages, Processes), and a front end built from OpenLayers, Leaflet, MapLibre or – for 3D – CesiumJS. Assembled well, this stack covers most of the envelope. Assembling it well is precisely the cost, and it is paid in integration and in-house engineering, not in licences. And the portal is only the server tier: on the desktop QGIS is the open substitute for ArcGIS Pro – and the target of the migration tools mentioned below, since cartography is half the move – while in the field QField and Mergin Maps stand in for the Esri mobile apps.

Commercial, not-Esri. If the objection to Esri is not “commercial software” but “this particular vendor”, there are full commercial platforms. SuperMap, from China, is the closest like-for-like: iServer is an enterprise GIS service platform and iPortal is a genuine GIS portal – no-code site building, multi-source service registration, monitoring, 3D and big-data support – and it comes closer to ArcGIS than anything in open source does, though Esri still leads on imagery, 3D and the depth of its app ecosystem. Hexagon’s LuciadFusion – renamed Octave Alto Server after Hexagon spun its geospatial business out as Octave in 2026 – is an all-in-one geospatial server with full OGC support and exceptional performance, though the line is aimed squarely at aviation, defence and security rather than general enterprise GIS. Bentley (OpenCities) and Smallworld (utilities) each own a slice; Carto and Mapbox sit closer to the cloud-native camp below – the first for spatial analytics, the second for vector-tile web mapping. None of them is a drop-in for an ArcGIS shop, and each brings its own lock-in.

Cloud-native and the building blocks. Finally there are the platform services – Google’s Earth Engine and Maps Platform, AWS Location, Azure Maps – and the web-map libraries – Leaflet, OpenLayers, MapLibre GL, CesiumJS, deck.gl. These are not geoportals; they are capabilities and components you compose into one. They belong on the map because for some needs – a public viewer, one specific analysis – the right answer is a thin app on a cloud service, not a portal at all.

The bill nobody reads – why “free” geoportals are not free

The single most common mistake in this decision is reading the licence line and stopping there. An open-source geoportal has a licence cost of zero and a total cost of ownership that is emphatically not zero. You pay instead in integration – wiring GeoServer, PostGIS, the catalogue and the front end into one coherent, secured, backed-up system; in upgrades and maintenance you now own; in support you either buy from an integrator or supply yourself; and, most expensively and least visibly, in the in-house capability to do all of that. ArcGIS’s price buys you a team you do not have to hire. Take the licence away and that team is the bill.

This is not an argument against open source. Run at scale, with the engineering capability in place, the open-source stack can be both cheaper and more controllable than the commercial equivalent. It is an argument against the comparison that pits an Esri quote against a “free” download, because that comparison is fictional. The real comparison is total cost of ownership against total cost of ownership – and the place open source reliably wins is not always price; it is control, and the absence of lock-in.

Esri vendor lock-in: the data, not the licence

Here is the part the brochures do not cover, and the part that in practice hurts most. The hardest thing about leaving Esri is not standing up a new portal. It is the data.

Esri’s core storage format, the file geodatabase, is proprietary in the strong sense: its internals were never fully published, and for years the only way to write one was through Esri’s own libraries. That particular wall has lowered – since version 3.6 the open-source GDAL reads and writes file geodatabases through its OpenFileGDB driver with no Esri SDK at all – but lowered is not gone. The format is still vendor-controlled rather than an open standard, reverse-engineered support trails what Esri itself guarantees, and the higher-order contents of a geodatabase – topology, networks, domains, relationship classes – do not always survive the round trip. The documents and projects that hold the cartography and configuration are worse: MXD from ArcMap and APRX from ArcGIS Pro remain proprietary with no open writer at all. And note where the trap is not: it is not that ArcGIS refuses to speak open standards – it serves OGC services perfectly well – which is exactly why the lock-in lives in the data and the cartography, not in the wire protocol. Years of an organisation’s work accumulate inside formats one vendor controls, and the moment you try to move it, that control becomes a wall. Tools exist to climb it – SLYR, for instance, converts Esri styles and layer files to QGIS in its free edition, and full MXD and APRX projects in its paid one – but conversion is lossy, laborious, and exactly the work nobody budgeted for. In the forced migrations we have watched, deploying the replacement portal was the easy week; re-homing the data and the cartography that were born in Esri formats was the hard quarter, and it is where the project’s real cost and risk lived. And the data is only the half of the migration you can see: the other half is people – a team fluent in one toolchain has to be retrained on another, and that cost lands at exactly the moment everything else is on fire.

The escape from this is not a product. It is a discipline, and it is an open standard. Data kept in open, specified formats – GeoPackage, the OGC’s single-file SQLite format designed precisely as an open successor to the shapefile and the geodatabase, or simply PostGIS – is data you can pick up and take anywhere, because every tool works from the same published specification. Services exposed through OGC standards – WMS, WFS, WMTS, and the modern OGC API – are services any client can consume, which is what lets a viewer outlive the server that fed it. That interoperability is real but never quite frictionless: “OGC-compliant” still varies by version, profile and edge case, so standards make portability the strong default, not an absolute guarantee. The organisations that find a forced exit survivable are the ones that kept their data portable and their interfaces standard all along. The ones that find it catastrophic are the ones whose crown jewels were locked in a format they did not own.

When access disappears – platform independence as continuity risk

All of which reframes the question. “What are the alternatives to Esri?” is the wrong question to ask in an emergency, because in an emergency there is no good answer: you take the best replacement you can stand up quickly, you discover it is a downgrade, you spend a brutal quarter migrating data, and you find the alternative’s limits constraining the business while you go looking for the next one. We have seen exactly that sequence – a capable open-source portal chosen under pressure, the data-migration wall, and then the slow realisation that the replacement’s ceiling sits lower than the work requires.

The right question is asked years earlier, in calm: how much of our continuity depends on a single vendor whose access we cannot guarantee, and what would it cost us the day that access ends? Vendor lock-in is not a procurement footnote; it is an operational-continuity risk, and like other such risks it is cheap to insure against in advance and ruinous to confront unprepared. It is also the test a commercial replacement quietly fails: swapping one single vendor for another – particularly one in a different jurisdiction whose access you can no more guarantee – can reproduce the exact exposure you are trying to escape. Independence is not a change of captor; it is portability and standards, which is why it cannot be bought as a product. The insurance is not a second platform on the shelf. It is keeping your authoritative data in open formats, your services on OGC standards, your cartography reproducible outside one toolchain, and a tested understanding of what your portal would actually run on if you had to move. Independence is not something you buy in the week you need it. It is something you maintain so that the week you need it is survivable.

Choosing without illusions

So choose with the envelope, the bill and the lock-in all in view, not the logo. Match the alternative to how much of the ArcGIS Enterprise envelope you genuinely use – a team that needs publishing, a catalogue and viewers is in very different territory from one leaning on advanced analysis, imagery and the app ecosystem. Weigh total cost of ownership, not licence price, and be honest about the in-house capability the cheaper-looking option demands – and about the cost of retraining a team off one toolchain onto another, which is the half of a migration that is not data. And weight data portability and standards compliance heavily, because they decide whether this move, or the next forced one, is a project or a crisis. Independence rarely means a full rip-and-replace, either: more often the pragmatic estate is hybrid – keep the commercial platform where it genuinely earns its licence, move what you can onto open formats and standard services, and measure success not by how much you have replaced but by how survivable a forced exit would be.

The trade-off across the archetypes, on the axes that actually decide it:

Archetype	Envelope coverage	Cost reality (TCO)	Data lock-in	Integration / in-house need	Forced-exit resilience	OGC standards
OSS portal-in-a-box (GeoNode, MapStore, NextGIS Web)	core publish / catalogue / viewers; weaker on advanced analysis, apps, 3D	zero licence, moderate TCO	low – open formats native	moderate; some GIS engineering	high (self-host, open)	native
OSS box-of-parts (GeoServer, PostGIS, GeoNetwork, pygeoapi + JS front end)	most of the envelope, if assembled	zero licence, high build-and-run TCO	low	high; needs a real team	high	native
Commercial non-Esri (SuperMap, Hexagon/Octave, Bentley)	high – SuperMap closest to Esri	commercial licence + integration	medium – new vendor formats and lock-in	low to moderate	medium – still vendor-dependent	good, varies
Cloud-native / libraries (Google, AWS, Azure, Carto; Leaflet, OpenLayers, MapLibre, Cesium)	components, not a portal	usage-based; scales fast, can surprise	varies; data usually stays yours	high – you build the portal	varies	varies

Read it as the thesis in a grid: the further you move from the commercial box toward the parts, the more you trade licence freedom and portability for the integration effort and in-house capability you have to bring yourself. There is no free move, and no drop-in equal of ArcGIS Enterprise in the open-source world. What there is, is a set of honest options – and one discipline that makes any of them reachable without a crisis: own your data in open formats, speak OGC, and decide before the day you are forced to.