Skip to content
GEOSAT
Back to blog
Open GIS
Open GIS2026-09-23GEOSAT6 min read

How to replace ArcGIS applications by workflow

Break down viewers, dashboards and collection; identify what needs building and maintaining.

Editorial review: 2026-09-23

ArcGISMapLibreQFieldPostGISOpen GIS

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

WorkflowPossible componentsWork that remains
Query viewerMapLibre or Leaflet, API, basemapPermissions, search, accessibility, printing
Operational dashboardWeb application, SQL queries, mapIndicator definitions, refresh, filters
Offline collectionQGIS, QField, synchronizationForms, conflicts, attachments, support
Map publicationPostGIS, GeoServerStyles, caching, security, operations
Feature integrationPostGIS, pygeoapiContracts, 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 behaviorConcrete acceptance exampleLikely hidden dependency
Search by asset codeExact identifier returns one authorized recordStable key and data permissions
Address searchKnown address resolves within the required areaGeocoding source and usage terms
Dashboard indicatorSame period and filters return reconciled countsMetric definition, timezone and refresh
Export selectionAuthorized rows, fields and CRS in expected formatExport service and data policy
Print reportSame required facts and readable layoutFonts, legend, page size and server rendering
Share linkRecipient reopens allowed view without leaked accessURL 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.

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.

Related articles