Skip to main content

Should our hapū use the cloud?

Cloud services can be very useful for hapū GIS. So can a local GeoPackage. The answer depends on the mahi and the people who need to use the system.

A small hapū does not need one architecture for every kind of information, and it does not need to prove rangatiratanga by running its own server rack.

Start with the work​

Common needs may include:

  • marae assets and resilience
  • whenua and land-block research
  • taiao monitoring
  • historical maps and archives
  • planning information
  • field forms
  • public StoryMaps or web maps
  • internal project layers

For each workload, ask how many people need it, from where, how often it changes and what would happen if the service or current GIS person disappeared.

Cloud can solve real problems​

A managed service can make sense when people need:

  • remote access from several places
  • phones/tablets and field synchronisation
  • shared editing
  • web maps and dashboards
  • central account administration
  • less server maintenance
  • easier collaboration with councils or partners

For a team spread across a rohe, those benefits can be substantial.

Local can solve different problems​

A QGIS project plus GeoPackage can be enough when:

  • one or two people edit
  • data volumes are modest
  • the project is mainly desktop research/analysis
  • no live web service is required
  • local/offline work is valuable
  • the team can maintain good backups

Small is not second-rate. If the whole workflow can be understood, backed up and handed over, it may be the most durable design.

Hybrid is ordinary​

Many useful GIS environments are already hybrid:

local source/archive
       ↓
working desktop GIS
       ↕
shared operational service
       ↓
public map / StoryMap / partner extract

Different copies can serve different audiences without making one system carry every responsibility.

See Local and hybrid GIS.

Compare actual services​

The cloud is not one place. Compare the service you are considering on concrete facts:

  • where data are stored and processed
  • who runs the service
  • account/identity model
  • offline behaviour
  • export formats
  • APIs
  • backups and retention
  • costs now and later
  • what happens when an account closes
  • what the supplier needs from the organisation to migrate away

For example, KoboToolbox public servers, ArcGIS Online, QFieldCloud and a Māori-owned storage service have different architectures and purposes. The question is which characteristics fit the project.

See Kobo data storage, ArcGIS Online and Māori GIS projects and infrastructure.

Te Pā Tūwatawata​

Te Pā Tūwatawata is a current Māori-owned, iwi-designed distributed storage service developed by Te Kāhui Raraunga. Its public information describes seven distributed locations, 100% New Zealand ownership and S3 compatibility, with customers able to choose storage location.

It is useful to include in a comparison because it shows that the choice is not limited to overseas hyperscale cloud versus a server under somebody's desk. It is storage infrastructure rather than a replacement for QGIS or a full web-GIS platform.

Account ownership matters​

For any managed service, keep the organisational relationship clear:

  • organisation-held account or tenant
  • more than one administrator
  • billing visible to the organisation
  • export/recovery instructions
  • current contact information

This is mostly boring administration, which is precisely why it works.

Cost over time​

A cheap first year can become expensive through subscriptions, consulting, licence growth or custom integrations. A self-hosted system can also become expensive through patching, backups, hardware and specialist support.

Compare the whole operating model rather than the headline storage price. See Ten-year cost models.

A simple decision guide​

SituationSensible starting point to test
one editor, desktop researchQGIS + GeoPackage + backups
small distributed teammanaged cloud/SaaS suited to the workflow
field forms across community devicesKoboToolbox or Survey123 depending on ecosystem
shared QGIS editingQField/QGIS cloud or database pattern
mixed local research + public web mapshybrid
larger organisation with established ITenterprise platform plus independent archive/exit copies

These are starting points, not rules.

The continuity test​

Whichever architecture is chosen, ask:

  1. Can another kaimahi find and open the important data?
  2. Can the organisation recover the accounts?
  3. Can a useful complete export be made?
  4. Are source/provenance notes retained?
  5. Are working and public/shared copies distinguishable?
  6. Is the annual cost understood?

If yes, the platform is much easier to carry forward.

Last reviewed: 26 August 2026

Last updated on