What should organisations do before a major SaaS or cloud migration?

They should run a full entitlement review first, including contracts, overlaps, renewal dates, and underused tools. That gives the migration team a realistic cost baseline and exposes which products can be consolidated or retired before new spend is committed.

Why This Matters for Security Teams

A major SaaS or cloud migration is not just a procurement event. It is a control reset, a contract review, and often the first realistic chance to clean up dormant access, duplicated tooling, and hidden renewals before spend is locked into the new environment. NIST’s Cybersecurity Framework 2.0 treats this kind of transition as a governance and risk-management moment, not a simple technical cutover.

The mistake many organisations make is treating migration as an inventory exercise after the fact. By then, old SaaS licences, shadow IT, shared secrets, and overlapping admin paths are already embedded in the target state. NHIMG research shows how often identity and access maturity lags behind actual operational need, with the 2024 Non-Human Identity Security Report finding that 88.5% of organisations say non-human IAM practices lag behind or only match human IAM. That matters because migrations frequently copy weak access patterns into a new platform instead of correcting them.

In practice, many security teams discover entitlement sprawl only after migration crews have already signed the new contracts and started importing the same risks into a more expensive stack.

How It Works in Practice

The practical answer is to run a pre-migration entitlement review before any new SaaS or cloud commitment is approved. That review should map who and what has access today, which products are actually used, which contracts auto-renew, and where privileged or non-human access exists without a clear business owner. This is where identity, procurement, and architecture need to work from the same source of truth.

For human users, teams should validate role assignments, dormant accounts, and group memberships. For NHIs and service integrations, they should identify tokens, API keys, certificates, and workload identities that will need re-issuing, re-scoping, or retirement during the migration. A separate control pass should look for overlapping SaaS products that provide similar functions, because migration plans often preserve both old and new tools during transition and accidentally double the cost.

• Inventory every contract, renewal date, and cancellation notice window.
• Compare active entitlements against actual usage, not just licence counts.
• Identify shared secrets and long-lived credentials that can be removed before cutover.
• Classify admin, integration, and automation accounts as migration-critical assets.
• Document which systems can be consolidated, replaced, or retired.

For cloud migrations, this should be paired with a policy review so the target environment enforces least privilege from day one. NIST guidance and NHIMG research both point to the same operational lesson: migrations fail when organisations move access patterns first and ask questions later. The Salesloft OAuth token breach is a useful reminder that tokens and integrated access paths can become the real attack surface when trust in software relationships is too broad.

These controls tend to break down when the migration spans multiple business units and each owner negotiates separate exceptions, because entitlement cleanup stops being centralised and becomes a collection of local compromises.

Common Variations and Edge Cases

Tighter pre-migration review often increases coordination overhead, requiring organisations to balance speed against confidence. That tradeoff is real, especially when leadership wants a fast cutover and procurement wants to preserve vendor leverage. Current guidance suggests that the review should be risk-based: the most sensitive SaaS apps, cloud management planes, finance systems, and any environment with privileged automation should be assessed first.

There is no universal standard for how deep the review must go, but best practice is evolving toward including non-human access as a first-class category. That means service principals, workload identities, CI/CD secrets, and third-party integrations cannot be treated as implementation details. A cloud migration that ignores them usually recreates old exposure patterns in a new tenancy. NHIMG’s 2024 Non-Human Identity Security Report is relevant here because it reflects the broader maturity gap organisations are still trying to close.

Two edge cases deserve special handling. First, in mergers or divestitures, entitlement cleanup must account for legal ownership and data segregation, not just access efficiency. Second, in multi-cloud or heavily automated environments, migration planning should anticipate hidden dependencies so that one retired tool does not break downstream workflows. That is why a pre-migration entitlement review is both a financial control and a security control, not one or the other.

Related resources from NHI Mgmt Group

• How should organisations govern software assets across SaaS and cloud environments?
• Why do organisations keep Active Directory even after moving heavily to the cloud?
• What should organisations measure before trusting machine-speed remediation?
• What should organisations do before automating ticket triage or enrichment in ITSM?