Guidelines for Application Handover

Application Handover refers to transfer of ownership of a certain type of role, required for the healthy life of an application, from one person or a team to another person or another team. A badly executed handover is all the ingredients to cause a lot of frustration and wastage of resources across the board in an organization of any size. All these un-necessary costs can be avoided if certain points are remembered during and before accepting ownership from the person or team giving the handover. This also results in transparency in processes and help in making the organization more nimble to change thereby being more effective to deal with market forces.

Below is given list of things to do before accepting ownership of an application. This list is divided by role and might have repeating points across roles. These points assume a team setup described below.

Below are listed things that people in different roles should be made aware of.

• Level 1 support
  • User level working knowledge of the application.
  • Any L1 support specific machine setup that might be needed.
  • Any user accesses that need to be done specifically for this application.
  • Training on specific tools expected to be used by L1 which might be new for this application or are not generally used by L1.
  • Schedule and/or training on any reports that need to be generated from this application.
  • Schedule and/or training on any reports that need to be generated on L1 activity.
  • All previous release notes.
  • Any outstanding user issues.
  • Commonly occurring user problems and quick ways to resolve them.
  • Steps to quickly smoke test the application.
  • Location of any knowledge base or user training manual that has been created for L1 till now.
  • Any contact numbers, emails or channels for issue escalation to L2 and their availability timings.
  • Any contact numbers, emails or channels for issue escalation to infrastructure.
  • Escalation manuals/procedures (especially. if escalation involves third party.)
  • The working shifts if there is any exception to the regular work hours.
• Level 2 support
  • As many of the points listed under user training for L1 as possible.
  • Training on specific tools expected to be used by L2 which might be new for this application or are not generally used by L2.
  • Schedule and/or training on any reports that need to be generated on L2 activity.
  • Should ensure that the application demonstrates a minimum level of tracing and status tracking.
  • L2/L3 Leads should ensure that the application demonstrates a graceful failure with proper notifications being sent to the appropriate personnel.
  • Any readily available scripts to automate or perform regular operations or deal with regular issues on the application.
  • List of key application objects and key procedures.
  • Any L2 support specific machine setup that might be needed.
  • Complete knowledge about the deployment architecture.
  • Complete knowledge about the database and application architecture.
  • Complete knowledge about the dependencies (third party and non third party).
  • Knowledge about the disaster recovery plan/architecture of the application.
  • Knowledge about any commonly occurring user problems and quick ways to resolve them.
  • Knowledge about any other applications that might affect this application. If yes and the other application’s support is also managed by L2 then all the points in this section, about the other application should be known to L2.
  • Location of application documentation.
  • Any contact numbers, emails or channels for issue escalation to L3/Dev and their availability timings.
  • Any contact numbers, emails or channels for change control for production fixes.
  • Any other supportability details and accesses such as event logs, application logs, etc.
  • People awareness: Knowledge of the strengths and the weaknesses of different people in different teams.
• Level 3 Support / Development
  • As many points listed under user training for L1 and L2 as possible.
  • Training on specific tools, frameworks or languages to be used by L3/Dev which might be new for this application or not generally used by L3/Dev.
  • L2/L3 Leads should ensure that the application demonstrates a graceful failure with proper notifications being sent to the appropriate personnel.
  • The location of current release in production and the labels in source control which mark the code currently running in production, staging and in test.
  • Knowledge of the current version of the application source (with is running in production) in source control. The source control needs to be labelled with the release numbers and the developers need to be able to find the associated deployment setup for the application for that release/label. This setup needs to be verifiable from release management.
  • Business justification for different parts/functionalities of the application. This might require a listen-in on meetings of business/systems analysts with business.
  • Senior Developers, Designers and Architects need to have complete knowledge on the application and database design and architecture. They also need to have knowledge of any pre-existing or upcoming plans on any application redesign with has or will affect the current design of  the application.
  • Senior Developers, Designers and Architects need to be able to decide or help business decide the technology path to choose when required. This requires them to be updated on any upcoming language, platforms or frameworks.
  • Senior Developers, Designers and Architects need to understand how the application handles cross-cutting issues like exception handling and error management, logging, auditing, application security, data security, reliability of data, storage, state management, localization/globalization, versioning, code complexity, maintainability, etc., performance related issues such as scaling up or scaling out, parallelization and load management using effective infrastructure design. For applications with large and distributed user bases distributed/client side computation, data distribution, network related issues, application upgrade and user distribution issues need understanding as well.
  • Complete details on the application setup in the dev, test, staging environments.
  • Knowledge of how to and schedules to work with the integration development and testing teams.
  • Location of the complete documentation on the application. This documentation needs to contain the updated functional requirements documents (FRD) . The FRD needs to have links to all the change requests that have gone in the lifetime of the application till now. Note: Avoid using emails to track or change requirements. If there are a lot of emails that contain such requirement changes then these emails need to be coalesced into a document that needs to be linked into the updated functional requirements document. The same applies to any use case, business requirement documents that might have created for the application.
  • Any contact numbers, emails or channels for issue escalation to integration, business analysts, system analysts, architects or managers, change control and their availability timings.
  • People awareness: Knowledge of the strengths and the weaknesses of different people in different teams.
• Test
  • User level working knowledge of the application.
  • Business justification for different parts/functionalities of the application. This might require a listen-in on meetings of business/systems analysts with business.
  • Location of any knowledge base or user training manual that has been created for L1 till now. This knowledge base needs to contain the updated functional requirements documents (FRD) . The FRD needs to have links to all the change requests that have gone in the lifetime of the application till now. Note: Avoid using emails to track or change requirements. If there are a lot of emails that contain such requirement changes then these emails need to be coalesced into a document that needs to be linked into the updated functional requirements document. The same applies to any use case or any other documents that might have created for the application.
  • Training on specific tools, frameworks or languages to be used by testers which might be new for this application or not generally used by testers.
  • Any user accesses that need to be done specifically for this application.
  • Test lead should ensure that the application has a critical/major bug count below a set maximum count before the handover can take place.
  • Complete knowledge of any test plans for the previous and current version of the application and of any future test plans/schedules if some exist.
  • Complete details on the development, usage and maintenance of any pre-existing test suits being used to test the application.
  • Complete details on the application setup in the test and staging environments.
  • Knowledge of how to and schedules to work with the integration development and testing teams.
  • Schedule and/or training on any reports that need to be generated from this application.
  • Schedule and/or training on any reports that need to be generated on testing activity.
  • All previous release notes.
  • Any outstanding user issues.
  • Steps to quickly smoke test the application.
  • Any contact numbers, emails or channels for issue escalation to L3/Dev and their availability timings, change control for changes to test such as data refresh and integration development and testing teams.
  • Any contact numbers, emails or channels for issue escalation to business analysts, system analysts, architects or managers and their availability timings.
  • People awareness: Knowledge of the strengths and the weaknesses of different people in different teams.
• Business Analyst/Systems Analysts/SME
  • User level working knowledge of the application.
  • Business justification for different parts/functionalities of the application.
  • Location of any knowledge base or user training manual that has been created for L1 till now. This knowledge base needs to contain the updated functional requirements documents (FRD) . The FRD needs to have links to all the change requests that have gone in the lifetime of the application till now. Note: Avoid using emails to track or change requirements. If there are a lot of emails that contain such requirement changes then these emails need to be coalesced into a document that needs to be linked into the updated functional requirements document. The same applies to any use case, systems specifications document that might have created for the application.
  • Needs to be able to sufficiently understand technical language, processes and issues to be able to interpret them for business.
  • Needs to know the business and tricks of the trade very well.
  • Needs to know business by face since a person in this role is the primary owner of any kind of requirements or discussions with business from an application development process point of view.
  • Complete knowledge of any development, test and integration development and test schedules for past, current and future versions of the application.
  • People awareness: Knowledge of the strengths and the weaknesses of different people in different teams.
• Release Management
  • Complete knowledge of the location of change requests, deployment/release instructions, business justification, test sign off and corresponding source control label for all the releases that have gone in the application lifetime.
  • Complete knowledge of the application setup in various deployment environments production, UAT, staging and test.
  • Complete knowledge of the structure, versioning and history of code in source control and installers that are linked to any releases that have gone in test, UAT, staging or production. All of these releases must constitute corresponding code and setup installers for the rollback.
  • Complete knowledge of any existing or upcoming release plans for the application.
  • Any contact numbers, emails or channels for leads and members of L3/Dev, Release Management, Infrastructure, application sanity testing personnel and application managers along with their availability timings.
• Infrastructure
  • User level working knowledge of the application.
  • Knowledge of systems and integration aspects of the application.
  • Complete knowledge of the current infrastructure deployment design and disaster recovery plans/design/setup in the organisation for the application.
  • Complete knowledge of the current infrastructure setup in the organisation. They need to be able to help L3/Dev, management or business take a decision if the application handover can proceed without any updates/upgrades or any new software/patch is required to be installed.
  • Complete knowledge of the user setup or user migration related issues in test, UAT, staging and production. Also should know and probably lead the any kind of infrastructural issues that relate to user authentication, and user access on different objects such as servers, file-system objects, email accounts, etc.
  • Complete knowledge of any plans for infrastructural upgrades on key servers or user machines.
  • Any contact numbers, emails or channels for leads and members of L2, L3/Dev, Release Management, application sanity testing personnel and application managers along with their availability timings.
• Application Manager
  • User level working knowledge of the application.
  • Business justification for different parts/functionalities of the application
  • Knowledge of systems and integration aspects of the application.
  • Knowledge of how code is setup in source control and the current version in production and location of it’s associated artifacts.
  • Knowledge of the current infrastructure deployment design and disaster recovery plans/design/setup in the organisation for the application.
  • Complete knowledge of any development, test and integration development and test schedules for past, current and future versions of the application.
  • Complete knowledge of any and all documentation developed for the application.
  • Any contact numbers, emails or channels for leads and members of L1, L2, L3/Dev, Test, Business/Systems Analysts, Release Management and Infrastructure and their availability timings.
  • Needs to know the business by face since the manager might need to help them understand potential dev, test, integration, framework related issues to them or get deeper understanding about how business is working or expecting to work in future.
  • Knowledge of resource availability in the upcoming months.
  • People awareness: Knowledge of the strengths and the weaknesses of different people in different teams.
  • If a person in a certain role is leaving the application, then the manager needs to ensure to assign/allocate another person in the or having the capacity to be in the corresponding role to shadow this person (who is leaving) to learn as much as possible about the application.

Since every organization has a slightly different way of working, each has had it’s own set of issues. Hence, there might be points that I have missed. Please mail me or comment below to let me know any points that you think should be added to this list.

Thanks and Cheers!!!