Discovery should come first, because councils need a usable view of data locations, sensitivity and access patterns before any consolidation starts. Migration should follow only after high-risk content is identified and the most obvious exposure gaps are addressed. Otherwise, the programme moves risk into the new authority instead of reducing it.
Why discovery has to happen before migration
Discovery is the control step that tells the programme what is actually present, where it lives, who can reach it and which datasets are likely to create the greatest risk if moved badly. In a council reorganisation, that is more than an inventory exercise, it is the point where hidden dependencies, duplicate stores and overexposed records become visible enough to manage.
Once the current state is mapped, the migration plan can be staged around the highest-risk content first, rather than around organisational convenience. That sequencing matters because councils often inherit multiple systems, old file shares, shared drives and service-specific repositories that were never designed for a clean handover.
A useful way to think about the order is: discover, classify, stabilise, then migrate. If discovery is shallow, the migration team may copy low-value data first and leave the most sensitive material, orphaned credentials or loosely governed access paths untouched until late in the programme.
What councils should identify before any consolidation begins
The practical discovery target is not simply “what systems exist”, but what data is exposed by each system and what would break if access, ownership or location changed. That includes personal data, restricted casework, service records, shared folders, integration accounts and any data stores with unclear retention or ownership.
For teams dealing with service accounts, scripts and other machine-held access paths, the inventory should also capture how those credentials are used, where they authenticate and whether they are shared across environments. NHIMG’s NHI Lifecycle Management Guide is useful here because it frames discovery as part of lifecycle control, not a one-time lookup exercise.
High-risk items should be sorted by exposure, sensitivity and migration complexity. The point is to separate simple, low-impact content from records that need access review, segregation decisions or remediation before they are moved into a new authority.
How to sequence migration without importing the old risk profile
Migration should start only after the programme has identified the obvious exposure gaps, for example broad access, shared ownership, stale accounts, unclear retention or duplicated stores that can be removed before transfer. If those issues are carried across unchanged, the reorganisation simply recreates the old environment under a new organisational structure.
That is why councils should treat migration as a controlled reduction in surface area, not as a bulk copy exercise. The safest path is usually to migrate in waves, beginning with content that is well understood, low sensitivity and operationally stable, while separately remediating high-risk repositories and service-linked access.
Where the data is tied to ongoing service delivery, migration planning should include both the content and the access model that supports it. NHIMG’s Ultimate Guide to NHIs, Lifecycle Processes for Managing NHIs supports that approach by tying lifecycle activity to governance, rotation and offboarding rather than treating access as an afterthought.
What good sequencing looks like in practice
Good sequencing has three visible properties. First, discovery output is detailed enough to support a risk-based migration order. Second, high-risk data and access paths are remediated before they are copied. Third, the programme can show that each migration wave reduced uncertainty, rather than simply moving that uncertainty into a new platform or authority boundary.
Teams often underestimate the value of discovery as a dependency check. Councils rarely fail because they lacked a migration tool, they fail because the tool was pointed at an incomplete picture, and the hardest repositories were left until the end, when remediation options were narrower and service pressure was higher.
To keep the sequence disciplined, councils should define a migration gate that requires discovery sign-off, sensitivity classification and an exception path for unresolved high-risk content. Top 10 NHI Issues is a useful reminder that visibility gaps, overprivilege and unmanaged credentials are not separate problems, they are the kinds of issues discovery is meant to uncover before they spread.
Risk and Threat Considerations
When discovery is skipped or compressed, the most likely failure is not immediate outage, it is silent risk transfer. Sensitive records, broad access paths and unmanaged service credentials can be reproduced in the target environment with less visibility than before, which makes later cleanup harder and compromise more persistent.
Failure mechanism: The programme migrates data and connected access before it understands where the high-risk stores, trust relationships and privileged paths are, so inherited exposure becomes embedded in the new structure.
Impact: The reorganisation can retain the old attack surface, preserve excessive access and create a fresh control gap around data that should have been remediated or excluded before transfer.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | Discovery and consolidation depend on knowing what systems and repositories exist. |
| CIS-6 — Access Control Management | Sequencing must account for who can reach sensitive council data before transfer. | |
| Recommendation — Inventory every system and repository before planning migration waves. Review and tighten access to high-risk data before migration. | ||
| NIST CSF 2.0 | ID.AM-01 — Physical devices and systems within the organization are inventoried | Reorganisation requires an inventory-first view of assets and data locations. |
| ID.RA-01 — Asset vulnerabilities are identified and documented | Discovery must surface sensitivity, exposure and dependency risk before migration. | |
| Recommendation — Build an inventory that covers systems, stores and dependencies before moving data. Document the most exposed repositories and remediate them before transfer. | ||
| ISO/IEC 27001:2022 | A.5.9 — Inventory of information and other associated assets | Councils need an asset and data inventory to sequence discovery ahead of migration. |
| Recommendation — Create and maintain an information asset inventory before consolidation starts. | ||
Practitioner Guidance
What to prioritise: Start with repositories and access paths that combine sensitivity, broad reach and unclear ownership. If a dataset or account can influence many services, or if its business owner is uncertain, it should move to the front of the remediation queue before any bulk transfer begins.
What to verify: Before each migration wave, verify that discovery has identified the system of record, the data classification, the effective access set and any service or automation account that depends on the source environment. If any of those are missing, the wave is not ready.
Practitioner takeaway: Councils get the best outcome when migration is treated as the final step of discovery-led risk reduction, not as the first visible sign of progress.