- Migration scope depends on the estate, dependencies, target platform, and review requirements
- Failures often trace to undocumented dependencies and tacit knowledge missed during discovery
- Automation can support inventory, analysis, translation, and deployment, but requires validation and human review
- Custom ArcObjects COM code, highly custom FME transformers, and undocumented business rules need a separate review path
Quick Answer
This retained article describes a historical manual-migration model. Current time and cost depend on the estate, dependencies, target platform, discovery, translation, validation, training, procurement, and operations. Complex COM code and undocumented business logic require separate review; no generally available automated migration service is described here.
A migration review may include a statement of work, discovery workshops, code analysis, data conversion, validation, and operational planning. The current scope and price must come from the target estate, not from this retained article.
The retained article compares manual work with automation patterns. Current tooling still needs bounded inputs, validation, human review, and explicit limits. Here is what can take time in a GIS migration and why the failure modes matter.
The Historical Manual Market Context
GIS is deeply embedded in utilities, insurance, infrastructure, government, and environmental consulting. Most of these organisations built their spatial workflows on desktop GIS -primarily ArcPy scripts running against file geodatabases, FME workbenches moving data between systems, and QGIS projects with Python plugins for analysis.
Cloud migration pressure can come from support dates, storage, processing, collaboration, procurement, or operating requirements. The retained market-size estimate is historical context, not a current market measurement.
HISTORICAL PLANNING ILLUSTRATION — VERIFY CURRENT INPUTS
Historical illustration only. A current model needs estate scope, dependencies, target platform, labour, infrastructure, validation, and ownership assumptions.
The useful lesson is that calendar time is not determined by file count alone. Discovery, stakeholder decisions, sign-off cycles, validation, procurement, and operational ownership can dominate the work. The retained workflow counts and timeline are not a current forecast.
What a Manual GIS Cloud Migration Actually Looks Like
A consulting engagement follows a predictable eight-step process. Understanding each step shows exactly where the time goes -and which steps are genuinely human problems versus which ones are automation waiting to happen.
Inventory (Week 1)
A discovery review may cover file servers, SharePoint folders, network drives, ArcPy scripts, FME workbenches, QGIS projects, and ModelBuilder models. The inventory can differ from an owner's initial estimate; the actual count must come from the target estate and its verifier.
Dependency Assessment (Week 1-2)
Each script is read manually to map what it calls, what data it reads, and what it writes. This uncovers hardcoded file paths pointing to \\server\gis\layers, scripts that call other scripts, and FME workbenches that reference ArcSDE connection files that may no longer exist.
Business Logic Capture (Week 2)
Workshops with the GIS analysts who wrote the scripts. The code rarely explains why a buffer is 250 metres rather than 200 metres, or why a particular spatial join uses the third geometry in a multi-part polygon. That knowledge lives in people's heads. Consultants run structured interviews to extract it.
Target Architecture Planning (Week 2-3)
Deciding whether workflows go to Databricks, AWS Glue, GCP Dataproc, or Snowflake. This depends on the organisation's existing cloud contracts, data residency requirements, and workload. A current choice should be recorded with its trade-offs rather than inferred from a vendor preference.
Code Rewrite (Week 3-4)
ArcPy calls may be translated to GeoPandas and Rasterio, FME workbenches to Python ETL, and QGIS processing algorithms to GDAL-based code. Translation throughput depends on dependencies, review depth, test data, and the target runtime; the retained script-per-day example is not a general rate.
Output Validation (Week 4-5)
Running the new cloud pipelines against the same inputs as the legacy scripts and comparing outputs. Feature counts, coordinate precision, attribute values, and spatial accuracy all need to match within tolerance. Any divergence triggers a debugging cycle back into the rewrite phase.
Deployment (Week 5-6)
Configuring cloud infrastructure, setting up IAM roles, creating orchestration (Airflow, Databricks Workflows, AWS Step Functions), and deploying into production environments. Platform-specific issues -IAM propagation delays, GDAL format limitations on object storage -often cause a final round of debugging here.
Handover and Documentation (Week 6+)
Writing up what was migrated, what was left behind, and how the new pipelines are maintained. This is usually compressed at the end of an engagement and produces documentation that becomes outdated within months.
Steps 1, 2, 5, 6, and 7 are candidates for automation. Steps 3 and 4 require human judgement. Step 8 is valuable but rarely done properly under time pressure. That ratio -five automatable steps, two requiring humans -is where the opportunity sits.
Why GIS Migrations Fail or Overrun
Migration risk is usually driven by missing dependencies, tacit knowledge, scope uncertainty, platform assumptions, and weak validation. The retained percentages are not a current failure-rate or overrun estimate.
Tacit knowledge loss
GIS workflows accumulate undocumented decisions over years. Why does this script clip to a 500-metre coastal buffer? Because a regulation that passed in 2019 required it, and the analyst who added the line left in 2021. The consultants interviewing the current team will not find this. Neither will anyone reading the code. When the cloud rewrite removes the clip because it looks redundant, the output is silently wrong.
Undiscovered dependencies
Manual inventory can miss dependencies. Script A may call Script B, while an FME workbench reads from a share written by Script D. A migration should map those relationships and test the order before the target workflow is treated as operational.
Platform assumptions in legacy code
ArcPy scripts written on Windows use pathlib.Path with backslash separators that break on Linux cloud instances. arcpy.env.workspace points to a file geodatabase at a UNC path. Rasterio writes require a local intermediate file because S3 and GCS object storage cannot seek -so a direct write that works locally silently corrupts GeoTIFF output in cloud. These platform-specific traps cost days each when they surface mid-deployment.
Scope creep from incomplete inventory
A scope can expand when the first inventory is incomplete. Record the source, confidence, exclusions, and update path for the workflow count. Do not apply a generic multiplier without a dated estate review.
These are structural problems with discovering undocumented codebases. Programmatic inspection may support the work, but it does not replace human interpretation, target tests, or approval of the migration boundary.
Automation Patterns Under Development
Migration Engine is in development. The following patterns describe where code analysis, dependency mapping, translation, and validation may support a migration. They are not a claim of a generally available automated service.
Automated: Inventory
A bounded tool could inspect a selected folder of .py, .fmw, .qgz, .mxd, .shp, or .tif files and produce a candidate inventory. The handling location, processing time, permissions, and completeness must be tested for the target implementation.
Automated: Dependency Mapping
Programmatic inspection can parse imports, file reads, subprocess calls, and FME workspace connections to build a candidate dependency graph. A reviewer must check the graph against the estate, undocumented data flows, and operational order before migration starts.
Human required: Business Logic Capture
Code inspection can flag likely business rules: unexplained constants, spatial parameters, and conditional logic. The team must explain and confirm those decisions. The number of questions and review time are target-specific.
Human-assisted: Target Architecture
A decision record can compare target platforms against workload type, data residency, access, cost, operations, and ownership. A human selects or rejects the recommendation; the decision time is not fixed.
Automated: Code Generation
A future workflow could use separate planning, code-generation, and review steps to propose translations such as arcpy.analysis.Buffer to GeoPandas or arcpy.da.SearchCursor to vectorised operations. Every translation needs source, target, test data, output comparison, failure capture, and human review. No production-deployment result is implied.
Automated: Output Validation
A validation plan can compare cloud outputs with legacy results using feature counts, CRS, attributes, geometry, and task-specific tolerances. A workflow is not complete until the comparison, discrepancies, limits, and reviewer are recorded.
Automated: Deployment and Error Correction
Deployment needs explicit access, configuration, security, cost, monitoring, rollback, and ownership checks. A future tool may assist with diagnostics, but automatic deployment and repeated repair are not current Axis Spatial claims.
Manual Consulting vs Automation: Retained Illustration
The original article retained a comparison for a named workflow shape and AWS target. The values below are not current benchmarks, prices, or Axis Spatial results. Use a dated run record and cost model for any present decision.
| Dimension | Manual Consulting | Automation pattern |
|---|---|---|
| Discovery and inventory | 5-8 days | Run record required |
| Business logic workshops | 3-5 days | Target-dependent |
| Code translation (150 files) | 10-15 days | Run record required |
| Output validation | 3-5 days | Test and verifier required |
| Deployment | 2-3 days | Target-dependent |
| Total calendar time | Model required | Model required |
| Cost (selected estate) | Model required | Terms required |
| Files leave your environment | Check handling boundary | Check implementation |
| Re-migration if requirements change | Full SOW again | Re-test and review |
Any current comparison needs the estate, workflow count, dependency review, test data, target platform, labour, infrastructure, support, and failure handling. Do not infer a current saving, timeline, or subscription price from this retained table.
When Automated Migration Does Not Work
Automated migration is not a universal replacement for consulting. Some work requires human expertise throughout, including undocumented business rules, specialised platform APIs, custom transformers, topology, regulatory outputs, or missing test data.
ArcObjects COM code
ArcPy scripts that call ArcObjects through COM interfaces -using comtypes or the arcobjects bindings -rely on ESRI's C++ internals that have no direct open-source equivalent. A geometric network topology operation or a custom raster algebra that calls into ArcObjects cannot be translated by pattern matching. These require a GIS developer to assess what the COM operation actually does and find or build an equivalent.
Highly custom FME transformers
FME workbenches using standard transformers (Reprojector, Clipper, Joiner) migrate well. Workbenches built around PythonCaller or TCLCaller with complex embedded logic, or those using custom installed transformers from the FME Hub, need individual review. The agent will flag these but cannot guarantee the translation without human verification.
Workflows with departed original authors and no documentation
If the original author is unavailable and documentation is missing, no inspection system can recover every decision. The uncertainty must be recorded, the candidate translation must be tested with representative data, and a human reviewer must decide whether the output is acceptable for its use.
Network Analyst and advanced topology workflows
ESRI Network Analyst routing, service area analysis, and origin-destination matrix generation have no direct one-to-one equivalent in open-source Python. osmnx and pgRouting cover many use cases but require architectural decisions -what graph data model, what routing algorithm, what edge weight schema -that cannot be automated. These migrations need a GIS architect involved from the start.
Do not assume a fixed share of an estate is suitable for automation. Classify each workflow by dependency, data, risk, testability, and ownership. Standard operations may still require review when the output is used for a regulated or consequential decision.
The retained article argues that parts of discovery and translation can be supported by software. That is a research direction, not a current market or product claim.
Code can be inspected programmatically, dependencies can be mapped, and standard calls can sometimes be translated by pattern. Outputs still need target data, validation, review, and operational ownership. The retained consulting timeline is not a current comparator.
Human work remains central for undocumented business logic, architecture decisions, exception cases, safety, and acceptance. A current migration plan should show where that work occurs and who owns the decision.
Get Workflow Automation Insights
Monthly tips on automating GIS workflows, open-source tools, and lessons from enterprise deployments. No spam.