How to replace ArcGIS applications by workflow
Break down viewers, dashboards and collection; identify what needs building and maintaining.
Editorial review: 2026-09-23
Start with the user's task
“Replace ArcGIS” does not define an acceptance test. “An inspector retrieves an order, captures an offline photograph and delivers a traceable result” does. List tasks and dependencies with the people who perform them, including reports produced only once a year.
Map components without promising equivalence
| Workflow | Possible components | Work that remains |
|---|---|---|
| Query viewer | MapLibre or Leaflet, API, basemap | Permissions, search, accessibility, printing |
| Operational dashboard | Web application, SQL queries, map | Indicator definitions, refresh, filters |
| Offline collection | QGIS, QField, synchronization | Forms, conflicts, attachments, support |
| Map publication | PostGIS, GeoServer | Styles, caching, security, operations |
| Feature integration | PostGIS, pygeoapi | Contracts, limits, identity, versions |
A mapping library alone does not replace Dashboards or Experience Builder. A web form also does not reproduce offline collection with relationships and attachments.
Build a vertical test
Choose a frequent task with manageable risk. Use ten fictional records and an authorized identity. Complete the journey from creation through consultation and export; repeat it without permission, without connectivity and with a failed request. Record task time, manual steps, errors and lost data.
When a capability requires development, estimate construction and maintenance separately. Include identity integration, basemaps, geocoding, routing and third-party formats. Do not attribute all these services to the current application license: they may have independent contracts.
Decide by capability
Temporarily retain ArcGIS components serving a specialized dependency without a validated alternative. Migrate capabilities with portable data and contracts first. The result may be hybrid: existing clients on a shared source, new open services and a different application for a new process.
Before cutover, establish where writes occur, how competing authoritative sources are avoided and how rollback works. Redirecting a link does not migrate permissions or history. The final decision should combine functional results, operational workload and coexistence costs.
Inventory capabilities at the level a user notices
Open the existing application with a representative user and list observable tasks. Include saved filters, deep links, printing, exports, attachments, mobile behavior, permissions and integrations. Record rarely used but mandatory tasks such as annual reporting; frequency alone does not determine importance.
For each capability, assign one of four outcomes: reproduce, improve with an agreed change, retain temporarily or retire with the user's agreement. Avoid an ambiguous “supported” label. A replacement may support map search while lacking the address source, ranking or geographic coverage users depend on.
| Existing behavior | Concrete acceptance example | Likely hidden dependency |
|---|---|---|
| Search by asset code | Exact identifier returns one authorized record | Stable key and data permissions |
| Address search | Known address resolves within the required area | Geocoding source and usage terms |
| Dashboard indicator | Same period and filters return reconciled counts | Metric definition, timezone and refresh |
| Export selection | Authorized rows, fields and CRS in expected format | Export service and data policy |
| Print report | Same required facts and readable layout | Fonts, legend, page size and server rendering |
| Share link | Recipient reopens allowed view without leaked access | URL state and identity |
Build a complete small replacement slice
Use the synthetic lab to implement asset search, detail, map highlight and a permitted download. Define the API response before building widgets. Include the stable identifier, display fields and a clear indication of data version. Keep personal or restricted attributes outside the public representation.
Test the same task through a table and a map. If a record lacks geometry, its details should remain reachable. If a service fails, preserve the search criteria and show a retry path. If access expires, do not silently display stale confidential data as if the request succeeded.
For a dashboard, write the metric definition in ordinary language before writing SQL. Does “inspected” mean a submitted observation or an accepted one? Is the denominator active assets today or assets assigned at the start of the period? Two polished charts can disagree because they answer different questions. Reconcile the metric with the operational owner using a small known batch.
Plan coexistence as a data problem
A temporary hybrid application can read an existing supported service while a new workflow is built. That reduces the number of moving pieces, but it may retain licensing and service costs. Include those costs explicitly. Do not count a server as retired while the new application still calls it for search, identity or printing.
Choose a single intended write authority for each data domain. If two systems must write, design and test synchronization, conflict resolution and delete handling. A nightly export creates a snapshot, not live shared editing. Make refresh time visible where it affects decisions.
Test migration failures before changing the link
Simulate an expired session, denied record, timeout, oversized response, empty result, missing attachment and duplicate submission. Verify that errors do not turn into misleading success messages. Test deep links after signing in and make sure the user returns to the intended record rather than a generic home screen.
Preserve important public URLs or provide deliberate redirects when retiring a viewer. For internal apps, identify saved bookmarks and embedded links in reports. Search-engine redirects and authenticated application state have different requirements; test both if the old tool is public.
Estimate ownership beyond the first build
Include upgrades, monitoring, accessibility fixes, security maintenance, data contracts and incident response. An open-source component reduces dependence on one implementation vendor only when the organization receives source code, configuration, documentation and a realistic way to operate it. A custom application maintained by one unavailable developer can create another form of dependency.
End the pilot with a capability-by-capability decision and an estimate based on observed work. Use the Enterprise comparison for infrastructure scope and the TCO model for retained components and transition costs. Retire the old application after the replacement's tasks, recovery and data ownership are demonstrated.
Sources and documentation
Next step
Continue in the Open GIS collection. For a specific project, use the total-cost calculator and request an assessment.