// migration

Migrate in measured steps.
Automate what can be proven.

Inventory the estate. Import supported Esri services. Convert supported source. Validate client behavior. Run old and new side by side before cutover. GeoServer has a bounded public catalog path: scan, dry-run, then apply workspaces, layer groups, and PostGIS-backed layers whose target tables already exist; data copying and unsupported stores remain manual. The public JavaScript prerelease and Python source preview include honua-migrate codemods. Honua does not yet ship an automated .NET or .NET MAUI source rewriter; those applications follow a guided reimplementation path with adapters.

Discuss your migration Compatibility →

public JS prerelease · example output

→ npx @honua/honua-migrate@0.1.0-beta.0 codemod ./webmap-app \
    --target honua-compat --write --report parity.json
  analyzing source files...
✓ FeatureLayer / MapView / Map  rewritten
✓ Query options                 deep-transformed
✓ reactiveUtils.watch accessors rewritten
✓ event names remapped          layer-view-created · …
 
ℹ parity is partial · gaps in docs/migration-punch-list.md
→ report written to ./parity.json
# public npm prerelease; numbers come from your run

// JS public prerelease · Python source preview · .NET + MAUI guided path

One migration playbook. Automation where evidence supports it.

Automate supported transformations, report every change, and flag the rest for review. JavaScript is a public npm prerelease and Python is a source preview. .NET and MAUI are source-preview SDKs with guided migration paths because Honua does not yet ship automated source rewriters for them.

JavaScript SDK

@honua/sdk-esri-compat@0.1.0-beta.0 · scanner + codemod

public prerelease

$npx @honua/honua-migrate@0.1.0-beta.0 codemod ./webmap-app --target honua-compat --write

@arcgis/core → @honua/sdk-esri-compat

// what the converter rewrites

import paths & barrel re-exports
FeatureLayer · MapView · Map constructors
portal references & webmap content
renderer / symbol / popup wiring

honua-sdk-js · Vitest + Playwright in CI

.NET

.NET SDK

Honua .NET · source preview · guided reimplementation + adapters

guided path

$# guided reimplementation + adapters — no automated .NET source rewriter

ArcGIS Runtime .NET → Honua .NET

// what the migration guide maps

Esri.ArcGISRuntime usings → Honua namespaces
Map · MapView · GraphicsOverlay ctors
FeatureTable · ServiceFeatureTable
PortalItem & WebMap loaders

honua-sdk-dotnet · integration suite

Python SDK

honua-migrate · scan / translate / run

source preview

$python -m honua_sdk.migration scan ./scripts/analysis.py

ArcPy source file → scoped migration plan

// what the codemod does today

detects ArcPy calls in one Python source file
classifies recognized tools as translatable, manual review, or unsupported
translates only registry-listed, server-executable calls to OGC API Processes payloads
emits parity evidence for review before any translated plan is run

source checkout · scan / translate / run · parity evidence per run

MAUI

Mobile SDK · .NET MAUI

honua-mobile · source preview · guided reimplementation + adapters

guided path

$# guided reimplementation + adapters — no automated MAUI source rewriter

ArcGIS Maps SDK · MAUI / Xamarin → Honua MAUI

// what the migration guide maps

MapView / SceneView → native display adapter
ServiceFeatureTable → Honua query client
GeodatabaseSyncTask → planned GeoPackage offline-sync path
FeatureForm / OpenRosa → private-beta connected field schemas; offline workflows planned

honua-mobile · field-collection-first · migration guide ↗

// js converter · example output

Here's what one of those rewrites looks like.

A representative honua-migrate codemod diff. Where the compatibility package supports a call site, familiar class shapes reduce code churn while Honua replaces the runtime, transport, and infrastructure underneath. The codemod does not repoint service URLs; the unchanged ArcGIS URL below keeps that separate migration step visible.

honua-migrate codemod · diff webmap-app/src/MapView.jsx

BEFOREArcGIS JS API · v4

// hand-maintained ArcGIS JS app

import Map from "@arcgis/core/Map";

import MapView from "@arcgis/core/views/MapView";

import FeatureLayer from "@arcgis/core/layers/FeatureLayer";

const map = new Map({ basemap: "streets-navigation-vector" });

const view = new MapView({ container: "viewDiv", map });

const parcels = new FeatureLayer({

url: "https://gis.acme.gov/.../Parcels/FeatureServer/0",

});

map.add(parcels);

AFTER · AUTOMATED SOURCE REWRITE@honua/sdk-esri-compat

// imports + constructors rewritten; endpoint repointing remains manual

import { MapCompat, MapViewCompat, FeatureLayerCompat } from "@honua/sdk-esri-compat";

const map = new MapCompat({ basemap: "streets-navigation-vector" });

const view = new MapViewCompat({ container: "viewDiv", map });

const parcels = new FeatureLayerCompat({

url: "https://gis.acme.gov/.../Parcels/FeatureServer/0",

});

map.add(parcels);

// migration path

Lower switching cost with compatibility + checks.

Migration support and adoption value by path
Path	Migration support	Adoption value
Esri service import	Documented imports accept queryable FeatureServer and MapServer service roots, copy selected layers into PostGIS, and publish them. Unsupported renderers, external symbols, attachments, and other flagged content require manual follow-up.	Existing Esri clients validate against Honua before any cutover.
App conversion (supported SDK conversion)	The public JavaScript prerelease rewrites supported ArcGIS JS imports, FeatureLayer / MapView / Query / reactiveUtils constructors, and call sites to `@honua/sdk-esri-compat`. Python exposes a source-preview scan / translate / run flow. .NET and MAUI use guided reimplementation plus adapters; no automated source rewriter is available for those paths.	Supported call sites can be rewritten automatically. Each run reports its automation ratio; remaining call sites carry a `TODO(honua-migrate)` marker for review.
GeoServer service import	The public path scans and dry-runs a GeoServer REST catalog, then explicitly applies bounded catalog entries for existing target PostGIS tables. It does not copy feature data; unsupported stores, missing tables, external graphics, and lossy SLD conversions remain manual-review evidence.	Load data separately, review every apply step, and validate WMS/WFS/WMTS clients while the existing GeoServer service remains available for rollback.
Standards & data ingestion	Available paths cover documented OGC and GeoServices surfaces plus supported files, databases, and object-storage formats; coverage varies by source and operation.	Move service by service, dataset by dataset. No big bang.
Parity checks	Each JavaScript codemod run reports detected source usage, rewritten and manual-review call sites, TODO markers, and readiness gates. It does not execute behavioral response comparisons.	Run client and response-behavior tests separately; estate-wide parity reporting remains planned.

// adoption model

Run old and new together.

01 · ASSESS

Inventory.

List the services, data sources, clients, and operations that must continue. Match each workflow to public compatibility evidence and record the gaps before changing an endpoint.

02 · PILOT

Import and convert.

Choose one representative service and application. Import only through a documented source path, use automation where the supported SDK allows it, and keep unsupported metadata and call sites visible for review.

03 · VALIDATE & CUT OVER

Run side by side.

Compare responses and client behavior against the existing system. Move an endpoint only when its required workflow passes, then repeat service by service.

// next

Assess the estate. Pilot one workflow.
Cut over when the evidence is ready.

Discuss your migration Compatibility Try the JavaScript codemod ↗

Migrate in measured steps.Automate what can be proven.