How to evaluate a land information system before you buy or build

This note is for programme managers, ICT leads, survey and land officers, and anyone asked to approve a land information system (LIS) purchase or build. It is not a product recommendation. It does not replace a formal requirements study or procurement law. It is a practical way to ask better questions before money and politics lock you in.

Most land information systems do not fail because the software “cannot draw maps.” They fail because the organisation bought a map viewer, a document vault, or a dashboard and called it an LIS — then discovered that parcels still cannot be updated cleanly, titles still disagree with the map, and nobody owns the data after go-live.

If you are about to buy or build, evaluate the system of work, not the demo.

What a land information system actually is

In plain language: an LIS is the shared memory of who holds what interest in which piece of land, where that land sits on the ground, and how that record is kept current when the world changes.

Technically, a serious LIS ties together at least four layers:

1. Legal identity — parcel identifiers, ownership or tenure interests, and the status of dealings (transfer, charge, caveat, mutation, and so on), usually linked to a land register or equivalent authority.
2. Spatial identity — geometry (or a controlled link to cadastral geometry), coordinate reference, topology rules, and a clear relationship between the parcel number on the register and the shape on the map.
3. Process — the workflows that create, check, approve, and publish changes: survey intake, digitisation QC, registration steps, planning overlays, dispute flags.
4. Operations — roles, audit trails, backups, hosting, training, and a plan for when the vendor leaves.

A GIS that only displays parcels is useful. It is not yet an LIS. A document management system that stores scanned titles is useful. It is not yet an LIS. An LIS is where identity, geometry, and process stay consistent under update.

Start with the job, not the technology

Before you compare vendors, write down the jobs the system must support in the next three to five years. Use sentences a field officer would recognise:

• Receive a survey plan or mutation and put the new parcels into the official map without breaking neighbours.
• Answer a search or inquiry: which parcel is this, what is its status, what overlays apply?
• Support subdivision, amalgamation, or sectional work with a clear chain from application to updated record.
• Show planning constraints, infrastructure corridors, or public land reservations against the same parcel base.
• Hand a clean extract to another system (finance, rates, housing, courts) without retyping.

If you cannot name the jobs, you will buy features. Features look impressive in a boardroom. Jobs decide whether the system is used on a Tuesday afternoon when three mutations arrive and one boundary dispute is already open.

Seven questions that separate a real LIS from a map product

1. What is the source of truth for a parcel?

Every mature programme has one uncomfortable answer to this question. Is the register authoritative and the map derived? Is the cadastral map authoritative for shape and the register for rights? Or are both “sort of” true until someone reconciles them by hand?

Ask vendors and internal architects to draw a simple diagram: where a change starts, who approves it, and which database wins when the papers and the map disagree. Vague answers (“they sync”) are a risk flag. Dual systems that never declare a winner produce silent corruption: two parcel numbers for one plot, or one number with two shapes.

2. How does geometry stay legally and topologically honest?

Lay version: when you split one plot into three, the three new shapes must fit the old outer boundary, leave no gaps, and not overlap neighbours.

Technical version: the cadastral layer needs rules for topology (no unintended overlaps or gaps), a defined coordinate reference system, lineage from survey control, and a QC path for digitised or converted data. Ask:

• How are new surveys ingested — as files, services, or manual redraw?
• Who checks topology before publish?
• What happens to historical geometry (superseded parcels)? Are they archived with dates, or overwritten?
• Can the system record approximate versus fixed boundaries if your law distinguishes them?

Pretty cartography without topology control is how counties inherit a beautiful map that cannot support mutation.

3. Does the data model match land practice — or only IT convenience?

A spreadsheet mentality (“one row = one plot”) collapses under real land administration. You need concepts such as:

• parcel / plot / unit as distinct where your law requires it;
• parties and interests (ownership, lease, charge, caveat) that can change without redrawing geometry every time;
• applications and transactions with status, not only static attributes;
• spatial relationships to roads, blocks, administrative units, and plan sheets.

Ask for the conceptual model in everyday language. If the only answer is a list of GIS layers, the product may be a viewer with attribute tables — useful for display, weak for administration.

4. How do people work — and who is locked out?

Watch a real workflow during evaluation, not a scripted demo:

• Can a survey officer submit work without an ICT intermediary?
• Can a registrar or land officer see status without exporting to Excel?
• Are roles separated (capture vs approve vs publish)?
• Is there an audit trail: who changed what, when, and under which authority?

Systems that require a “GIS specialist” for every routine update will bottleneck. Systems with no approval gates will drift. You want both throughput and control.

5. What integrates — and what is promised later?

“API available” is not integration. Ask for:

• documented interfaces already in production elsewhere;
• which identifiers travel between systems (parcel ID, PIN, application number);
• whether integration is read-only display or two-way update;
• what fails when the other system is down.

Prioritise the three integrations that matter in your context — often land registry or search services, billing/rates, and planning. Defer the rest deliberately. An LIS that depends on ten unfinished integrations will never go live cleanly.

6. Can you operate and exit it?

The demo ends. The contract continues. Demand clarity on:

• hosting (on-premise, government cloud, vendor SaaS) and data residency;
• backup, restore tests, and disaster recovery;
• who holds admin passwords and encryption keys;
• open formats for export (parcel geometry, attributes, documents, audit logs);
• source code escrow or open components where policy requires it;
• training that creates local capacity, not permanent dependency.

If you cannot extract your parcels, history, and documents in open, usable form within a defined period, you do not own an information system. You rent a black box.

7. What does “done” mean after go-live?

Success is not “the launch event happened.” Define measurable outcomes before purchase:

• percentage of active parcels with consistent ID and geometry;
• average time to process a standard mutation or inquiry;
• number of unresolved conflicts between register and map;
• uptime and restore-test frequency;
• staff able to complete core workflows without the vendor on site.

Put those measures in the statement of work. Otherwise the project will be declared successful while officers still keep the real register in a side spreadsheet.

Build, buy, or hybrid — a sober frame

Buy when the core workflows are standard, the vendor’s data model fits your law closely enough, and you can negotiate exit and integration. Buying is faster only if configuration stays honest; endless customisation recreates a custom build inside a licence fee.

Build when your legal and institutional rules are distinctive, you have (or can hire) durable capacity, and you accept that the hard part is governance and data, not the first screen.

Hybrid is common and often wise: open spatial database and standards at the core; commercial or open-source components for capture, viewing, and workflow; careful glue for registry and finance. The test is the same: one source-of-truth story, topology discipline, and an exit path.

Do not decide build vs buy from a preference for “innovation.” Decide from who will maintain the cadastral truth in year four.

Red flags and green flags

Red flags

• Demo data that never shows a failed topology check or a rejected survey.
• Claims that “AI will clean the cadastre” without a QC and legal process.
• No parcel history — only the current map.
• Custom reports that require the vendor every time.
• Pricing that hides data migration, scanning, and change management (often larger than software).
• Refusal to discuss open export and handover.

Green flags

• They ask about your law, survey practice, and approval chain before showing slides.
• They show how a mutation changes both geometry and status, with roles and audit.
• They distinguish display GIS from transactional land records.
• They propose a phased data clean-up with acceptance criteria, not a one-shot “digitise everything.”
• They name standards (for example OGC services, well-known CRS, documented APIs) without treating standards as magic.

A short evaluation checklist you can take into a meeting

1. List the five jobs the LIS must support in year one.
2. Name the source of truth when register and map conflict.
3. Require a live walkthrough of create → check → approve → publish for one parcel change.
4. Inspect topology and history rules, not only symbology.
5. Score integration readiness for your top three systems with evidence, not promises.
6. Demand export and exit terms in the contract draft.
7. Budget data migration and organisational change as first-class line items.
8. Define go-live success metrics before vendors score their own demo.

When you need an independent reading

If the procurement is already in flight, or the architecture options disagree, an outside technical diagnostic is often cheaper than a wrong five-year platform. The point is not to pick a brand for you. The point is to pressure-test source of truth, data model, workflows, integration, and exit — in language your steering committee and your survey team can both use.

Related: Advisory · Technical Diagnostic · Digital Systems · Case studies.