End-of-support dates are infrastructure deadlines

An end-of-support date looks straightforward on a vendor's lifecycle calendar. In a working business environment, however, it can represent months of discovery, planning, testing and controlled change before an ageing platform can safely be retired.

The real question is not simply when support ends. It is whether the organisation understands everything that depends on the platform and has enough time to replace it without disrupting the services it supports.

A support deadline should be the final milestone in a planned transition, not the point at which planning begins.

A support date is only the visible deadline

When a product reaches end of support, security updates, bug fixes and vendor assistance may no longer be available through normal support arrangements. That creates an obvious security concern, but the operational consequences can extend much further.

A server may appear to run a single application while also providing authentication, licensing, scheduled tasks, configuration services or storage access to other systems. Network devices can support connections between sites or applications that are poorly documented. Older platforms may also rely on software or integrations that are incompatible with current replacements.

These dependencies are often more significant than the age of the hardware itself.

The Australian Signals Directorate's Information Security Manual recommends removing or replacing unsupported applications, operating systems, network devices and other networked IT equipment. Where immediate replacement is not possible, compensating security controls should be implemented until those systems can be retired.

Those controls can help manage the immediate exposure, but they are not a substitute for a sustainable replacement plan.

Why lifecycle planning needs to start early

Microsoft Windows Server 2016 provides a timely example.

Extended support for Windows Server 2016 ends on 12 January 2027, according to Microsoft's published lifecycle schedule.

For organisations still operating the platform, the work may involve considerably more than installing a newer operating system.

Before a replacement can proceed safely, the business may need to establish whether its applications remain supported, whether integrations and authentication methods will continue to function, and whether the underlying infrastructure can accommodate the proposed change.

Migration planning must also account for data, configuration, backup and recovery arrangements, operational testing and the ability to recover from an unsuccessful cutover.

A technically successful upgrade is of limited value if the business service it supports no longer works as expected.

This is why lifecycle planning is best treated as an ongoing infrastructure responsibility rather than a project initiated when a vendor deadline becomes urgent.

An inventory tells you what exists, not what depends on it

Accurate asset registers are an essential starting point. They establish which systems exist, the software and firmware they operate, and the support boundaries approaching.

But an asset register does not necessarily explain what will be affected when a system changes.

An ageing server might still support a legacy application, an authentication integration, a certificate, a service account or a fixed network relationship. Its backup configuration may be documented, while the process required to restore the complete service has never been tested.

These relationships can remain unnoticed during normal operation because the infrastructure continues to function.

The consequences become visible when something changes.

Effective lifecycle planning therefore needs to connect technology assets to the business services they support. The objective is to understand not only what needs replacing, but what must continue working throughout the transition.

This changes the scope of the work from replacing an old system to maintaining a business service through a controlled infrastructure change.

Infrastructure lifecycle belongs in normal governance

For regulated organisations, the importance of ongoing infrastructure oversight is already reflected in formal requirements.

APRA's Prudential Standard CPS 230 requires APRA-regulated entities to maintain appropriate technology capability and monitor the age and health of their information assets.

Although these obligations do not apply to every Australian business, the underlying principle has broader relevance.

Organisations benefit from understanding which systems are approaching end of support, the services that depend on them, and the practical consequences of delaying replacement.

That knowledge supports better investment decisions. It also allows infrastructure changes to be prioritised alongside business requirements rather than driven solely by equipment age or vendor announcements.

A well-maintained lifecycle view helps distinguish between systems that can be retired with limited disruption and those requiring more substantial architecture, migration or operational planning.

It also provides a clearer basis for deciding where temporary risk controls are necessary while a longer-term solution is developed.

The replacement needs to work before the old system is retired

Selecting a replacement platform is only part of the outcome.

The new environment must support the intended business function, including its applications, users, access controls, integrations and operational dependencies.

Testing should provide confidence that the replacement behaves as expected under realistic conditions and that the organisation can manage a failed change without unnecessary disruption.

This may involve application compatibility testing, data validation, connectivity checks, backup and recovery verification, and confirming that monitoring and ongoing administration remain effective.

The depth of testing will depend on the importance and complexity of the service.

What matters is that the decision to retire the original platform is based on evidence that the replacement is ready, not simply confirmation that the new hardware or operating system has been installed.

Four questions worth answering before end of support

For any significant system approaching a lifecycle deadline, leadership should be able to answer four practical questions:

1. What business services still depend on it? Understand the applications, users, integrations and infrastructure relationships that could be affected.
2. What is the intended replacement or retirement path? Establish whether the appropriate outcome is an upgrade, migration, redesign, consolidation or complete retirement.
3. What evidence will demonstrate that the replacement works? Define the service outcomes that must be validated before the original platform is removed.
4. Who owns the decision and the remaining work? Confirm accountability for planning, investment, implementation and operational handover.

If these answers are unclear, the approaching support date is already an infrastructure planning issue.

Making infrastructure lifecycle decisions with confidence

Not every ageing system requires an extensive transformation project. Some can be replaced through routine maintenance, while others support business functions that make change substantially more complex.

The challenge is identifying the difference early enough to make an informed decision.

A structured Infrastructure Review can help establish the current environment, identify ageing platforms and their dependencies, and determine which lifecycle issues deserve priority.

Where the findings point towards migration, architecture changes or replacement infrastructure, a defined Infrastructure Design & Delivery engagement can provide a path through implementation, testing and operational handover.

The objective is not to replace technology simply because it has reached a particular age.

It is to ensure that infrastructure continues to support the business, with lifecycle decisions made while there is still time to plan, test and transition safely.

A vendor can tell you when support ends. Understanding what needs to happen before that date is an infrastructure responsibility.