A migration decision often starts with a simple question: can a lower licence bill reduce the total cost of a geospatial system? A simple comparison is not enough to answer it.
Licence terms are only one part of the system. Engineering, integration, support, training, data conversion, validation, and parallel operation can move the total cost in either direction. This article calls that wider ownership burden the Engineering Tax.
Treat migration as a change to an operating system for spatial work, not as a guaranteed cost reduction. The useful outcome is a model that makes assumptions, dependencies, failure modes, and ownership visible.
This retained note lists the cost categories a current review should test. It does not establish a universal answer. You can also review licence use as an audit method and the ArcPy to GeoPandas process note for technical migration questions.
Why are organisations migrating from ESRI ArcGIS?
The historical model groups the decision into licence cost, cloud integration, and automation capability. Current savings depend on workflows, contracts, retained specialist capability, engineering scope, and validation effort. Use a dated workflow review to test the assumptions; this retained example is not a savings guarantee.
Why Simple Price Comparisons Fail
A historical comparison is useful for showing what a licence-only model leaves out. The figures below are an illustrative example from the retained article. They are not current vendor pricing or an Axis Spatial benchmark.
HISTORICAL ILLUSTRATION (INCOMPLETE)
ILLUSTRATIVE CURRENT STATE
$730K/year
A retained licence, maintenance, and support estimate
ILLUSTRATIVE TARGET STATE
$24K/year
A retained infrastructure-only estimate
What's missing: Who maintains your open-source stack? Who fixes bugs? Who keeps Python libraries compatible? Who trains your team? Who builds integrations?
The useful point is not that one stack always costs less. Open-source software can have a different cost structure. A current model must include the people and services needed to operate the proposed stack.
I call this the Engineering Tax. It includes maintenance, integration, support, documentation, and validation. There is no honest universal range: the current amount depends on the system and the organisation that owns it.
What a Current TCO Model Must Include
The retained article includes a worked five-year comparison. Treat it as a historical illustration of cost categories, not as a current price or savings forecast. A current model must verify the contract, users, extensions, region, data, migration scope, engineering capacity, support, training, validation, and parallel-running plan.
HISTORICAL FIVE-YEAR TCO ILLUSTRATION
Retained worked example. Inputs are not current prices, benchmarks, or a forecast for any organisation.
ESRI PATH
OPEN SOURCE MIGRATION PATH
YEAR 1 (MIGRATION YEAR)
Historical comparison only; recompute the transition cost from current evidence.
YEAR 2-5 (STEADY STATE)
* 1 senior engineer @ 50% time maintaining stack, updating libraries, supporting team
The original crossover calculation is not a current payback forecast. Rebuild it from dated costs, benefits, risks, and acceptance evidence.
Key insight: A migration has transition cost and operational risk. Do not approve it from a headline saving. Approve it only when the current model, target workflow, validation checks, ownership, and fallback plan are credible.
Understanding the Engineering Tax
"But wait—you said QGIS is free!" A software licence is only one part of the operating cost. Someone still needs to:
Maintain library compatibility
GeoPandas 0.14 breaks your scripts when Pandas updates. Someone fixes that. (See our ArcPy to GeoPandas guide for what this transition involves.)
Troubleshoot platform issues
"Why is Rasterio failing on Windows?" Your team needs an answer, not a GitHub thread.
Build integrations
Connecting QGIS → Databricks → Power BI isn't plug-and-play. Someone architects that.
Support end users
ESRI has a support desk. You need to build yours (or designate someone internal).
Keep documentation current
Your custom workflows need docs. They need updating when libraries change.
COST INPUTS TO MODEL TODAY
- People: engineering, data, GIS, support, and review time.
- Platform: hosting, storage, observability, security, and vendor services.
- Change: translation, integration, training, documentation, and parallel operation.
- Assurance: test data, acceptance checks, error handling, human review, and rollback.
Historical ranges in the original article are not a current price list. Record the actual inputs and their evidence before comparing systems.
The key question is not "Can we eliminate this cost?" It is "What will this proposed system require to operate, and is that supported by current evidence?"
For repetitive workflows, compare the current baseline with a defined target. Include operational ownership, specialist capabilities, validation, and unresolved edge cases. A lower licence bill is not proof of a better system.
When ESRI is Actually the Right Choice
A full migration is not always the right answer. Existing tools may remain appropriate when:
The current scope is small or stable
If the current scope is small, stable, or well supported, a migration may add more change risk than value. Test that with a dated model rather than a fixed threshold.
The work is specialist or not repeatable
One-off analysis, specialist cartography, and judgement-heavy work may not justify a platform change. Identify repeatable steps and retain specialist tools where they remain the safer choice.
Highly Specialised ESRI Extensions
Specialist extensions or contractual deliverables may have no equivalent in the proposed target. Confirm current vendor status, contract terms, interoperability, and fallback options. Utility organisations can also read the historical Utility Network note.
No Technical Capability (and No Budget to Build It)
A target stack needs a named owner, support model, training plan, and time for validation. If those are not available, keep the current system while the capability gap is resolved.
Contractual ESRI Requirements
Government contracts sometimes mandate ESRI for interoperability. Check your contracts before planning migration.
Staying with ESRI can be the right technical and economic choice. The important work is to understand licence use, workflow constraints, support obligations, and evidence before changing the system. See the note on manual workflow cost categories.
The Migration Decision Framework
Use these questions to structure a current review. Do not treat them as automatic migrate or stay thresholds.
| Factor | Evidence to collect | Current answer |
|---|---|---|
| Annual ESRI spend | Contract, renewal, users, extensions | ___ |
| Repetitive workflows | Frequency, effort, delay, failure modes | ___ |
| Cloud infrastructure adoption | Target environment, security, service limits | ___ |
| Technical team capability | Named owner, support, training capacity | ___ |
| Executive sponsorship | Budget, sponsorship, coexistence plan | ___ |
| Workflow automation potential | Acceptance checks and human review | ___ |
Decision rule: Do not use a fixed score. Proceed only when the current evidence supports the target design, ownership, validation, cost model, and fallback plan.
The Hybrid Approach (What Most Organisations Actually Do)
Binary thinking ("all ESRI or all open source") is how migration projects fail. The organisations that succeed use a hybrid model:
Open Source For
- →Automated pipelines and workflows
- →Cloud-native data processing (Databricks, Snowflake)
- →API integrations and web services
- →Large-scale batch processing
- →Data science and analytics workflows
Keep ESRI For
- →Specialist extension-dependent work
- →Complex cartographic production
- →Ad-hoc exploratory analysis
- →Teams not ready for Python transition
- →Contractually required deliverables
Historical hybrid example
The retained article describes a mixed system in which repeatable workflows moved to open tools while specialist work stayed in ESRI. The original licence counts, timing, and savings are historical and are not published as current proof.
Hybrid isn't compromise—it's pragmatism. Use the best tool for each job, not the same tool for all jobs.
What is the best alternative to ArcGIS for enterprise GIS?
There is no single best alternative - the right answer depends on your workflows. For desktop analysis and cartography, QGIS is a capable free replacement. For automated batch processing, Python with GeoPandas and PostGIS covers many requirements. For cloud-scale processing, Databricks with GeoParquet is one option. A hybrid model may retain ESRI for specialist extensions. A current workflow review must test translation coverage, validation checks, operational ownership, and unresolved edge cases.
Migration Risk Factors (What Kills Projects)
These are common risks to test in a current migration review:
Expecting immediate savings
Model transition costs before approving a target. Parallel operation, training, migration, and validation can increase early cost.
No Executive Sponsorship
Migration requires budget, patience, and air cover when things get difficult. Without a sponsor at director level or above, you'll get defunded at the first hiccup.
Underestimating Training Time
"We'll learn Python as we go" is not a delivery plan. Name the training, support, and acceptance work before changing production workflows.
Big-Bang Migration
Do not switch the whole estate at once without a coexistence and rollback plan. Phase the work around evidence and operational risk.
Ignoring Change Management
"If we build it, they'll use it" fails. People resist change. You need champions, training, documentation, and patience.
No Engineering Tax Budget
If ongoing maintenance, support, and validation have no owner, the target stack will become fragile. Include them in the operating model.
What Evidence Would Support an ROI Case
If migration were purely about cutting costs, the TCO analysis might not justify it for many organisations. But the real value comes from what becomes possible:
Workflow Automation at Scale
A current run may reduce turnaround or increase throughput. Record the baseline, target data, runtime, failure state, output checks, and human review. The historical three-week and 30-minute example is not a current performance claim.
Cloud Platform Integration
Geospatial data joins your data lake. Analysts query spatial data in Databricks alongside business data. GIS stops being a silo.
Team Autonomy
Your team controls the stack. Need a new feature? Build it. Library breaks? Fix it. No vendor roadmap dictating what's possible.
Modern Data Science Integration
Data scientists can use geospatial data without learning ESRI tools. Geospatial becomes another data type, not a specialised silo.
The historical cost model is useful only as a prompt for current evidence. The strategic question is what your team can build when it is not constrained by desktop GIS tools. Script migration still requires current scope, translation checks, data validation, and human review; the examples here are not a delivery-time promise.
The Bottom Line
ESRI migration is a platform change, not a guaranteed cost-cutting exercise. There is no universal payback period.
If your current contract and workflows create a measurable constraint, compare a defined target against the existing system. Include specialist requirements, support, validation, and transition risk.
If the work is stable, specialist, or not repeatable, staying with ESRI may be the better choice while you improve licence use or remove the specific constraint.
If the answer is mixed, consider a hybrid approach: move only the workflows with a tested target and retain ESRI where specialist capability or contractual requirements remain.
The Question to Ask Your CFO
"What does our current spatial system cost to operate, what would the proposed target require, and what evidence would prove that the change is safer and more useful?"
A current answer should include the model inputs, acceptance checks, responsible owner, and a fallback path. Do not make the decision from an inherited headline figure.
Skip the Manual Work
If you follow this method, you can build a current TCO model. Executing the migration—translating scripts, converting data, training teams, and validating outputs—is where the real work begins.
Manual migration can create inconsistent code, weak validation, and operational gaps. Measure those risks in the target workflow rather than assuming a fixed delivery period.
Migration Engine is In development; it is not a finished self-serve migration service.
A current migration plan should record translation coverage, validation checks, human review, and unresolved edge cases. See our ESRI migration guide for the retained process discussion.
Get Workflow Automation Insights
Monthly tips on automating GIS workflows, open-source tools, and lessons from enterprise deployments. No spam.