// proof hub · migration evidence

Prove the migration one workflow at a time.

A safe migration begins with the estate you actually run: its services, clients, authentication flows, extensions, data, and non-negotiable workflows. Honua provides public inventory tooling and operation-level compatibility evidence for an Esri assessment. A public GeoServer migration guide ↗ documents a bounded catalog scan, dry run, and apply path for PostGIS-backed layers whose target tables already exist; it does not copy feature data or eliminate manual review.

Inventory an Esri footprint with the open, read-only assessment tool, or scan a GeoServer REST catalog through Honua's bounded server path.
Validate every required client workflow against documented operation and parameter coverage.
Pilot representative data and workloads before planning a staged cutover.

Step 1 — Inventory the Esri footprint

honua-io/honua-esri-assess is Apache-2.0 footprint-assessment tooling — deliberately open so evaluators can audit the code before running it against their own ArcGIS Online, ArcGIS Server, or FileGDB inventories. It produces a versioned EsriFootprint.json artifact.

Scanner boundary: network inventory uses GET-only requests, while local FileGDB scans read metadata from the specified files. The tool does not modify a source, mint credentials, contact a database server, or send network telemetry by default. It accepts credentials only through --token-env VAR; logs record the environment-variable name, not its value.

Supported sources:

Step 1 — Inventory the Esri footprint with read-only scans
Source	CLI surface	Notes
ArcGIS Online	`scan agol --target <…/sharing/rest>`	Portal Sharing REST API, read-only
ArcGIS Server	`scan server --target <…/arcgis/rest>`	ArcGIS Server REST service metadata, read-only
FileGDB (descriptor)	`scan filegdb --target <path>`	Reads a local `_inventory.json` descriptor; no network
FileGDB (workspace)	`scan filegdb-workspace --target <path.gdb>`	Read-only `pyogrio`/GDAL metadata on a local `.gdb`
RBAC / access	`scan rbac --target <portal-or-server-admin-url>`	Read-only identity/RBAC posture into `EsriAccessFootprint.json`

Install status: no PyPI package is published yet; issue #81 ↗ tracks registry publication. Until then, install the verified 0.7.1 source revision by immutable commit:

pipx install 'honua-esri-assess[filegdb] @ git+https://github.com/honua-io/honua-esri-assess.git@c4dccd9db14836e3227143e6944baef6b1369534'
export AGOL_TOKEN="..."
honua-esri-assess scan agol \
  --target https://yourorg.maps.arcgis.com/sharing/rest \
  --token-env AGOL_TOKEN \
  --output EsriFootprint.json --validate
honua-esri-assess report --input EsriFootprint.json --output readiness-report.md

The filegdb extra installs pyogrio for workspace scans; it is not required for REST or descriptor-only inventory.

The repository publishes the EsriFootprint.json v0.1 schema, an example artifact, an example readiness report, and the handoff contract between this open assessment tool and Honua's commercial migration service. The v0.x schema may change; stability begins with v1.0.

Step 2 — Validate the workflows that must keep working

After the data lands in Honua, use the Compatibility Matrix to map each required operation and parameter to public evidence. Then run the actual ArcGIS Pro, ArcPy, SDK, and raw GeoServices workflows in the migration scope against the exact Honua revision or pilot build you are evaluating.

The site demos illustrate selected paths; they are not a substitute for testing the customer's versions, authentication flow, extensions, and operation inventory.

Esri Leaflet / GeoServices demo: honua.io/demo-esri-leaflet.html
Two-protocol (same data via Esri REST and OGC) demo: honua.io/demo-two-protocols.html
Editing round-trip demo: honua.io/demo-editing.html

Step 3 — Pilot before cutover

Run representative data, permissions, clients, and operations against the exact Honua revision or pilot build you plan to adopt. The Benchmarks page can inform test design, but its April 28 snapshot is historical and not an independently reproducible release result. Use your pilot—not that snapshot—as the performance and capacity basis for a cutover decision.

Current migration boundaries

The public parity matrix is the source for current gaps. At planning time, treat these surfaces as follows:

FeatureServer, MapServer, and ImageServer: partial parity; inventory every required operation and parameter.
GeocodeServer, NAServer, and GPServer: partial and provider/task dependent; test the configured workflows directly.
Geometry Service: documented operations are implemented; parameter and spatial-reference behavior still requires workload testing.
Desktop clients: versions and connection behavior are not represented by a blanket checkbox; validate them in the target environment.

See the public GeoServices operation matrix ↗ and client limitations ↗ for the current source of truth.

No estate-wide compatibility percentage. A public readiness-report result has not been published. Compatibility remains scoped to documented operations and your validation run.

GeoServer automation is bounded. The public path scans and dry-runs the REST catalog, then applies workspaces, layer groups, and PostGIS-backed layer entries only when the corresponding tables already exist in the target Honua database. Copy feature data separately; unsupported stores, missing tables, external graphics, and lossy SLD conversions remain explicit manual-review or unsupported evidence.

No public customer case study. Honua has not yet published a customer migration with a measured scope, timeline, and outcome.