When taking over the operation and further development of a legacy system, it is essential to gain a clear understanding of its complexity, strengths, and weaknesses. This allows for an accurate estimation of the effort and costs associated with maintenance and future development.

An IT audit uncovers technical, operational, and legal factors, demonstrating that software transition is far more than just handing over the source code. In practice, it is crucial to update key documentation, assess security risks, and review business requirements and SLA expectations. A well-structured audit ensures that concrete plans are in place from the beginning of the transition, helping to prevent future issues such as technical debt or data protection gaps.

Although an audit requires time and resources, it lays a solid foundation upon which the client and the service provider can confidently build their contract and collaboration.

By gaining a comprehensive view of the system’s current state, potential risks, and necessary improvements, both parties can avoid disputes and unexpected costs. In the long run, this approach not only offers financial benefits but also strengthens partnerships, which is essential for the continuous and successful operation of the software.

Multiple aspects need to be examined to thoroughly assess a software system. An IT audit should consider the following 9 key areas.

A critical aspect of an IT audit is assessing how well the system’s functionality and business processes are documented. Clear and up-to-date documentation significantly aids in understanding the expected behaviour of the software, as it is built to support specific business requirements.

However, if documentation is incomplete or entirely missing, the next step is to determine whether anyone within the company is still available who was involved in the software’s development or the definition of business requirements. If key individuals are still employed, interviews and discussions with them can provide crucial insights into the system’s intended operation and may even facilitate the reconstruction of missing documentation.

If no internal experts remain, the only option is to analyze the source code to map out the system’s functionality. This approach, however, often leads to challenges such as distinguishing whether a particular implementation is a feature or a bug.

A thorough understanding of a software system’s technological stack begins with identifying the programming languages, databases (both SQL and NoSQL), and message queue solutions in use. Additionally, it is crucial to examine the versioning and support status of these technologies in alignment with the software’s lifecycle plans—for example, whether security updates are still available for the versions in use.

Using outdated or unsupported versions poses security risks and can hinder development by restricting the adoption of newer frameworks and libraries. In such cases, it is advisable to plan for version upgrades as early as the transition phase to avoid future roadblocks.

Another key aspect is evaluating the availability and cost of skilled professionals for the given technologies, both internally and in the job market. For instance, finding developers experienced in Delphi can be challenging, and even within the company, there may be little interest in acquiring expertise in such a niche area. Similarly, hiring a PHP developer versus a senior Java developer may come with vastly different salary expectations. Resources such as LinkedIn Talent Insights, Glassdoor Salary Insights, Stack Overflow Developer Survey, or GitHub Trends can provide valuable data for this assessment.

Finally, every programming language, framework, library, and tool should be reviewed for licensing requirements to ensure compliance. If any commercially licensed technology is in use, it is critical to define in the operations contract who will bear the associated costs. Ignoring these factors can lead to unexpected expenses or legal complications down the line.

Gaining a clear understanding of a system’s size and complexity is crucial for accurately estimating the resources required for maintenance and further development. Software size can be assessed using quantitative metrics, which are relatively easy to generate but provide only an approximate overview. In contrast, complexity analysis offers a more precise understanding of the system’s structure and maintainability, though it requires significantly more effort.

When estimating software size, many immediately think of the Lines of Code (LOC) metric. While LOC can be generated relatively easily from the codebase and serves as a useful starting point, it can be misleading in terms of complexity.

Version control systems can also provide insights into codebase size and modularity, offering a broader perspective on the software’s structure. Additionally, other quantitative indicators can be useful in the initial assessment, such as data-related metrics (The number of databases, tables, and their interrelationships) or infrastructure metrics(The number of physical or virtual servers, or the count of containers in a containerized environment).

Beyond assessing software size, evaluating complexity is crucial for realistically estimating maintenance and development efforts. By considering both size and complexity, organizations can establish a solid foundation for planning future tasks.

To map out system complexity, various static and dynamic code analysis tools can be utilized. These tools analyze the codebase and runtime behaviour, generating key complexity metrics. Some widely used static code analysis tools include: SonarQube, Codacy, Deepsource, JetBrains Qodana.

One of the most commonly used metrics for assessing software complexity is Cyclomatic Complexity (CC), which measures the logical complexity of code based on the number of decision paths (branches) in the program. This metric can be calculated at different levels, including the entire codebase, individual modules, classes, or even functions.

The Halstead metrics provide a way to quantify code complexity and readability based on the number of operators and operands in the code.

A dependency graph visualizes the relationships and dependencies between system components and modules, offering insights into the overall complexity of the software.

The previously mentioned static code analysis tools can assist in defining and evaluating these metrics. By comparing the results obtained from these tools, a more accurate assessment of the system’s size and complexity can be achieved. This, in turn, facilitates the development of more effective maintenance and development strategies, ensuring that resource allocation and long-term planning are based on data-driven insights.