Challenges in GIS Data Migration: The Failure Modes Nobody Warns You About

Most guidance on GIS data migration tells you to plan carefully and validate your data. That is true and useless. It does not tell you what actually breaks, in what order, or how to catch it before your field crews do.

This article is the concrete version. If you are scoping or de-risking a spatial data migration, this is the list of failure modes you will hit, ranked roughly by how often they cause pain, plus a workflow that surfaces them early instead of at cutover.

The framing matters because “migration” is not one problem. It is four.

The four migrations hiding inside one project

When someone says “we’re migrating the GIS,” they usually mean some combination of four distinct engineering problems. They fail in different ways and need different validation.

1. Schema / data-model migration. Mapping source fields to a target schema, with its domains, subtypes, and controlled vocabularies. This is the “data model workshop” step, and it is interpretive, not mechanical.

2. Geometry migration. Moving the shapes themselves. Curves, precision, topology. This is where connectivity and validity quietly degrade.

3. CRS / datum transformation. Getting coordinates into the right reference system without shifting everything by a few metres — or a few hundred.

4. System-to-system / platform migration. Geometric Network to Utility Network, ArcMap to Pro, on-prem to cloud, legacy to a vendor platform like 3-GIS or IQGeo.

The fourth one is now the highest-pressure case in the industry, and the reason is a date. Per Esri Support, ArcMap was officially deprecated on 1 July 2024 and retired as of 1 March 2026. The Geometric Network retires with it. Any organisation still running network connectivity on the Geometric Network is on a forced migration path to the Utility Network, and that migration touches all four problem types at once.

Keep the four in mind as you read the failure modes below, because most real incidents are a geometry problem masquerading as a schema problem, or a CRS problem masquerading as “the data’s in the wrong place.”

The failure modes, ranked

1. Connectivity and topology loss

This is the one that costs the most and shows up latest. In the source system, features are connected — a service line ties to a main, a fibre run ties to a splice closure. That connectivity is often implicit, held by a network model or a topology rule rather than by the geometry alone.

Move the geometry without reconstructing the connectivity, and you get a map that looks correct and traces wrong. A tool that walks the network — outage analysis, capacity tracing, isolation — returns garbage. Nobody notices until an engineer runs a trace and the result is obviously incomplete, by which point the migration is “done.”

The trap: connectivity loss is invisible in a visual QA pass. The features are all there, in the right place, the right colour. The break is in the relationships between them, which you cannot see on a map.

What to do: validate connectivity explicitly. Run known traces on the source, run the same traces on the target, and compare the feature sets. If a trace returns 214 features in the source and 190 in the target, you have a connectivity break — and you found it before a field crew did.

2. Curve degradation

GIS stores curves in two fundamentally different ways, and moving between them loses information.

True curves — circular arcs, Bézier and elliptic segments — are stored as parametric geometry. Straightened geometry approximates a curve with many short line segments. Most migrations that pass through a lowest-common-denominator format, or through a tool that does not preserve true curves, silently convert the former to the latter.

For a lot of data this is tolerable. For anything where geometry is dimensionally exact — a designed road alignment, a curved duct route, a parcel boundary defined by a radius — it is corruption. Areas and lengths shift. Downstream tools that expect true curves misbehave.

There is a specific version of this trap at the PostGIS-to-ArcGIS boundary. ArcGIS stores curve information in an extra binary column that other PostGIS clients cannot read. So a curve that round-trips fine within ArcGIS is invisible or broken when a QGIS or GeoServer client reads the same table. Teams end up converting curves to straight segments and “massaging” the data just to make it interoperate — which defeats a large part of the reason to store geometry natively in PostGIS in the first place. If your migration crosses that boundary, decide the curve strategy up front. We cover the mechanics of this incompatibility in the PostGIS setup guide.

What to do: decide, per layer, whether true curves are load-bearing. Where they are, test the round-trip explicitly and reject any pipeline step that densifies curves without your say-so.

3. Stacked points and self-intersections

The Utility Network — and any strict topological model — is unforgiving about dirty geometry that older systems tolerated for years.

Two features stacked on the exact same coordinate. A line that crosses itself. A vertex that should snap to a junction but sits a millimetre off. In a Geometric Network or a loose file-based dataset these are cosmetic. In the Utility Network they become hard failures — “dirty area” errors that stop functionality until they are resolved. The model will not let you enable the network with them present.

This is why a migration that looked like a data-copy turns into a data-cleansing project the moment the target schema is strict. The source data was never clean; the old system just did not care. The new one does.

What to do: run geometry validation on the source before you commit to a timeline. Count the stacked points, the self-intersections, the near-misses. That count is a direct input to your cleansing effort, and it is far better to know it during scoping than during cutover.

4. Datum and CRS shift — data in the wrong place

The classic. Data lands hundreds of metres from where it should, or worse, subtly shifts a few metres so it looks almost right.

Two distinct mistakes cause most of it. The first is a coordinate reference system that is undefined or mislabelled — the data has coordinates but the system does not know what they mean, or has been told the wrong thing. The second, more insidious, is omitting a geographic (datum) transformation. Reprojecting between two systems on different datums — NAD83 and WGS84 being the canonical pair — without applying the datum transformation produces a shift that is small enough to pass a glance and large enough to matter for anything precise.

Underneath both is the Define Projection versus Project confusion. Define Projection tells the software what CRS the data is already in; it moves nothing. Project actually transforms the coordinates. Use one when you meant the other and you either mislabel correct data or move data you meant to leave alone.

What to do: confirm the source CRS from an authoritative record, not from what the file claims. Validate against known control points — a handful of features whose real-world coordinates you can independently verify. If those land correctly after migration, your CRS handling is sound. If they are off by a consistent offset, you have a missing datum transformation.

5. Domain and subtype fallout

Schema migration is where judgement, not tooling, decides the outcome.

The source “Status” field has fourteen values — some duplicates, some obsolete, some that mean different things depending on which era of the data you are in. The target schema has five. Mapping fourteen to five is not a lookup table; it is a series of decisions, each of which can quietly lose information or misclassify a feature.

Subtypes make it worse, because a subtype often drives behaviour — which rules apply, which symbology renders, which fields are required. Map a subtype wrong and you do not just get a bad attribute; you get a feature that behaves as the wrong kind of thing.

What to do: capture every ambiguous mapping decision in writing, with the person who owns the call. Produce an exception report of every source value that did not map cleanly to a target domain, and review it with a domain expert before cutover, not after.

6. Shapefile limits: 10-character fields and the 2GB ceiling

If a shapefile is anywhere in your pipeline — and it often is, because a third-party tool “only accepts shapefiles” — two hard format limits will bite.

Field names truncate to ten characters. Silently. installation_date and installation_depth both become installati, and now you have a collision or an overwrite and a corrupted attribute schema. This is a property of the format; it cannot be overridden.

And a single shapefile cannot exceed 2GB. Large datasets — think a multi-million-feature layer — simply cannot be written to one file, forcing you to tile the export and reassemble on the far side, with every join risk that implies.

What to do: keep shapefiles out of the pipeline wherever you can — use a file geodatabase, GeoPackage, or a direct database-to-database path instead. Where a shapefile is unavoidable because a downstream tool demands it, audit field names for truncation collisions before export and plan the tiling for anything approaching 2GB rather than discovering the ceiling mid-run.

7. Versioning locks and compress failures

On enterprise geodatabases, the migration mechanics themselves can stall on locks.

An enterprise geodatabase periodically needs a compress operation to fold edit history back into the base tables and keep performance from degrading. Compress cannot reach state 0 while active connections or services hold locks — so a migration that runs alongside live editing, or against a database with connected services, fails to compress fully. Orphaned locks from crashed sessions produce a compress failure outright, and clearing them means manually removing stale entries from the geodatabase’s lock tables.

This is less a data-integrity failure than an operational one, but it stalls migrations that assumed the database would be quiet and it was not. If your migration involves an enterprise geodatabase, the versioning and locking behaviour is worth understanding in its own right — see our multiuser geodatabase guide for the compress, locks, and versioning detail.

What to do: stop services and disconnect users before the migration window that touches the enterprise geodatabase. Treat “the database is quiet” as something you verify, not assume.

The platform-migration multiplier: custom code

One more cost that scoping regularly misses, specific to the Geometric-Network-to-Utility-Network case. It is not data at all — it is the tooling built around the data.

Every custom toolbar, every ArcPy script, every ModelBuilder model that touches the network has to be rewritten for the new platform. There is no automated path for custom code. The consultancy Axis Spatial estimates this rewrite is often around 40% of total Utility Network migration effort, noting that Esri provides no automated migration path for custom code. Whether that figure holds for your organisation depends on how much you built, but the direction is right: if your team has years of accumulated automation, budget for rebuilding it, not migrating it.

The related trap is trace behaviour. The Utility Network traces differently from the Geometric Network, and results diverge in edge cases. Field crews notice, and they escalate. Plan a reconciliation period where the two systems run in parallel and you resolve the discrepancies deliberately, rather than treating cutover as a clean switch.

Platform-to-platform: it is a schema-mapping problem, not a file-conversion problem

The system-to-system case deserves its own note, because the way it is usually framed — “we’re moving from platform X to platform Y” — hides where the work actually is. The platforms in this space each carry their own data model and their own idea of a system of record, and the model is what has to be reconciled, not the file format.

The field is crowded enough that the pairs recur. Esri ArcGIS (Enterprise, Pro, Online) is the incumbent for most utilities and many carriers, with the Utility Network replacing the retiring Geometric Network. VETRO (FiberMap) and 3-GIS are cloud and telecom-focused fibre platforms; IQGeo runs Network Manager products across telecom, electric, and gas; GE Smallworld (now GE Vernova) is the long-established GIS under a lot of large Tier-1 carriers and gas/electric/water utilities. Bentley OpenCities Map / OpenUtilities sits on the MicroStation engineering side, Cadcorp SIS shows up across UK public-sector and utility estates, and QGIS / PostGIS is the open-source datastore-and-desktop end. Any of these can be a source or a target.

The migrations that come up in practice are moves between these systems of record:

Esri ArcGIS → VETRO or IQGeo → VETRO — enterprise or operational fibre systems to a cloud fibre platform
GE Smallworld → ArcGIS Utility Network — a legacy carrier or utility GIS onto the current Esri model
Geometric Network → Utility Network — the forced move, in-platform but a full model change
Legacy shapefile / CAD → PostGIS — a file-based or drawing-based source into an open datastore

In every one of these, the file conversion is the easy 20%. The mapping between two data models that disagree about what a “feature” is, and the reconstruction and validation of connectivity on the target, is the work — and it is exactly the work every failure mode above lands on. “We support platform Y” is not the same claim as “your model maps cleanly onto platform Y,” and the gap between those two is where a platform migration either goes well or overruns.

A validation-first workflow

The thread through every failure mode above is the same: they are invisible to a visual check and cheap to catch with an explicit one. That points to a specific way of working.

Audit before you map. Profile the source first — geometry validity counts, CRS confirmation, attribute value distributions, feature volumes. The audit output is your effort estimate. Skipping it is how migrations discover their real scope at the worst possible time.

Migrate iteratively, not in one flag-day run. Build the migration as repeatable, re-runnable scripts, not a one-shot manual process. Run migrate, test, fix, and run again on a subset, then the whole. A pipeline you can only run once is a pipeline you cannot trust, because you get exactly one chance to be right.

Produce exception reports at every stage. Every value that did not map to a domain. Every geometry that failed validation. Every feature whose trace result differs between source and target. These reports are the actual deliverable of a good migration — they are what tells you, in numbers, whether the migration is sound.

Validate connectivity and control points, not just appearance. Compare trace feature-counts source-to-target. Check known control points for CRS shift. Reconcile domain coverage. A migration that passes a visual QA and fails these is a migration that will fail in production a month later.

The point of all of this is to move failure discovery to the left — into scoping and testing, where it is a line item, and out of cutover, where it is an incident.

When not to migrate yet

Sometimes the right call is to stop.

If the source data has never been through a real quality assessment, migrating it into a strict schema converts silent problems into hard failures, all at once, under deadline. Clean first, or at least count the problems first, so cleansing is a planned phase and not an emergency.

If the GIS is being used as a design workspace — proposed and in-progress features accumulating in the operational data — untangle that before you migrate. GIS should be the system-of-record, not the scratchpad. Migrating a bloated, half-designed dataset carries all the noise into the new system and complicates every topology check on the way.

And if the governance is not in place — no owner for the ambiguous mapping decisions, no agreement on what the target schema means — the migration will produce rework regardless of how good the tooling is. The technical work is the easy part. The decisions are the hard part, and they need an owner before the scripts run.

The bottom line

GIS data migration fails in predictable ways: connectivity that breaks invisibly, curves that degrade, dirty geometry that the new model rejects, CRS shifts that hide in plain sight, schema mappings that lose information, format limits that corrupt silently, and locks that stall the mechanics. None of these are exotic. All of them are catchable with explicit validation before cutover.

Treat the migration as a validation problem with a data-movement component, rather than the other way around, and most of these stop being surprises.

GIS as the Operational Layer for Utility and Telecom Networks — the pillar this fits into: running infrastructure data as a system-of-record.
Deploying and Maintaining a Multiuser Geodatabase — versioning, compress, and lock behaviour in depth.
PostGIS Setup for Network & Infrastructure Data — including the PostGIS-to-ArcGIS curve incompatibility.

LayerSpec provides GIS data migration — source audit, schema mapping, geometry and topology cleansing, and validation-first cutover with a rollback path.

Informational content, not engineering advice. Cost and effort figures cited are third-party estimates; validate against your own project before relying on them.