Replace ArcGIS services with GeoServer: a compatibility matrix

Replacing an ArcGIS service requires replacing its consumer contract. A GeoServer WMS endpoint can supply a map to a compatible client, but it does not become an ArcGIS REST MapServer when you rename a reverse-proxy path. Inventory the operations used by applications before choosing a target.

Build an inventory from requests, not screenshots

Start with one application and follow its requests during a real task: open a map, search a record, select a feature, edit an attribute and export a result. Capture only synthetic or authorized data; redact tokens. Record the resource URL, method, parameters, response schema, authentication, error behavior and caller. Repeat for scheduled jobs and desktop consumers, which may never appear in browser logs.

A service with ten layers may be simple if it only draws images. A single FeatureServer with attachments, related records, sync and offline editing can be a larger migration. The public service list is therefore a starting point, not a complete dependency inventory.

The ArcGIS REST feature service reference and GeoServer WFS reference describe different contracts. The table is a migration design, not a claim of automatic equivalence.

Choose a migration pattern for each caller

Change the caller when the application is maintained and can consume an OGC endpoint directly. This usually makes the final architecture easier to understand. Keep a compatibility adapter only when its supported operations are small and explicit; budget tests and maintenance for every emulated behavior. Retain an ArcGIS service when an essential application or specialized capability still depends on it. A hybrid architecture can remove public read workloads while preserving a specialized editing system.

Do not create a universal REST emulation layer as the first task. An adapter that passes a single query request but silently drops pagination, domains or time filters can produce plausible and incorrect results. Mark unsupported operations explicitly and prevent the caller from assuming success.

Compare results with a fixed fixture

Create five representative records: ordinary polygon, multipart geometry, missing optional value, accented text and a date around a timezone boundary. Add two records sharing a related parent, if relationships matter. Use immutable identifiers. For each supported query compare the identifier set first, then geometry and attributes. Count alone will miss duplicates paired with missing records.

For images, fix extent, dimensions, CRS and scale; compare line thickness, labels, transparency and legend. Cartographic acceptance should name tolerances and exceptions. For editing, test simultaneous changes from two users, permission revocation, validation failure and replay of a request. A basic WFS transaction is not proof of ArcGIS branch versioning or business approval semantics.

Protect the cutover

Publish the candidate under a separate hostname or path. Run a representative caller against it while the original remains authoritative. During the transition, define one writer per dataset or a deliberate synchronization mechanism; “both teams can edit wherever they prefer” creates an uncontrolled conflict problem.

Cut over callers in small groups and keep rollback configuration ready. If edits have already occurred in the new system, rollback also needs a data reconciliation procedure. Switching DNS alone does not move those edits back. Retire an old endpoint only after checking application logs, scheduled jobs and known consumer owners over a meaningful business cycle.

Troubleshoot misleading successes

The next concrete step is the PostGIS-to-GeoServer publication exercise. For the broader platform, use the ArcGIS Enterprise comparison. Bring your operation inventory to an assessment; it supports a much more defensible estimate than counting map services.