Managing and migrating aged legacy systems

Practical advice for upgrading

So what should to be done about this migration of aged legacy systems? It is not something you should try by yourself.

Your job does not typically include just managing a security control system - it also includes ongoing examination of your enterprise's risks and vulnerability assessments. Are you addressing both day-to-day operational issues along with situations which may be emergencies or disaster scenarios? Is there willingness in the C Suite to confront the brutal facts of the current situation? Without a will, there may be little or no way. Getting this message delivered may require early involvement with a trusted advisor - which means having the right group vetted to arm and assist you.

Organize by looking at how things are interconnected - you may see how you can redirect or use alternate pathways and devices. Take advantage of existing resources to ensure you are developing a testable specification that is concise, unambiguous and easy for others to read. Your specification should define functional requirements in verifiable terms - not to specify how requirements are to be implemented and met.


Documenting your existing systems' infrastructure as it relates to wiring types and their location is critical. Some, but not all of this may have been provided when original systems were installed. Unless you had someone managing this piece of data, it is likely to be incomplete or out-of-date at best. This forensic assessment may require the acquisition of a third-party provider, trusted advisor and/or the current provider of your security controls.

This documentation should include all of your systems - intrusion detection, access controls, video surveillance, critical process/condition monitoring, infrastructure, power cabling and any other security applications you may have deployed for asset tracking, package delivery management, visitor management, ID management, audio systems and perimeter control devices and systems.

If you are verifying the operation of your systems on a regular basis, you are likely to have developed an internal checklist of components. The verification of system operation and functionality is one of the tenants of system management. Hopefully, some scheduled process is in place now and reports and materials used to document operations are available for your use.

The chart on page one of this article, which I call a Security Component Location Chart (SCLC), is one I have used for years. Regardless of what form you use to illustrate this type of information, the end-result will enable verification of location(s) and components installed.

This chart should be created with IT's assistance regarding the location of and availability of network drops and current locations of communications. Additionally, you should engage facilities management to ensure you have identified the locations and availability of power, how it is managed at the facility, back-up, and availability of dedicated circuits for your control system.

Needless to say, building and construction changes which may have occurred during the life of your system may have already made some device locations and their connection infrastructure obsolete and less than useful. Other challenges may emerge like how you and your facility management deal with abandoned communications wiring and devices, or abatement issues as they relate to disturbing areas where asbestos or other hazardous materials may have been used in years past.

All of this information will give you and your organization a realistic view of the existing "infrastructure" and conditions enabling you and your selected provider a reasonable starting point for determining how best to perform any migration strategy.

Naturally, once this information is developed, it must be managed like any other proprietary information - safeguarded and distributed only as your risk management plan provides.

Project Management Skills