In Place Upgrade

What an in place upgrade changes

An in place upgrade replaces the software version while preserving the existing deployment footprint, host placement, and much of the current configuration. That makes it different from a rebuild or side-by-side migration, because the operational goal is continuity: keep the service running on the same environment while moving it onto a supported, fixed, or more capable release.

That continuity is why teams often prefer it when compatibility is high and the platform is stable. The trade-off is that the upgrade inherits the health, drift, and technical debt already present in the live environment, so the result is only as clean as the starting state.

Why organisations use this upgrade path

In place upgrades are attractive when downtime windows are limited, dependent systems are tightly coupled, or the cost of recreating the environment is high. They can shorten change planning, reduce revalidation effort, and preserve local customisations that would otherwise need to be rebuilt.

Security and IAM teams often care about this path because it can restore a supported version without forcing a full platform replacement. That can reduce change management overhead, but it also means the upgrade plan must account for existing roles, integrations, local agents, service dependencies, and any authentication or access configuration that has accumulated over time.

When the environment includes sensitive access paths, align the upgrade with NIST SP 800-53 Rev 5 Security and Privacy Controls so the operational change is still governed through configuration management, access control, and system integrity expectations.

Operational characteristics and common failure points

An in place upgrade usually depends on compatibility between the current release, the target release, and the surrounding environment. Failures often come from unsupported customisations, stale dependencies, incomplete pre-checks, or configuration values that no longer make sense after the new version starts.

Because the existing system remains in service, the upgrade can also preserve hidden weaknesses such as weak local permissions, outdated credentials handling, brittle automation, or undocumented exceptions. If those issues are not surfaced before the change, the upgrade may succeed technically while leaving the environment difficult to support or secure.

For that reason, many teams treat the upgrade as both a software change and a control review. The path works best when inventory, dependency mapping, and rollback assumptions are accurate enough to show what will actually remain in place after the version change.

Security implications after the upgrade

The main security benefit is that the organisation can move onto a supported release and close known exposure without introducing a completely new deployment. The main security risk is that any compromise, misconfiguration, or privilege accumulation already present in the environment may survive the upgrade if it is tied to the retained host, configuration, or identity model.

That is why in place upgrades are often followed by a focused review of access paths, service accounts, scheduled tasks, local admin rights, and logging continuity. If the upgraded system has been exposed, review it as a potential post-change compromise case, not just as a successful patch event.

When the retained environment includes machine-to-machine access or automated credentials, use OWASP Non-Human Identity Top 10 as a lens for secret handling, overprivilege, and credential lifecycle issues that can persist through the upgrade.

Risk and Threat Considerations

An in place upgrade can reduce exposure by getting systems onto a supported version quickly, but it can also preserve the very weaknesses the organisation hoped to leave behind. The security risk is highest when the upgrade is used as a shortcut over poor hygiene, because inherited configuration, access paths, and hidden dependencies can survive the version change.

Failure mechanism: Attackers or failure conditions exploit the retained environment, such as stale privileges, exposed services, vulnerable extensions, or incomplete validation, and the organisation assumes the version change removed more risk than it actually did.

Impact: The system may remain reachable, overprivileged, or inconsistently configured after the upgrade, creating continued compromise risk, operational instability, or delayed detection of post-change abuse.

Practitioner Guidance

Why practitioners should care: An in place upgrade is best treated as a controlled continuity event, not a simple version bump. The key judgement is whether the retained configuration is trustworthy enough to keep, because the upgrade path does not reset the environment’s underlying security posture.

What to watch for: Pay close attention to brittle dependencies, exceptions carried forward from the old release, and identity or access settings that were never meant to live beyond the original build. If those elements are not deliberately reviewed, they become part of the new baseline by default.

Practitioner takeaway: The safest in place upgrade is the one that preserves service continuity without preserving avoidable risk, so validate what must remain and deliberately retire everything else.

Related resources from NHI Mgmt Group

• What is the difference between an in-place upgrade and a migration to new infrastructure for identity security platforms?
• How should IT teams plan an in-place RHEL 8 to RHEL 9 upgrade without creating avoidable downtime?
• What governance controls should every enterprise put in place before deploying AI agents?
• How should security teams handle stolen OAuth tokens when MFA is already in place?