GIS data migration: what to expect and how to prepare

Every GIS team accumulates data. Shapefiles in shared drives. QGIS projects on local machines. CAD drawings from surveyors. Spreadsheets with postcodes that someone once geocoded manually. Over time, this becomes the status quo. It works until it doesn’t.

A GIS data migration is the process of moving all of that into a single, governed platform. It sounds straightforward. In practice, it is one of the most underestimated projects a GIS team can take on.

This article walks through what is actually involved, the common pain points, and how to set yourself up for success.

Start with an audit

You cannot migrate what you do not understand. The first step is always a data audit: cataloguing what exists, where it lives, who owns it, and how it is used.

We scoped a GIS data migration for a national property consultancy working across multiple rural teams. Some teams were using QGIS. Others had CAD files. A few had data only in spreadsheets with postcodes. The first step was simply understanding what existed.

That audit produced a Master Data Register. Every dataset was listed with its source, owner, refresh cycle, format, and whether an authoritative copy already existed somewhere centrally. Without this register, any migration plan would have been guesswork.

The audit also surfaced duplicates. Multiple teams maintaining their own copies of the same boundaries, updated on different schedules, stored in different places. This is normal. It is also exactly the kind of problem a migration should fix.

The register should carry a decision against every dataset, not just a description. Migrate it, consume it live from the publisher, or retire it. That third category matters more than people expect. A migration that moves everything, including the datasets nobody has opened in four years, just relocates the mess.

Assess data quality before you move anything

Migration will expose every shortcut ever taken. If your data has topology errors, broken geometries, or inconsistent coordinate reference systems, those issues will surface during conversion. Better to find them now than after you have loaded everything into a new platform.

Common quality issues include:

• Overlapping or gapped polygons that were never validated against each other
• Mixed coordinate reference systems across datasets, sometimes within the same project
• Missing or inconsistent attributes, where the same field means different things in different offices
• Metadata that was never recorded, so nobody knows when a dataset was last updated or where it came from
• Self-intersecting and zero-area geometries, usually from digitising done at the wrong scale

A quality assessment flags these early. Some can be fixed programmatically. Others need a human decision about which version of the truth to keep, and that decision needs the person who owns the data, not the person running the migration.

Choose your target format

Where your data ends up matters as much as where it starts. The choice depends on your organisation’s size, technical capacity, and existing software licences.

GeoPackage is the modern open standard for file-based GIS. It is a single SQLite file that holds vector data, attributes, styling, and metadata together. It works in both QGIS and ArcGIS Pro. If you need a portable, interoperable format, GeoPackage is the sensible default.

File Geodatabase is Esri’s proprietary format. If your organisation runs ArcGIS Enterprise or ArcGIS Online, this is often the path of least resistance for migration. It handles large datasets well and supports domains, subtypes, and relationship classes. The trade-off is vendor lock-in, and the practical annoyance that a file geodatabase is a folder rather than a file, so it has to be zipped to move and breaks if it is partially copied.

PostGIS (PostgreSQL with the spatial extension) is the right choice for anything at scale. It gives you a proper spatial database with full SQL access, multi-user editing, role-based permissions, and views that can serve different teams from the same underlying tables. For organisations with more than a handful of GIS users, or where data needs to feed into web applications and dashboards, PostGIS is where most serious migrations end up.

Shapefiles still exist, of course. They are also a 1990s format with a 10-character field name limit, a 2GB file size cap, no support for null values, and no way to store more than one geometry type per file. If your migration plan involves converting everything to shapefiles, reconsider.

Where cloud-native formats fit

There is a fourth option that did not really exist a few years ago. GeoParquet, FlatGeobuf and PMTiles are built for reading large datasets directly from object storage without a database server in front of them. GDAL has supported GeoParquet since version 3.5, so QGIS, GeoPandas and DuckDB all read it, and it is now the format behind some of the largest open datasets available, including Overture Maps.

These are not a replacement for your operational store. If people need to edit features, you want PostGIS. But if part of your estate is large, read-only analytical data that gets queried and rarely changed, moving that portion to GeoParquet instead of loading it into the database is often the better call. It keeps the database lean and makes the data usable from analytics tooling that has no GIS connection at all.

Map your schemas

Different source datasets will have different field names, data types, and structures. Before loading anything into the target platform, you need a schema mapping: a clear definition of what each field is called, what type it is, and where it comes from.

This is where field name truncation bites. Shapefiles limit field names to 10 characters. A field called “planning_application_reference” becomes “planning_a” or something equally unhelpful. When migrating away from shapefiles, you have the opportunity to give fields proper, readable names. Take it.

Schema mapping also means deciding on conventions. Will you use snake_case or camelCase? How will you handle date fields? What about free-text fields that should really be constrained to a lookup list? These decisions are boring. They also determine whether your data is usable in five years.

Handle coordinate reference systems

In the UK, most local data is in British National Grid (EPSG:27700). Web maps typically use WGS 84 (EPSG:4326) or Web Mercator (EPSG:3857). Datasets sourced from GPS devices might arrive in WGS 84. CAD files sometimes have no defined CRS at all.

Reprojection is usually straightforward, but it needs to be systematic. Define a standard CRS for your target platform. Transform everything on ingest. Document any exceptions.

The danger is not the reprojection itself. It is the datasets where the CRS is missing or wrong. A shapefile that claims to be in British National Grid but is actually in WGS 84 will place your data somewhere in the sea off West Africa. These errors are common and easy to miss if you are bulk-loading without visual checks.

The awkward data nobody scopes

Vector layers convert predictably. The rest of the estate is where migrations lose time.

CAD drawings. DWG and DXF files rarely carry a CRS, so they need georeferencing before anything else can happen. Beyond that, CAD has no attribute table. Meaning lives in layer names, block names, and text objects placed near features. Converting a drawing into usable GIS features means deciding what each CAD layer represents and building attributes from that. It is manual, and it does not get faster with volume.

Rasters. Scanned site plans, aerial imagery, historic maps. These are usually large, often untiled, and sometimes unreferenced. Decide early whether they belong in the database, in a file store alongside it, or converted to Cloud Optimized GeoTIFF and served from object storage. Loading multi-gigabyte imagery into PostGIS because it was on the list is a common and expensive mistake.

Geocoded spreadsheets. Someone geocoded a list of addresses once, using a service nobody now remembers, at unknown accuracy. Treat these as source addresses to be re-geocoded against a current reference, not as trustworthy coordinates.

Live services. Some of what teams use is not data you hold at all, it is a web service from a publisher. Those should stay as live connections. Copying them into your database creates a stale duplicate the day after you load it.

Styling and symbology will not transfer cleanly

This catches people out. QGIS and ArcGIS use entirely different symbology engines. A carefully styled QGIS project with categorised fills, rule-based labelling, and SVG markers will not convert to an ArcGIS layer file without significant rework. The reverse is equally true.

There is no magic button for this. You can export QGIS styles as SLD (Styled Layer Descriptor) files, which ArcGIS can partially import, but the results are inconsistent. Complex labelling rules almost always need rebuilding by hand.

If you are migrating between platforms, budget time for restyling. If you are consolidating onto a single platform, this is the moment to standardise your symbology and build project templates that everyone shares. Our comparison of ArcGIS and QGIS covers the wider platform decision if that is still open.

Test before you commit

Run a pilot. Pick one region, one team, or one thematic dataset and migrate it end to end. Load it into the target platform. Check the geometries. Verify the attributes. Apply the styling. Let actual users work with it.

The pilot will reveal problems that no amount of planning can predict. Maybe the permissions model does not work for how a particular team operates. Maybe a view that looked fine with test data is too slow with the full dataset. Maybe users need training on the new platform before they can do their jobs.

Fix these issues in the pilot. Then replicate the pattern across the rest of the organisation.

Validate everything

After migration, validate. This means more than a visual spot-check. Compare record counts between source and target. Run geometry validation. Check that attribute values survived the conversion intact. Confirm that coordinate reference systems are correct.

Automated validation scripts save time here. A simple Python script using GDAL/OGR or GeoPandas can compare source and target datasets field by field. For PostGIS, SQL queries can check for invalid geometries, duplicates, and orphaned records.

Write these checks so they can be re-run. You will want them again at cutover, and again when a dataset is refreshed six months later.

Plan the cutover, not just the load

The load is a technical task. The cutover is an organisational one, and it is where migrations quietly fail.

The failure mode is easy to describe. The new platform goes live. The old shared drive stays exactly where it was, because someone might still need it. Six months later half the organisation is still working from the shared drive, the two copies have diverged, and the duplication problem the migration was meant to solve has come back with an extra system attached.

Avoiding this needs three things written down before go-live: a date when the old location becomes read-only, a date when it is archived, and a named person who owns each dataset in the new platform. Read-only first is the important step. It stops new divergence immediately while leaving the old data readable, which is usually enough to settle nerves about deleting anything.

Expect a period of parallel running, but put an end date on it. Parallel running without a deadline is not a transition, it is just two systems.

Train your users

A new platform is only useful if people can use it. Training does not need to be a week-long course. Short, focused sessions work better: how to connect to the central database, how to use the project templates, how to edit features without breaking anything.

A champion model helps. Identify one or two confident GIS users in each team. Train them first. Let them support their colleagues day to day. This scales far better than a central helpdesk.

Decide who owns the data afterwards

Migration is a project. Data management is not. The register you built during the audit should survive as a live document, with an owner against every dataset and a refresh cycle that someone is accountable for.

Without that, entropy resumes immediately. Someone exports a layer to their desktop for a quick bit of analysis, keeps editing it, and eighteen months later it is the version their whole team relies on. The technical platform does not prevent this. Ownership and habit do.

The foundation is always the audit

Every successful GIS data migration we have seen starts the same way: with a clear picture of what exists. The audit is not glamorous work. It is interviews, spreadsheets, and opening hundreds of files to check what is actually in them. But it is the foundation that everything else rests on.

Without an audit, you are guessing at scope. You will miss datasets. You will underestimate the cleanup work. You will hit problems late in the project when they are expensive to fix.

If you are planning a GIS data migration, start with the audit. Map what you have, assess its quality, and build your migration plan from evidence. If you want a quick read on where your organisation currently stands, the GIS scorecard takes a few minutes. If you would rather talk through scoping the work, get in touch. It is what we do.