Many organisations will have had on-premises datacentres or computer rooms, or have had their own servers and infrastructure in co-lo or hosted datacentres. Whilst these systems may have served a company’s needs in the past, it is often more complex and unknown systems that are the last to be evolved or modernised to cloud solutions. There will be a need to follow a plan for modernisation, rationalisation, migration, or retirement of legacy systems – such as resolving legacy hardware or systems, planning to migrate to cloud platforms, a new datacentre, as a result of a merger or acquisition, or the expiry of such systems.

Have a look at what is out there

The current usage of systems will require analysis, to find key parameters that will influence the most appropriate handling, destination, method of migration, or if the system should be removed. It is often the case that older systems have less understanding and documentation about them.

confidence to the client that you will find it out for them.

  • What are the locations? Office datacentres / computer rooms, off-site co-lo hosted datacentres? Branch offices? Interstate or international presence? 3rd party contracts?
    • Identify locations with consistent names – not just “the datacentre”, but include location suburb/building name and any hosting provider.
  • What servers and systems exist? What is in scope and what is excluded?
    • Produce a spreadsheet with a top-down focus (business function -> application -> server(s) -> hardware -> facility)Try and obtain a network architecture or diagram – this will assist later with scans.Are there multiple AD domains / networks / security boundaries (e.g. from a previous merger)?
    • What documentation is available? When was it last updated?
  • What is the licensing model and status of contracts?
    • How are servers and applications licensed?
      • Remember Microsoft, VMware, network hardware, backup hardware
      • Are licenses perpetual or subscription? When do they expire
      • Are licenses ‘named’ (per user) or concurrent connections or CPUs/cores?
      • Is backup software licensed by servers, or GB backed up etc.
    • What support contracts exist? Maintenance contracts and “right to upgrade” etc.
      • Applications may have maintenance agreements and separate support
  • What hardware exists?
    • Ask for a datacentre tour, and ask to take photos of racks/servers from front and back
    • Is there a CMDB (configuration management database) or asset register?
    • Don’t forget backup tape drives / autoloaders, KVM (keyboard, video, mouse)
    • Try and get model and version of each item – e.g. HP DL380 Gen7
    • Create a spreadsheet to include server network name, make, model, OS, version, patch level, condition, and other information as it is available
  • High level network and security investigation
    • Are there old systems that cannot be secured to modern/current standards?
    • Are there firewalls and is there an older “trusted network” layered architecture?
    • Is security documented or known?
      • Are user accounts audited – by the data owner / application owner?
      • Are network rules (ports, protocols, etc.) known and implemented?
READ ARTICLE:   VMware vs. AWS

Remember that the many IT shops may not be fully aware of each item that they have – record everything you can, including offline or powered off items, hardware that is not explicitly out of scope etc. to include in your report – finding something they were unaware of will increase confidence.

  • What is the business function of the in-scope systems?
  • How do applications interact and share information – what are the dependencies?
    • Include any out of scope systems that are communicated to by in-scope systems
    • Create an application architecture to show relationships and communication
  • What is the criticality of the in-scope systems?
    • How do they interact, get data, supply data, deliver services?
    • Assess applications and their data with the CIA triad (Confidentiality, Integrity, Availability).
    • Has a DR plan / Business Impact Assessment (BIA) been done to identify the MTD (Max Tolerable Downtime), RPO (Recovery Point Objective – amount data that can be lost) and RTO (Recovery Time Objective – how soon to be back up)?
  • What ‘unwritten’ information can you obtain?
    • Opinions, past experiences or incidents, views on costs or overheads
    • Stories on problems like getting parts or support or building/facility issues

Building on the initial baseline discovery, further detailed analysis can identify the priority systems, easy wins and previously unidentified benefits.

  • Review technical assets
    • List operating systems and patch levels.
    • List applications and versions.
    • List virtual machines and physical servers.
    • Include supporting infrastructure where appropriate – SANs, networks, backup
    • Consider a scanning tool like Belarc Advisor or use existing infrastructure tools;
      • HPE Systems Insight Manager
      • Microsoft SCCM / Intune
      • Dell OpenManage
      • Fujitsu ServerView
  • Per-server review
    • Ask for login to servers (admin not required) to review;
      • Applications installed – including tools and utilities, obsolete applications
      • Hardware management tools / utilities – and if they exist on a VM, it is a sign it was a P2V conversion that was not cleaned up
      • Hardware that is assigned – disks and disk space, CPUs and memory, interface cards and controllers. Is it adequate or over-sized?
    • Look for duplicates
      • Development, test, UAT servers
      • Load-balanced pairs and clustered machines
    • Review firmware and management utilities’ version.
      • Some firmware needs interim upgrades if it is very old. Most firmware updates cause downtime
      • Consider in your report the effort, risk, and impact firmware being out of date
    • Ask for information on hosting servers if VMware or Hyper-V is used for virtualisation
    • Look into shared storage (SAN, NAS, Fibre Channel networks, iSCSI networks)
  • Review the age of hardware and software
    • Find End of life for operating systems, hardware, applications and management toolsInvestigate driver availability for the current hardware with newer operating systems
      • Note that Windows servers before Server 2008R2 may be 32-bit and not upgradable
      • Consult the manufacturer’s website for parts and warranty replacements
        • Find the cost of a replacement disk and power supply
        Your report / business case should outline the cost and risk of operating older hardware, including parts and increased risk of failure, unable to get drivers and updates, unable to upgrade.Does the software / hardware vendor exist any more? Is there online documentation or help available for the product, or has the vendor removed it?
      • Does the software / hardware vendor offer any support, or do they charge high fees?
  • Options for the future;
    • Consolidation – move applications and services to the “newest” of old hardware.
    • Upgrade – add more hardware to the “newest” server to support more services.
    • Cloud or SaaS – but ensure that IaaS cost calculation includes data ingress/egress.
    • Data retention in a data warehouse
    • Data retention in backups – but must retain the restore equipment and software.
    • Retire – if systems are not delivering business value.
    • Application upgrade, or data transfer to SaaS version of same software
    • Extra protection for the legacy system – cybersecurity measures, hardware protection
  • For unique systems (SCADA, industrial control, OT, specialised systems)
    • If system is heavily customised or bespoke – is this delivering business value? Is it really required to be this way, or is it only “what we have always done”. A full BA analysis with a challenge of why it needs to be customised, to identify if there is an off-the-shelf solution or package available.
    • Investigate if the software vendor will support a change to the OS or hardware?
    • Are there custom licensing keys and hardware dongles required?
READ ARTICLE:   VMware product name glossary
Share this knowledge