Taking over the app – best practices. Part one: the technological aspect

Paweł Dąbrowski - Chief Technology Officer

Taking over an existing system may be a stressful and complex process for both the app owner 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.

App maintenance 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:
    1. Where are the servers hosted? In the cloud, or is everything configured on one server?
    2. Who owns the infrastructure?
    3. 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?
    4. Can servers automatically handle bigger and/or smaller workloads?
  2. About the deployment process:
    1. What is the process of publishing changes?
    2. Is the process complex?
    3. Is the process automated, or does it involve manual input from someone familiar with specific procedures?
  3. About the communication between different infrastructure elements:
    1. How do certain elements, such as application servers, database servers, and storage communicate with each other?
    2. Are the connections secure?
  4. About the monitoring and logging process:
    1. Are servers monitored against security and performance issues?
    2. Are there any critical metrics that are constantly tracked and analyzed?
    3. 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:
    1. What technologies were used in app development? Provide information about all the technologies used along with versions.
    2. Why were these technologies chosen for the app’s tech stack?
  2. Information about the documentation:
    1. Does the documentation exist?
    2. How the history of changes looks like?
    3. What is the test suite?

      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:
    1. How many external services are used? What are they?
    2. What is the monthly cost of these services?
    3. Does increased usage generate additional costs?
    4. How is the connection established?
    5. Are the credentials stored in a safe manner?
  2. In terms of libraries:
    1. How many programming libraries are used? What are they?
    2. Can we eliminate some of them?
    3. How do they affect the performance?
    4. 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 app functioning should cover:

  1. A high-level overview of functioning:
    1. What are the current challenges?
    2. What are the development plans?
  2. Examination of the codebase and database conditions using appropriate tools:
    1. Check the code quality.
    2. Check the security issues.
    3. Check the database structure.
  3. Evaluation of the app maintenance:
    1. Is there a code review? If yes, what are the acceptance rules?
    2. Is there QA in place?
    3. What development rules or strategies are used to deliver code?
  4. Outline of access and security policies related to the development team:
    1. Is it possible to successfully rotate credentials so that the previous developers won’t have access?
    2. 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?
    1. How many errors are not yet fixed?
    2. How many errors were reported?
    3. What is the nature of the existing errors?

Summary

When taking over an existing system’s maintenance, 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 app maintenance, drop us a line!


Let’s get in touch
Author's Bio
Paweł Dąbrowski

Chief Technology Officer

Open source fan and growth seeker with over a decade of experience in writing for both human beings and computers. I connect the dots to create high-quality software, valuable relations with people and businesses.

Similar articles
Comments

Bulletproof your development with remote team augmentation

Read how
This page is best viewed in portrait mode
Our websites and web services use cookies. We use cookies and collected data to enhance your experience, provide additional communication channels, improve marketing materials and enhance our offer. IRONIN SP. Z O.O. SP. K. is committed to protecting all the data that we collect or process in any way, especially data of personal nature. By accepting these terms you agree to our usage of cookies and processing your data, according to our Privacy Policy, and you declare that your browser settings reflect your preferences. Read more You have the right to revoke this agreement at any time, based on the terms of our Privacy Policy. You can change cookies settings in your browser. If you do not agree with us using cookies and processing your data, please change your cookies settings in your web browser and reject these terms. You can find more information about cookies, your data privacy This site uses cookies. By continuing to browse the site, you are agreeing to our use of cookies. data processing, and your rights in our Privacy Policy.