Taking over an existing system may be a stressful and complex process for both the stakeholder and the new development team. At the same time, it’s not rare in the tech industry to hand over app maintenance to another team or to take over an existing product’s maintenance from another company.
IT project takeover starts with a technology audit. This first project phase is quite complex and consists of a few steps that we should not bypass in order to ensure effective system maintenance and smooth product development in the future.
The five key aspects we should take into account when taking over an application and running the technical audit include:
1. The infrastructure
2. The core
3. Integrations
4. Functioning
5. Ongoing development
Developing a meaningful tech audit makes it easier to plan the new team composition and streamlines the future development of the product. The outcome should consider all the above elements and the different ways in which they are interconnected.
In the next paragraphs, we’ll take a closer look at all the five points and provide a checklist to guide you through the technical side of app maintenance takeover.
The infrastructure
Unlike delivering new features and fixing existing problems in the code, it's generally much harder to change the base infrastructure or fix issues caused by incorrect communication between system elements. First, we need to take note of how the application works from a server perspective. We examine the process of delivering changes to the production environment, the current resource usage, and the ability to scale resources according to different needs.
When assessing the existing infrastructure, we aim to answer the following questions:
1. About the general shape of the infrastructure:
- Where are the servers hosted? In the cloud, or is everything configured on one server?
- Who owns the infrastructure?
- Is there a staging server configured the same way as the production server so that it’s possible to test the features before releasing them?
- Can servers automatically handle bigger and/or smaller workloads?
2. About the deployment process:
- What is the process of publishing changes?
- Is the process complex?
- Is the process automated, or does it involve manual input from someone familiar with specific procedures?
3. About the communication between different infrastructure elements:
- How do certain elements, such as application servers, database servers, and storage communicate with each other?
- Are the connections secure?
4. About the monitoring and logging process:
- Are servers monitored against security and performance issues?
- Are there any critical metrics that are constantly tracked and analyzed?
- Are logs stored so it’s easier to debug issues?
The core
The more complex the application, the higher the number of technologies used. Therefore, it’s important to note all technologies with versions, as well as how they depend on each other. To get the big picture of the direction toward which the previous development team was going, we need to inspect the history of changes and reasons behind choosing each technology for the application stack.
The checklist for this point includes:
1. Detailed overview of the technical stack:
- What technologies were used in app development? Provide information about all the technologies used along with versions.
- Why were these technologies chosen for the app’s tech stack?
2. Information about the documentation:
- Does the documentation exist?
- How the history of changes looks like?
- What is a test kit?
Integrations
Apart from internal communication, your application can also connect with external services and apps via the API. The next steps are to identify all these external connections, verify how many external libraries are in use, and assess the cost of having them in the product.
To get a complete overview of the integrations used in the application, we need to examine:
1. In terms of external services:
- How many external services are used? What are they?
- What is the monthly cost of these services?
- Does increased usage generate additional costs?
- How is the connection established?
- Are the credentials stored in a safe manner?
2. In terms of libraries:
- How many programming libraries are used? What are they?
- Can we eliminate some of them?
- How do they affect the performance?
- How do they affect the code quality?
Functioning
The functional part of the audit determines whether the service is functioning according to expectations. The code is scanned against security and quality issues. While the database is inspected to identify any performance and data integrity problems. The audit should also assess the development culture. Lack of code reviews or QA process may indicate that the code wasn’t tested properly or that its design may be inconsistent.
A complete check-up of the IT project functioning should cover:
1. A high-level overview of functioning:
- What are the current challenges?
- What are the development plans?
2. Examination of the codebase and database conditions using appropriate tools:
- Check the code quality.
- Check the security issues.
- Check the database structure.
3. Evaluation:
- Is there a code review? If yes, what are the acceptance rules?
- Is there QA in place?
- What development rules or strategies are used to deliver code?
4. Outline of access and security policies related to the development team:
- Is it possible to successfully rotate credentials so that the previous developers won’t have access?
- How often were people leaving and joining the team?
Ongoing development
Last but not least, the quality of the codebase and infrastructure is also reflected by characteristics of the task in progress, as well as the number and type of errors being handled but not yet fixed. Previous planning sessions and workshops can provide insights into how the development was planned, and how different problems were handled in the past.
The last part of the audit covers the following aspects:
1. How many and what kind of tasks are currently in progress?
2. Is there access to past planning sessions and workshops?
3. Is the error reporting system configured?
- How many errors are not yet fixed?
- How many errors were reported?
- What is the nature of the existing errors?
Summary
When taking over an existing IT project, it’s essential to check both the code and the environment. The application environment has a significant impact on the development process and can pinpoint some critical issues that need to be verified before the handover.
If you need to switch to a new development team with your IT project, drop us a line!
