GIS operations
and backend support
that actually works

The setup: ArcGIS Enterprise 10.9 → 11.0 upgrade. Portal, Server, and Data Store all upgraded in the right order (Data Store → Portal → Server). The upgrade logs showed no errors. But Portal refused to start — portalstartup.log ended with a timeout on CreateSite.

The search: Two days of log combing, ESRI support threads, rebuild attempts. Portal kept hanging on Initializing Portal Admin.

The fix: The IIS Web Adaptor had a stale SSL binding pointing at the old Portal URL. The upgrade had changed the internal port Portal listens on, but the Web Adaptor was still forwarding to the old one. Reconfigured the binding, restarted IIS, Portal came up in 30 seconds.

Lesson: Web Adaptor configs don't update themselves during upgrades. Always check the reverse proxy / adaptor bindings before and after. Saved the client a full reinstall.

The symptom: Client reported Portal was "getting slow" over two weeks. Maps took 20+ seconds to load. Services randomly timed out. No obvious errors in the UI.

The check: First thing — disk usage. Portal Server's arcgisserver/logs directory had grown to 47 GB. The log rotation had been disabled during a previous config change and no one noticed. The OS itself started thrashing because the root partition was 98% full.

The fix: Cleared archived logs (safe — everything older than 7 days), re-enabled log rotation to 14-day max, set a log level from FINE back to WARNING (the root cause was someone had turned up logging for debugging and never turned it back down). Freed 42 GB. Server back to normal within the hour.

Lesson: "Slow server" is a storage problem more often than a compute problem. Check disk first, logs second, RAM third, CPU last. And always verify log rotation after any config change.

The job: Migrate a county planning department from a legacy ArcSDE geodatabase (SQL Server) to an ArcGIS Enterprise geodatabase (PostgreSQL 14 + PostGIS). About 80 feature classes, 15 relationship classes, and a handful of geometric networks.

The problem: Direct data export and import worked fine for the geometry. But all the relationship classes broke because the SDE schema used ObjectID fields that didn't map cleanly to the Enterprise geodatabase's expected GDB_OBJECTID pattern. Also, the geometric networks used topologies that aren't natively supported in Enterprise geodatabases the same way.

The approach: Instead of a straight ETL, we wrote a migration script that (1) rebuilt the feature classes in the target schema, (2) remapped the foreign keys using the new ObjectID values post-import, (3) replaced geometric networks with relationship classes and topology rules that enforced the same behavior. Then validated every relationship by running a test query against 5% of the data.

Result: Two weeks of planning, three days of migration work, one day of validation. Client had zero data loss and all applications continued working without code changes.

Lesson: Schema mapping is 80% of the work in a geodatabase migration. The actual data move is the easy part — understanding how the schema maps (and where it breaks) is where the value is.