- Desktop GIS cost includes licensing, hardware, analyst time, support, key-person risk, and operational constraints
- Migration economics must separate implementation cost, parallel running, training, validation, and ongoing support
- Recurring, well-defined workflows may be suitable for review; novelty, low volume, or deep Esri integration may favour retention
- A current decision needs a dated model with workflow volume, assumptions, alternatives, failure cases, and a review owner
Your team has run ArcPy scripts for years. They work. The analysts know them. Why change a workflow that still delivers?
It's a fair question. Migration costs real money and time. The benefits are often oversold by vendors with products to move. But there's a real decision to make: compare the current workflow with a tested alternative, including the cost of change and the cost of keeping the current path.
Migration may cost more during the transition because of parallel running, implementation, training, validation, and support. The break-even examples in this retained article are historical; a current model must use the target workflow and current costs.
This post gives you the framework to calculate the numbers for your specific workflows: when migration makes sense, when it doesn't, and how to make the case (or argue against it) with current, reviewable data.
The True Cost of Desktop GIS
The licensing invoice is only one cost category. Include analyst time, hardware, support, failure recovery, knowledge transfer, and the limits of the current operating path. The values below are inputs to measure, not Axis Spatial benchmarks.
1. Analyst Time on Repetitive Execution
Record who starts the workflow, sets parameters, waits for execution, verifies the result, and prepares the output. Measure the active time, waiting time, review time, frequency, and loaded labour rate for the target workflow.
frequency × attended time × loaded rate = current annual labour cost
Use measured values for one named workflow.
2. Hardware and Desktop Dependency
Record the current workstation, licence, extension, storage, refresh, and support requirements. Compare them with the target runtime only after testing the actual data and operations.
hardware + licences + support + refresh = current annual platform cost
3. Single Point of Failure
Check whether the workflow has documented inputs, outputs, assumptions, dependencies, failure handling, and a second operator. Key-person risk is a review item, not a universal cost estimate.
Key-person risk doesn't show up in budget spreadsheets until a deadline gets missed or emergency contractors get hired. One major slip can exceed annual migration costs.
4. Scaling Constraints
Record the workload, queue, concurrency, elapsed time, and review capacity. A different runtime may improve the operating path, but the result depends on data size, dependencies, controls, and configuration.
The current evidence question
Do not apply a typical team size, cost ratio, or saving claim. Build a dated baseline for the named workflow and record the source, owner, confidence, and review date for each input.
Migration Cost Reality Check
Migration cost depends on scope, evidence, interfaces, validation, training, and the operating path. Use the table as a current-input checklist. The historical ranges previously shown here are not a current Axis Spatial price list or benchmark.
| Cost Category | Current input | Evidence | Notes |
|---|---|---|---|
| Workflow audit and design | Measure | Scope, owner, acceptance criteria | |
| Code translation | Estimate | Dependencies, gaps, manual steps | |
| Platform setup | Estimate | Runtime, storage, network, access | |
| Team training | Estimate | Operators, reviewers, support owner | |
| Cloud compute | Measure | Workload, runtime, duration, provider terms | |
| Maintenance (15-20%) | Estimate | Updates, incidents, dependency changes | |
| Current model total | Calculate | Do not reuse historical ranges |
Transition cost can exceed retention cost at first. Test that statement against the current workflow. Migration is a change programme with validation and operating costs, not an automatic saving.
BREAK-EVEN CALCULATION
Current annual cost: licences + labour + hardware + support + failure cost
Migration investment: audit + build + interfaces + training + parallel running
Target annual cost: runtime + storage + support + review + remaining manual work
Annual difference: current annual cost - target annual cost
Break-even: migration investment ÷ annual difference. Use a range and state the assumptions.
ROI1 Calculation Framework
Use this framework to calculate ROI for your specific situation:
Step 1: Calculate Current Annual Cost
- • ArcGIS licenses (all tiers, all users)
- • Analyst time on workflow execution (hours × rate)
- • Hardware costs (workstations, annualised)
- • Maintenance and support contracts
Step 2: Estimate Migration Investment
- • Audit and design: scope and effort estimate
- • Translation: dependency and workflow estimate
- • Infrastructure: runtime, storage, network, and access estimate
- • Training: operator and reviewer effort estimate
Step 3: Estimate Post-Migration Annual Cost
- • Cloud compute (based on projected usage)
- • Maintenance: incident, update, and support estimate
- • Remaining analyst time (now exception-handling only)
Step 4: Calculate Break-Even
Break-even = Migration Investment ÷ (Current Annual - Post-Migration Annual)
If payback is long or uncertain, reconsider. Technology changes. Team priorities shift. Long payback periods carry execution risk.
When NOT to Migrate
Migration isn't always the right answer. Here's when staying on ArcPy makes more sense:
Low-Volume Workflows
If a workflow has low frequency and low attended effort, the cost of change may not be justified. Record the actual frequency, effort, consequence of failure, and migration estimate before deciding.
Single-Analyst Operations
If one analyst handles all geospatial work and has capacity to spare, the scaling case may be weak. Migration can add complexity without solving a current problem.
Deep Esri Ecosystem Integration
If workflows depend on ArcGIS Enterprise, Portal, Web Maps, and the full Esri stack, migrating the Python code may not remove the dependency. Map the integration boundary before proposing a change.
Constantly Changing Requirements
If every workflow execution requires tweaking the logic, automation may not help. A changing requirement can create the same manual work in a different platform.
Team Resistance
If operators and reviewers cannot support the change, adoption risk is material. Include training, ownership, support, and rollback in the decision.
Decision Criteria
A migration candidate usually needs several conditions to align. Treat these as questions for a pilot, not as a universal score:
The Decision Matrix
Use a bounded pilot when the evidence is incomplete. Keep ArcPy when the current path is adequate, dependencies are deep, or the target benefits cannot be measured. Record the decision and its review date.
Migration is an investment, not a quick win. Transition cost may exceed retention cost at first. Break-even is workflow-specific and the examples retained in this article are not a current forecast.
Some teams should stay on ArcPy. Low-volume workflows, single-analyst operations, deep Esri ecosystem dependencies. These are legitimate reasons to keep doing what works.
If a current workflow is costly, fragile, difficult to review, or blocked by its operating path, a tested alternative may improve capacity or trust. That result must be demonstrated for the named workflow.
In Part 2, we'll cover the technical translation: which ArcPy functions map to which open-source equivalents, where GeoPandas falls short, and when you need hybrid architectures.
Get Workflow Automation Insights
Monthly tips on automating GIS workflows, open-source tools, and lessons from enterprise deployments. No spam.