The short version

A QGIS project that survives being moved, archived, and reopened by someone else comes down to four decisions made before you load a single layer: a fixed folder tree, relative path saving, a single GeoPackage as the working store, and a deliberate project CRS. Everything else — styling, layouts, plugins — is recoverable. Broken data sources and lost scratch layers usually are not.

The trap with QGIS is that it is forgiving during a session and unforgiving afterwards. Temporary layers work perfectly until you close the project; absolute paths work perfectly until you move the folder; an undeclared CRS works perfectly until you measure. This checklist front-loads the discipline so the project is repeatable and handover-ready from the first save.

Set the folder structure before importing anything

QGIS resolves data sources by path. If your sources are scattered across a Downloads folder, a network share, and a Desktop, the .qgz becomes a fragile index of locations that will not exist on anyone else's machine. Decide the tree first:

project-name/
  project.qgz
  data/
    raw/          # untouched downloads, never edited
    processed/    # working.gpkg and analysis outputs
  layouts/
  exports/        # PNG, PDF, GeoTIFF deliverables
  docs/           # notes, sources, metadata

Keeping raw read-only is not bureaucracy. When an output looks wrong, the only reliable way to debug is to re-derive it from inputs you know were never altered.

Turn on relative paths immediately

Open Project > Properties > General and set Save paths to Relative. With relative paths, QGIS records data/processed/working.gpkg instead of /home/you/project-name/data/processed/working.gpkg. The entire folder can then be zipped, emailed, moved to a server, or committed, and it opens with every layer intact as long as the internal structure is preserved. This single setting prevents the most common "broken layer" support ticket.

Use one GeoPackage, not a pile of shapefiles

Store working vector data in a single GeoPackage (.gpkg). It is an OGC standard SQLite container that holds many vector and raster layers, attribute tables, and styles in one file. Compared with shapefiles it removes the 10-character field-name limit, the 2 GB ceiling, the missing-.prj failure mode, and the multi-file fragility where a stray missing .dbf breaks the dataset.

Create and append from the command line when scripting:

ogr2ogr -f GPKG working.gpkg contacts.shp -nln contacts
ogr2ogr -f GPKG -update -append working.gpkg faults.shp -nln faults

Or in QGIS, Export > Save Features As > GeoPackage, reusing the same .gpkg and changing the layer name. Save layer styles into the GeoPackage too (Layer Properties > Style > Save Style > Save in database) so symbology travels with the data.

Set the project CRS deliberately

Project > Properties > CRS controls the on-the-fly display CRS and the default for new layers. Choose a projected CRS appropriate to your extent (a UTM zone or national grid) if you intend to measure, and check that each loaded layer's own CRS is correct in Layer Properties > Information. On-the-fly reprojection will align mismatched layers visually, but processing operates on stored geometry, so a layer in EPSG:4326 will still produce degree-based areas regardless of the project CRS. Reproject analytical layers with the Reproject layer algorithm or ogr2ogr -t_srs rather than relying on display alignment.

Promote scratch layers before they vanish

Processing algorithms default to temporary [Create temporary layer] outputs held in memory. They are gone the moment the project closes. For anything you will reuse, set an explicit output path into working.gpkg. To catch ones you forgot, watch the scratch-layer indicator (the temporary-layer icon) in the Layers panel and use Make permanent before saving the project.

Styling and layouts come last

Style layers only after the analytical outputs are stable. Restyling while the data model is still changing wastes effort and produces inconsistent symbology. For map composition use Project > New Print Layout, and when the project is finished package fonts and the SVGs your symbols depend on, because a layout that renders on your machine can break on another system missing those assets.

A reproducible-workflow example

Suppose you classify slope into hazard bands across a study area. Done reproducibly:

  1. Inputs in data/raw/dem.tif, never edited.
  2. Reproject and clip the DEM to the AOI with a named output: gdalwarp -t_srs EPSG:25831 -te <xmin ymin xmax ymax> -tr 10 10 data/raw/dem.tif data/processed/dem_aoi.tif.
  3. Run Raster Terrain Analysis > Slope, output to data/processed/slope.tif.
  4. Reclassify with Reclassify by table, output to working.gpkg.
  5. Save the chain as a model in the Graphical Modeler, or export Processing History, so the next analyst re-runs the exact sequence rather than reconstructing it.

The deliverable is then the folder plus the model — anyone can reproduce every number.

QA gates before export

  • Run Check Validity (and Fix Geometries where needed) on edited vector layers to catch self-intersections and null geometries.
  • Run Topology Checker against topology rules relevant to the data (no overlaps for polygons, no dangles for a connected network).
  • Confirm no layer is still a temporary scratch layer.
  • Verify the project opens cleanly after closing and reopening, ideally from a copy moved to a different folder, to prove relative paths hold.
  • Confirm CRS and units are explicit on every layer before generating a layout.

Common mistakes and why they happen

  • Leaving outputs as temporary layers — they exist only in RAM and disappear on close; the cause is the default temporary output setting.
  • Absolute paths — the default unless changed; the project becomes machine-specific.
  • Shapefile sprawl — easy to create but loses fields, CRS, and integrity; consolidating into a GeoPackage removes the whole class of failures.
  • Exporting before validity checks — invalid geometry can silently distort areas and break later joins.

Bathyl perspective

We hand off QGIS projects as self-contained folders: relative paths, a single GeoPackage, embedded styles, and a model or history file that reproduces every output. The discipline is not about tidiness for its own sake — it is what lets a client, an auditor, or a future analyst open the project a year later and get the same answer we did.

Related reading

Sources