ArcGIS Online alternative: the open source options, one by one

Why look for an alternative

ArcGIS Online is Esri's online GIS platform: web maps, hosted layers, apps, field data collection and sharing, in one subscription service. The model is built on user types and on credits, consumed by storage, geocoding and some analyses.

The reasons to look elsewhere are often the same: a license budget that is hard to predict, teams already working in QGIS, a wish to keep standard formats and services, or the need to host data in a given country or on your own servers. The open source world does not offer a single equivalent product, but a set of tools that, put together, cover the essentials.

According to Esri's documentation, credits pay in particular for hosted layer storage, batch geocoding of address tables, analyses, printing and route calculation, while using basemaps or a single address search is free. Cost therefore follows actual use, which is flexible but makes the annual budget harder to predict as volumes grow. Comparing options therefore means estimating your real yearly usage, not just the entry price. For many public bodies, the question of where data is hosted, and under which jurisdiction, also weighs in the decision.

ArcGIS Online alternative: component by component

This table compares uses, not identical products. We do not quote Esri prices: ArcGIS Online pricing depends on user types and credits, so check Esri's official page for a current figure.

Getting your data out: formats and precautions

Before choosing a tool, look at what you can take out of ArcGIS Online, and in what form. According to Esri's documentation, a hosted feature layer can be exported to CSV, Excel, shapefile, file geodatabase, GeoJSON, feature collection, KML and GeoPackage. Exporting is limited to the layer owner and organization administrators, unless the layer is configured to allow others to export the data: check this setting before splitting the work among several people.

In practice, prefer GeoPackage for layers without attachments, and file geodatabase for those carrying field photos. Avoid shapefile as a transit format: truncated field names and lost null values create silent errors that surface weeks later. During the transition, QGIS can also connect directly to an ArcGIS REST server to display feature or map services, which is useful for comparing the old and new setups side by side before you switch users over.

Lizmap and QGIS Server for web maps

Lizmap turns a QGIS project into a web map portal served by QGIS Server. The map looks exactly as you designed it in QGIS, with no styles to rewrite. Web-specific settings (which tools are shown, which layers can be queried, edited or hidden, the initial extent) are configured in the Lizmap plugin for QGIS Desktop, then published with the project. There is no second interface to learn: a GIS specialist who knows QGIS can handle publishing within a few hours, and the whole configuration travels with the project file.

• Viewing: layers, legend, search, popups, printing from QGIS print layouts.
• Online editing of PostGIS layers, with forms defined in the QGIS project.
• Access rights per user group, per project and per layer.
• Charts built into maps through Lizmap's data visualization tool.

For a detailed comparison, read Lizmap or ArcGIS Online, and for setup, hosting Lizmap or installing it yourself.

An advantage for teams already trained: there is only one authoring tool, QGIS Desktop. The printed map, the desktop map and the web map share the same project. A style change made in QGIS appears online at the next publication, with no double entry or conversion.

GeoServer and GeoNode to share and catalog

GeoServer publishes your layers as WMS, WFS, WCS and WMTS, readable by every OGC client, ArcGIS included. It is the equivalent of the feature and map services you share from ArcGIS Online. See online GeoServer hosting and the choice between GeoServer, MapServer and QGIS Server.

GeoNode adds a catalog: metadata records, search, maps composed in the browser, per-resource permissions. It runs on GeoServer itself. It is the closest building block to an open data portal. Because GeoNode stores its data in PostGIS and publishes it through GeoServer, the layers you catalog there remain usable as standard OGC services anywhere else, including in QGIS, Lizmap or ArcGIS. For an organization that must publish reference data, it is often the piece most missing from a plain map portal: readable records that say where the data comes from, when it was last updated and under which license it can be reused. Those records are what make a dataset findable and trustworthy for people outside your team.

QField for field data collection

QField is an open source mobile app that opens your QGIS projects on Android and iOS, online or offline. Forms, value lists and constraints defined in QGIS carry over to the field. In practice, field staff open on their phone or tablet the same project as the office, with its basemaps, layers and forms. Without a network they keep collecting; their entries, photos included, stay on the device until the next sync. Input checks defined in QGIS, such as a required field or a bounded value, apply in the field before anything is sent, which avoids fixing mistakes back at the office.

Synchronization sends field data back to the office. With LizPack Field, it relies on the same technology as QFieldCloud, and on the Pro plan, records are written to your PostGIS database: the Lizmap map showing them updates on every sync.

For a team that collects today with Esri mobile apps, the change is mostly in preparation: the form is no longer built in a web tool but in the layer properties of the QGIS project. In return, the same project serves the office, the field and the web portal. Plan a pilot campaign with a few field staff before rolling out, to adjust value lists, photos and constraints. Field staff keep a familiar experience: a map, a form, photos and GPS positions, on their own phone or tablet.

Migrating from ArcGIS Online: the process

Leaving an integrated platform takes preparation. The good news: your data is not locked in. According to Esri's credits documentation, exporting data is one of the operations that consume no credits. Most of the work is rebuilding maps and forms.

1. Inventory the content actually in use: hosted layers, maps, apps, field forms, and who relies on them.
2. Export hosted layers to an open format, then load them into a PostGIS database from QGIS or with the usual PostgreSQL tools.
3. Rebuild maps in QGIS: symbology, labels, print layouts. This is the longest step; it is also a chance to clean up.
4. Publish projects with Lizmap, and layers meant for partners with GeoServer.
5. Recreate field forms in QGIS (widgets, value lists, constraints) for QField, and test offline before the collection season.
6. Run both systems in parallel for a few weeks, share the new URLs, then shut down the old one.

One timing point matters: according to Esri's documentation, an organization that runs out of credits enters a restricted state where members can still view existing content but can no longer publish layers. So plan the migration before your subscription period ends, not after. If you want help rebuilding projects, our services offer it on quote. On the budget side, the switch is easier to manage in stages: first the viewing maps, which need little rebuilding, then online editing, and finally field collection, avoiding a change of tool in the middle of a survey season. Each stage can be validated and paid for separately, which keeps the risk under control.

Common migration mistakes

Migrations that go off track tend to look alike. The problems almost never come from the open source tools themselves, but from data or organizational details that were not inventoried at the start.

• Forgetting attachments. A layer exported to GeoPackage or shapefile loses its photos. Export layers that have them to file geodatabase, and plan where they will be stored before importing.
• Going through shapefile. Fields such as field_inspection_date become truncated names, and empty values turn into zeros. Filters and forms that relied on those fields stop working.
• Overlooking value lists. The pick lists of a form do not always travel with the data. Write them down before exporting, then recreate them in the layer properties of the QGIS project, for Lizmap and for QField alike.
• Recreating accounts too late. Groups and access rights must be rebuilt. List the users and what each one must see or edit before opening the new portal.
• Breaking shared links. The URLs of maps and apps embedded in a website or sent by email will change. List them so you can warn recipients and update the pages concerned.
• Migrating everything at once. Start with a simple, low-stakes map, validate it with its users, then move on to the others.

Finally, keep a complete, dated copy of the exports even after the switch: it is your fallback if a piece of data turns out to be missing during checks.

Three typical situations

• A local government that publishes a local plan and collects field data. The core need is a public viewing map for residents, an editing map for technical departments and mobile data collection. Recommended stack: PostGIS for the data, QGIS Server and Lizmap for both maps, with per-group permissions, and QField for field staff. Records written to PostGIS appear in the Lizmap map on every sync.
• A consultancy that delivers data to its clients. The main need is to share clean, documented layers that open in each client's tools, often ArcGIS. Recommended stack: PostGIS and GeoServer, with WMS and WFS services per project, plus a Lizmap portal for presentation maps.
• An organization that shares open data. The need is a catalog: metadata records, search, downloads. Recommended stack: GeoNode, which relies on GeoServer and PostGIS, complemented by a Lizmap portal for thematic maps.

In all three cases the software is the same; only the combination changes. At LizPack, these correspond to LizPack Map, GeoServer Cloud, LizPack Field and LizPack Catalogue, which you can combine to match your situation and adopt step by step, starting with the part that matters most to your users.

What remains simpler with Esri

• One vendor, one account. Everything is integrated from the start; with open source you assemble several tools, or rely on an open source geospatial infrastructure such as LizPack that assembles them for you.
• Ready-made apps: dashboards, story maps, no-code app builders. Open source equivalents partly exist but take more configuration.
• Reference content: basemaps, demographic data and geocoding services included with the subscription.
• The ArcGIS Pro ecosystem: if your teams build maps in ArcGIS Pro, staying with Esri avoids converting projects and retraining on QGIS.

If these points weigh heavily for you, ArcGIS Online remains a good choice. If your priority is QGIS, open formats and controlled costs, the open source stack is mature. LizPack, an open source geospatial infrastructure, hosts and connects it for you without replacing any of these tools: see what LizPack does and the cost of an open source web GIS. To decide without gambling, run a real trial: publish one of your existing maps with Lizmap and one of your layers with GeoServer, have the people concerned use them for a few weeks, then compare time spent, user satisfaction and the estimated yearly cost of both options. A trial on your own data answers questions that no comparison table can.

Frequently asked questions