GIS data migration & cleansing

Most GIS data migrations turn into data quality projects partway through. The data that worked fine in the old system reveals geometry issues, attribute gaps, or topology breaks the moment it has to fit a stricter schema.

We deliver GIS data migration that anticipates this rather than discovering it under deadline. Geospatial work is delivered through our partner Geodars.

The four kinds of GIS data migration

“Migration” gets used as one word for four genuinely different engineering problems. Most projects involve more than one, and each carries its own failure modes:

Schema / data-model migration. Mapping source fields, domains, and subtypes onto a target model. This is the interpretive work — controlled vocabularies that don’t line up, subtypes with no clean equivalent, attributes that meant different things in different eras.

Geometry migration. Moving the shapes themselves without degrading them. Curves flattened to straight segments, stacked coincident points, self-intersections, topology that has to be rebuilt on the far side.

CRS / datum transformation. Getting the data to land in the right place. An undefined or mislabelled coordinate reference system, or a missing geographic (datum) transformation such as NAD83 to WGS84, shifts features silently — the classic Define Projection versus Project confusion.

System-to-system / platform migration. Moving between platforms and models — file geodatabase to PostGIS, on-premises to cloud, or Geometric Network to Esri Utility Network. This is now the highest-pressure category: Esri retired ArcMap on 1 March 2026, and the Geometric Network retires with it, so operators on legacy Esri stacks are on a clock. It also carries its own failure surface, which we cover in detail in the failure modes nobody warns you about.

We scope which of the four are in play before quoting, because the mix — not the feature count — is what drives risk and effort.

Why migration is rarely “just” migration

A migration from format A to format B sounds like a conversion exercise. In practice, three things usually surface:

1. Source data is messier than anyone realised. Geometry without proper SRID, attributes that mean different things over time, codes that aren’t in any documented controlled vocabulary, features that exist in multiple records with different IDs. The old system tolerated this; the new system won’t.

2. Schema mapping is interpretive, not mechanical. “Status” in the old system has 14 values (some duplicates, some obsolete). The new system has 5. Mapping the 14 to the 5 requires judgement, not a lookup table.

3. Operations need to keep running through cutover. Most migrations can’t take a multi-week outage. The cutover plan has to allow for production work continuing on the old system while the new one is being prepared.

A migration that doesn’t anticipate these is a migration that misses its target date.

What’s in a migration engagement

A complete delivery covers:

Audit

Source data state — what’s actually there, in what shape
Quality assessment — geometry, attribute, topology issues
Volume profile — feature counts, expected complexity drivers

Schema mapping

Source-to-destination mapping at field level
Transformation rules for attribute values
Decisions captured for ambiguous mappings

Cleansing

Geometry repairs — fixing self-intersections, snapping, reprojection
Attribute backfill where data exists in alternative sources
Deduplication where records duplicate
Quality flags where issues can’t be resolved

Migration scripts

Repeatable, auditable transformation
Idempotent where possible (re-runnable safely)
Logging at row level for post-migration validation

Cutover plan

Sequence of work
Communication plan
Rollback path if cutover fails
Validation criteria for cutover success

Validation

Pre/post comparison report
Quality assessment of migrated data
Issue register for follow-up

The failure modes we guard against

Spatial migrations break in recognisable ways. We build the process to catch each of these before cutover, not after:

Connectivity and topology loss — a migration that moves geometry but not the relationships between features leaves a network that looks right and can’t be traced. We validate connectivity by running the traces operations will need, the same discipline we apply to utility network mapping.
Curve degradation — curved features flattened to straight segments during conversion, or ArcGIS-native curve geometry that other PostGIS clients can’t read. We identify curve-bearing data up front and choose a representation that survives the round trip.
Stacked points and self-intersections — the Esri Utility Network treats these as hard failures (“dirty area” errors) that stop functionality. Data that a Geometric Network tolerated has to be cleaned before it will load.
Datum and CRS shift — features landing in the wrong place because a transformation was omitted. We verify placement against known control, not just that a projection is defined.
Domain and subtype fallout — source codes that map to nothing valid in the target model. We surface these as exceptions rather than letting them drop silently.
Shapefile limits — the 10-character field-name truncation that silently corrupts attribute schemas, and the 2GB file ceiling that breaks large exports. Where shapefiles are unavoidable in the chain, we manage both explicitly.
Versioning locks — enterprise geodatabase compress and load operations that stall on active connections and orphaned locks. We plan the maintenance window and lock state into the cutover.

Our GIS data migration methodology

The difference between a migration that hits its date and one that doesn’t is method, not tooling. Our GIS data migration process is validation-first and iterative rather than a single flag-day cutover:

Audit before mapping. We establish the true state of the source — geometry, attribute, topology, CRS — before any transformation rules are written. Mapping without an audit produces problems that surface at the worst possible time.

Iterative migrate-test-fix. We migrate a representative slice, test it against the target model’s rules and the queries operations actually run, fix what fails, and repeat. Each pass narrows the exception set rather than deferring every problem to the end.

Exception reporting, not silent drops. Every record that can’t be mapped cleanly is reported, not discarded or fabricated. The exception register is a deliverable in its own right — it tells the owner exactly what needs a decision.

Repeatable, auditable scripts. Transformation runs from version-controlled, re-runnable scripts, so an updated source extract can be re-migrated without hand-work. This is what makes operational continuity through cutover possible.

Verification against the target’s own rules. For a Utility Network target, that means the model’s connectivity and validation rules; for a multi-user geodatabase or PostGIS, the constraints and topology the schema enforces. We prove the migrated data passes the destination’s checks, not just that it loaded.

This methodology is where migrations are won. It is also where quality assurance and audit requirements are satisfied — the evidence trail from source audit through exception register to post-migration validation is the record that stands up to funder review or internal audit.

Common migration scenarios

Shapefile / file geodatabase → PostGIS — open-source modernisation
Geometric Network → Esri Utility Network — forced by the 1 March 2026 ArcMap retirement; the Utility Network’s stricter validation means source data has to be cleaner than the old model required. Consultancy Axis Spatial estimates custom-code rewrites alone at roughly 40% of total Utility Network migration effort, since toolbars, ArcPy scripts, and ModelBuilder models that touch the network have no automated migration path — a cost we scope explicitly rather than discover late.
Esri Personal Geodatabase / file geodatabase → SDE — ESRI platform consolidation
Bespoke legacy systems → modern GIS — replacing decades-old custom systems
Cloud migration — moving on-premises GIS to managed cloud
Multi-source consolidation — combining several data sources into one authoritative platform

Each has its own pitfalls. We assess at the start which apply to the project.

Platform-to-platform migration

Most of the hard migrations are moves between systems of record — the platform an organisation runs its network on day to day. Our position is simple: any platform to any platform, given the right access, a defensible schema mapping, and source data we can actually read. The engineering that matters is the same regardless of the two logos involved — geometry, connectivity, CRS, and domains have to survive the move, and the operational system of record on the far side has to hold up under the queries operations run.

The platforms we work across include:

Esri ArcGIS (Enterprise, Pro, Online) — including the Utility Network and the retiring Geometric Network
VETRO (FiberMap) — cloud fibre and broadband network management
IQGeo — Network Manager Telecom / Electric / Gas
GE Smallworld (now GE Vernova) — long-established GIS for large carriers and utilities
Bentley OpenCities Map / OpenUtilities — MicroStation-based engineering GIS
3-GIS — telecom and utility network management
Cadcorp SIS — UK public sector and utility desktop/web GIS
QGIS / PostGIS — open-source desktop and datastore

Some moves come up often enough to be specialisations in their own right. These are the kinds of migration we handle:

Esri ArcGIS → VETRO — enterprise geodatabase to cloud fibre platform
IQGeo → VETRO, or the reverse, between operational fibre systems
GE Smallworld → ArcGIS Utility Network — legacy carrier GIS to the current Esri model
Geometric Network → Utility Network — the forced move ahead of the ArcMap retirement
Legacy shapefile / CAD → PostGIS — open-source modernisation off a file-based or drawing-based source
On-premises → cloud for any of the above

None of these are push-button. A typical Esri-to-VETRO move, for example, is mostly schema-mapping and connectivity work, not file conversion — the source model and the target model rarely line up field for field, and the connectivity has to be rebuilt and proven, not assumed. We scope each pairing on its own terms rather than treating “we support platform X” as if it made the migration trivial.

Inputs we need

A productive migration engagement runs on:

Source system access — read access to source data in whatever form it’s in
Destination platform — where data is going, with schema if defined
Operational context — what processes run on the data today, what windows for cutover are available
Quality expectations — what level of cleansing is in scope (everything? just blockers? case-by-case?)
Stakeholders — who needs to sign off on transformation decisions

Common pitfalls in outsourced migration

Skipping the audit phase. Jumping into mapping without an audit produces migrations that surface issues at the worst possible time. We always audit first.

Migration scripts that aren’t repeatable. One-off migration code that can’t be re-run on updated source data forces a flag-day approach. We build for re-runnability.

Cleansing that’s actually fabrication. Filling in missing data with assumed values to make the destination “complete” produces records that mislead. We flag rather than fabricate.

Cutover with no rollback. Cutovers without a tested rollback path turn issues into outages. We build rollback into the cutover plan.

Typical timelines

Single-source small dataset (under 100k features) — 3-6 weeks
Multi-source mid-sized migration (100k-1M features, 2-5 source systems) — 6-16 weeks
Enterprise migration with operational continuity requirements — 16-32 weeks

Cleansing complexity drives timelines more than data volume. Clean source data with messy schema migrates fast; small but messy datasets can take longer than large clean ones.

How we deliver

Geospatial work runs through our partner Geodars. The team has direct experience with multi-platform GIS migrations, including utility, telecom, and infrastructure data.

Talk to us about a migration project

Tell us the source and destination platforms, rough data volume, and the operational context. We’ll scope and price after a quick audit phase. Migration projects nearly always warrant a scoping call.

Related reading: Challenges in GIS Data Migration: The Failure Modes Nobody Warns You About — the specific ways spatial migrations break, and how we catch them before cutover.