How should councils govern data when local government reorganisation creates overlapping systems?

Govern the merged data estate as one programme

When local government reorganisation creates overlapping systems, the core mistake is to treat each application as a separate migration and each directorate as its own source of truth. Governance has to sit above the systems: one programme view, one cross-council inventory, and one decision record for which dataset, definition, and owner is authoritative for each business process.

That approach matters because the real problem is not just technical duplication. It is inconsistent reporting, duplicated stewardship, and policy drift across finance, housing, social care, education, and HR data that now has to operate as a single estate. Councils need a common view of the data assets before they can decide what to merge, retire, or keep temporarily parallel.

A practical starting point is to map each dataset to its business purpose, legal basis, and operational dependency, then assign a named owner who can approve definition changes and exception handling. Without that ownership layer, integration becomes a series of local compromises that are difficult to reverse later.

Standardise definitions before you standardise integrations

Overlapping systems often fail at the semantic level before they fail at the technical level. A field can be technically present in both platforms but mean different things, be populated by different teams, or be used in different statutory returns. Councils should therefore standardise core definitions, reference data, and reporting rules before relying on system-to-system sync as the source of consistency.

That does not mean freezing all local variation immediately. It means deciding which definitions must be common, which can remain local for a transition period, and which need transformation rules to keep reports comparable. If you skip that step, the merger may appear successful while dashboards, performance returns, and resident records quietly diverge.

Integration should be validated in stages, with each stage proving one business process end to end rather than many partial technical links. The safest pattern is to test one authoritative feed, one downstream consumer, and one reconciled output at a time, then expand once the data quality and exception handling are stable.

Plan for continuity, auditability, and controlled decommissioning

Reorganisation creates a period where old and new systems may both be live, which increases the risk of duplicated records, stale permissions, and conflicting updates. Councils should keep a controlled overlap only for as long as is necessary to preserve service continuity and regulatory reporting, then retire redundant routes with clear cutover evidence.

This is also the point where councils should tighten data lineage and change control. If a merged estate cannot explain where a record came from, which system last changed it, and which rule transformed it, then reconciliation problems will persist long after the technology programme is declared complete. Strong governance turns that traceability into a transition requirement, not a later clean-up exercise.

What to verify: Confirm that each high-value dataset has one owner, one definition set, one reconciled reporting rule, and one documented cutover path for the transition period.

What to measure: Track duplicate records, unmatched transactions, manual correction volumes, and the number of reports produced from reconciled versus local extracts.

Practitioner takeaway: The merger succeeds when the council can explain, for every critical data flow, which version is authoritative today, how exceptions are handled during overlap, and when the temporary dual-running will end.

Risk and Threat Considerations

Overlapping systems create a governance and operational risk even when no adversary is involved. The main exposure is that councils can end up with two or more “truths” for the same resident, asset, payment, or case, which weakens reporting, slows decisions, and increases the chance of policy breaches or missed statutory obligations.

Failure mechanism: Parallel systems, inconsistent mappings, and undocumented overrides cause data to diverge during transition, so a record may be updated in one place but still drive a report or workflow from another.

Impact: That divergence can produce inaccurate management information, duplicated communications to residents, delayed service decisions, reconciliation backlogs, and avoidable compliance exposure across the merged organisation.

Practitioner Guidance

Decision rule: If a dataset affects statutory reporting, case decisions, or resident-facing service delivery, treat it as a governed transition asset and not as a local application migration.

Implementation sequence: Start with the highest-risk shared datasets, define the authoritative source for each, then sequence integration testing by business process rather than by system catalogue.

What practitioners underestimate: Definition harmonisation is usually harder than interface work, and most merger issues come from inconsistent semantics, not broken transport.

Practitioner takeaway: Councils should optimise for controlled convergence, not rapid consolidation, because the safest reorganisation is the one that preserves traceability while the estate is still fragmented.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities in Salesforce?
• How should security teams govern non-human identities that have persistent access?