Legacy systems nobody fully understands
Critical services run on platforms whose original suppliers and authors have moved on, and the operating knowledge sits with a small number of individuals.
Technology consulting for government and public sector
Public sector technology is judged by a wider set of obligations than commercial technology: it must be accessible to everyone, accountable after the fact, and operable long after the people who procured it have moved on. Those constraints are the design brief, not a complication.
Industry overview
Public sector estates are long-lived by design and by circumstance. Systems remain in service for decades because replacing them requires funding, procurement and political attention simultaneously, and those rarely align.
The result is an estate where critical services run on platforms whose original suppliers may no longer support them, where the knowledge of how they work sits with a small number of people, and where the integration between departments is frequently a file transfer nobody has revisited.
Two obligations shape every design on top of that: services must be usable by the entire population, including people with access needs and low digital confidence, and decisions must be accountable — which means the estate has to be able to explain what it did and why, years later.
Business challenges
What public sector organisations bring to us most often.
Procurement shapes the architecture
Contract boundaries become system boundaries, so the estate reflects how it was bought rather than what it needs to do.
Accessibility is a universal obligation
Services are for everyone, including people with a wide range of access needs and low digital confidence. There is no acceptable segment to exclude.
Departments hold overlapping data
The same citizen is recorded separately by several bodies, and joining that data is constrained by rules that exist for good reasons.
Decisions must be accountable years later
What a system did, on what basis and under which rules, may be questioned long afterwards — which makes audit trail a functional requirement.
Funding cycles do not match delivery
Money arrives annually and often as capital, which pushes toward large programmes when incremental delivery would carry less risk.
Digital transformation challenges
Large public sector programmes fail publicly and expensively, and usually for the same structural reason: scope large enough that no part can be delivered independently, so there is no point at which the programme can be corrected without losing everything committed.
The alternative is smaller increments that each deliver a working service, which is harder to fund because it is harder to describe in a business case. We are explicit that this is a funding and governance problem as much as a technical one, and that architecture alone will not solve it.
- Increments that each deliver a usable service rather than a programme milestone
- The legacy system kept running deliberately during transition, not raced against
- A stopping condition defined, because a programme that cannot be stopped is ungoverned
- Capability retained in the organisation rather than resident in a supplier
Regulatory considerations
Public bodies hold citizen data under obligations that are usually stricter than the commercial baseline, and the Digital Personal Data Protection Act applies alongside sector-specific rules and data-sharing restrictions between departments.
Residency is frequently non-negotiable, and transparency obligations mean the estate may have to disclose how a decision was reached. Where automated decision-making is involved, that requirement is considerably harder to satisfy after the fact than to design in.
We advise on technical design and evidence architecture. We do not provide legal opinions, and we do not represent NG&NR as holding certifications or public sector accreditations it has not been awarded.
- Residency treated as an architectural constraint rather than a hosting preference
- Automated decisions explainable by design, because they will be questioned
- Data-sharing boundaries between departments enforced technically, not by policy alone
- Retention and disposal implemented against public records obligations
Enterprise architecture approach
The most valuable architectural intervention in a public sector estate is usually decoupling: putting a defined interface in front of a legacy system so new services can be built without waiting for it to be replaced.
The second is resisting the tendency for contract boundaries to become system boundaries. Where each procurement produces a self-contained system, the estate acquires duplication that no individual contract is accountable for and that no supplier is incentivised to remove.
- A defined interface in front of legacy, so new work does not wait for replacement
- System boundaries set by domain rather than by contract
- Open standards and portable data formats, because suppliers change and systems remain
- Explainability designed in where decisions affect citizens
Cloud strategy
Cloud adoption in the public sector is constrained by residency, sovereignty and procurement rather than by capability. Those constraints are real and should be established precisely — a general concern about sovereignty is not the same as a specific requirement about where data may be processed.
Exit is the second consideration and the one most often deferred. A public body will still exist when a supplier relationship ends, so data portability and the practical cost of moving are part of the initial design rather than a later problem.
- Residency and sovereignty requirements stated precisely rather than in general terms
- Exit position and data portability designed at the start, not deferred
- Elastic capacity used where public-facing demand is genuinely peaked
- Costs modelled against an annual funding cycle rather than monthly consumption
Data strategy
Public sector data problems are frequently governance problems in technical clothing. The same citizen is recorded by several bodies, and joining those records is constrained by rules that exist for good reasons — so the question is what may be joined, for what purpose, rather than whether it is technically possible.
Where sharing is permitted, the design should minimise it: answering a specific question through a controlled interface is usually preferable to copying a dataset between departments, and it leaves an audit trail that copying does not.
Data quality in long-lived estates deserves separate attention. Records captured under rules that have since changed sit alongside current ones without any marker distinguishing them, and analysis that treats decades of records as directly comparable produces conclusions the underlying data does not support.
- Purpose and legal basis established before any cross-department joining
- Controlled query interfaces preferred over dataset copies between bodies
- Lineage sufficient to explain a published figure years afterwards
- Open data published from a governed source rather than extracted per request
Security considerations
Public bodies are targeted both opportunistically and deliberately, and hold data whose exposure has consequences citizens cannot mitigate. Legacy systems complicate this because a proportion genuinely cannot be patched and are too critical to switch off.
The workable position is architectural: name the systems that cannot be remediated, bound what a compromise of them can reach, and apply compensating controls with named owners — rather than maintaining a policy that requires patching everyone knows will not happen.
- Unpatchable systems named explicitly, with blast radius bounded by segmentation
- Compensating controls given named owners rather than existing on paper
- Citizen data access logged in a form that answers a disclosure request
- Supplier and contractor access inventoried, scoped and time-bound
Software engineering
Accessibility is the defining engineering constraint. A public service has no acceptable segment of the population to exclude, which raises the bar above commercial practice and rules out treating accessibility as a late-stage assessment.
The second is longevity. Software procured now will be operated for far longer than commercial equivalents, frequently by different people, which argues for boring, well-documented technology choices over ones that are currently fashionable.
The third follows from the second: the code has to be handed over. Software a public body cannot take to a different supplier is software it has rented rather than commissioned, and the practical test is not whether a contract says so but whether the build, deploy and operate steps are documented well enough for someone else to run them.
- Accessibility specified, built in and manually verified across assistive technology
- Conservative, well-supported technology choices, because the operating horizon is long
- Documentation treated as a deliverable, since the maintainers will be different people
- Service design tested with people who have low digital confidence, not only staff
Integration strategy
Inter-departmental integration is usually the hardest part, and rarely for technical reasons. Data-sharing agreements, differing definitions of the same entity and unaligned funding all sit upstream of any technical design.
Where integration is permitted, the pattern that holds up is a defined interface per department with a stable contract, rather than direct access to another body's systems. That survives supplier changes on either side, which point-to-point access does not.
- A stable published interface per body rather than direct access to its systems
- Entity definitions agreed between departments before data is exchanged
- Legacy wrapped behind a contract so its replacement does not break consumers
- Every exchange logged, because accountability outlasts the systems involved
Recommended NG&NR services
The services usually engaged first in this sector, and why.
Enterprise Architecture
Decoupling legacy behind defined interfaces, and setting boundaries by domain rather than by contract.
Software Development
Services built to a universal accessibility standard, with documentation treated as a deliverable.
Cybersecurity
Bounding what unpatchable legacy can reach, and access logging that answers a disclosure request.
AI & Data Engineering
Lineage that explains a published figure years later, and controlled interfaces instead of dataset copies.
Cloud Consulting
Precise residency requirements and an exit position designed at the start rather than deferred.
Managed IT Services
Operating long-lived estates where knowledge must live in runbooks rather than in individuals.
Recommended technologies
Selected against the constraints above, not against a preference. We hold no vendor partnerships.
Java
Where a large share of long-lived public sector platforms are built, and where modernisation is practical.
.NET
Common across departmental administration systems, with a supported path off older frameworks.
Databases
Where citizen records live, and where retention and disposal obligations are actually implemented.
React
Citizen-facing services, where accessibility across assistive technology is the governing requirement.
Kubernetes
Where a defined interface layer in front of legacy must be operated and released independently.
Microsoft Azure
Frequently the incumbent platform, and where regional residency requirements can be met explicitly.
Delivery approach
How an engagement runs where accountability outlasts the systems.
Free first consultation
Your estate, your obligations, and whether the constraint is legacy coupling, data sharing or delivery capacity.
Assessment against the running estate
What the legacy actually does, where knowledge is concentrated, and which systems genuinely cannot be remediated.
Obligation mapping
Residency, accessibility, records retention and data-sharing constraints recorded precisely before design.
Target architecture and sequencing
Legacy decoupling, domain boundaries and increments that each deliver a usable service.
Delivery with your teams
Your people implement while we review design, so capability is retained in the organisation rather than in a supplier.
Handover
Documentation, decision records and runbooks written for people who were not present when the decisions were made.
Frequently asked questions
Not necessarily first. Putting a defined interface in front of it lets new services be built without waiting for replacement, which converts a single high-risk programme into a sequence of smaller ones. Replacement then becomes a decision you can take on its own merits rather than under pressure.
Usually because the scope is large enough that no part delivers independently, so there is no point at which the programme can be corrected without losing what has been committed. That is a funding and governance structure as much as a technical one, and architecture alone does not fix it.
By specifying accessibility as a requirement, building to it, and verifying manually across assistive technology. Automated scanning catches a limited portion. A public service has no acceptable segment of the population to exclude, which sets the bar above commercial practice.
That is a governance question before a technical one — purpose, legal basis and the agreements in place come first. Where sharing is permitted, answering a specific question through a controlled interface is usually better than copying a dataset, and it leaves an audit trail that copying does not.
Frequently, but the requirement has to be stated precisely. A general concern about sovereignty is not the same as a specific rule about where data may be processed, and precision here opens options that a general position closes. Exit and portability should be designed at the start.
Name them explicitly, bound what a compromise of them can reach through segmentation, and apply compensating controls with named owners. A policy requiring patching everyone knows will not happen provides no protection and obscures where the actual risk sits.
Partly, by setting the architecture before the procurement rather than afterwards. Where boundaries are defined by domain in advance and contracts are written to them, the estate reflects what it needs to do rather than how it was bought.
By treating documentation and decision records as deliverables, and by having your own people involved in delivery rather than only in acceptance. Capability resident in a supplier is capability you re-purchase at every contract renewal.
The estate has to be able to explain it — what rules applied, what data was used and what version of the logic ran. That is straightforward to design in and very difficult to reconstruct afterwards, particularly where automated decision-making is involved.
Into increments that each deliver a usable service and can be described in their own business case. That is harder to fund than one large programme and carries materially less risk, and being explicit about that trade-off with finance colleagues early is part of the work.
We describe practices rather than credentials and do not represent NG&NR as holding accreditations it has not been awarded. Where a control set or standard applies to your estate, we design toward it and prepare the evidence an assessment would require.
Only if the rule changes across that period are made explicit. Records captured under superseded definitions sit alongside current ones with nothing marking the difference, and treating them as directly comparable produces conclusions the data does not support — which matters more when the conclusion is published.
Next step
Discuss a public sector estate
A free first consultation covering your legacy position, your obligations, and whether the work in front of you is better sequenced as increments than as a programme.
No cost, no obligation. Pricing is transparent and includes GST.