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.

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

Common migration scenarios

• Shapefile / file geodatabase → PostGIS — open-source modernisation
• Esri Personal Geodatabase / file geodatabase → SDE / Utility Network — 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.

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.