Tech & architecture 
The short answer
The first days of a takeover make an application understandable and operable by the new team. Arrange service continuity, verify access, connect the code to the live version, examine data and backups, then establish priorities. A first change can then be prepared with tests, approvals and an appropriate recovery procedure.
Three priorities when taking over
- 01Identify who operates the service and handles incidents during handover.
- 02Verify access, the live version and recovery conditions.
- 03Prepare a limited, observable and approved first intervention.
01
Arrange continuity before taking over
Handover starts with a simple question: who responds if the application encounters a problem today? Identify the business contact, the person able to act on the service and how to report an incident. If the outgoing team remains involved, clarify its responsibilities and the agreed transition period.
Gather open incidents, ongoing changes, known deadlines and important processes. A planned update, service expiry or data operation may alter the order of initial actions. Users should know where to send requests during this period.
The stages in this article describe an adaptable sequence of work. They are not a delivery commitment: available access, complexity and service condition determine the effort required. An active incident may need immediate attention alongside the handover.
Clarify responsibilities at the start
- 01
Business decisions
Who decides priorities and approves consequences for the business?
- 02
Operations
Who can intervene in the live environment and its services?
- 03
Handover
Who provides available code, access, documents and explanations?
- 04
Communication
Who informs relevant teams and centralises incidents?
02
Verify usable access and accounts
Inventory necessary accounts: source repository, hosting, databases, files, domain, DNS, external services and monitoring tools. For a mobile application, include publication accounts and the items needed to prepare releases. Identify the owner, administrator and people authorised to intervene.
Check access against the intended role. Being able to view a repository does not establish that the team can prepare a release or administer the environment. Arrange individual access appropriate to responsibilities, along with recovery options. Transmit secrets through a suitable channel and keep them separate from general documentation.
If a secret has been exposed in a repository, GitHub recommends revoking or rotating it; removing its visible presence does not make it unusable. Assign this action to the responsible person and identify services using the affected credential. Rotation needs to account for their configuration and verification of operation.
An actionable access inventory
- The service and its role in the application
- The identified account owner and administrators
- Roles granted to the new team
- Verified operation of each necessary access
- Secret management and recovery options
- Access to remove or change under the agreed transition
Technical sources
03
Connect the code to the version running in production
Find the repository, branch or revision corresponding to the live version, then how it was built and released. The latest available code may differ from what actually runs. Also examine configuration: environment variables, tool versions, dependencies and expected services.
Prepare a separate working environment and check that the application can run there with appropriate data. Testing must account for external effects: emails, payments, notifications or calls to other systems. Arrange test settings and appropriate access before running these journeys.
Document commands, prerequisites and steps that actually worked. If preparation remains manual or depends on one person, make that dependency visible. Another team member should be able to understand and reproduce the process without rediscovering every answer by trial and error.
Connect these elements
- 01
Code
An identified revision and relevant change history.
- 02
Build
Tools, dependencies and steps needed to prepare a release.
- 03
Configuration
Settings and services expected in each environment.
- 04
Publication
Delivered version, target environment and procedure followed.
04
Understand data and verify recovery
Find where information is stored: databases, files, external storage and connected tools. Identify important relationships, automated processes and exchange owners. An application may depend on documents or data outside its main database.
AWS Well-Architected recommends periodically restoring backups and verifying that recovered data is usable. For a takeover, examine existing backups and run a trial in a suitable environment with the necessary authorisations and protections. Criteria should address the data and service to recover.
Record what was restored, checks performed, limitations and observed duration. Also verify items surrounding the database: files, configuration and connections. If recovery remains uncertain, that uncertainty should influence proposed interventions before any significant data change.
Evidence to keep after a trial
- Origin, date and scope of the backup used
- Restoration environment and procedure
- Checks on relevant information, files and relationships
- Results of journeys tested after recovery
- Observed duration and gaps against business needs
- Limitations, remaining actions and responsible person
Technical sources
05
Walk through the product with people who know the business
Describe a small set of essential journeys: signing in, creating and processing a request, passing information on and retrieving its history, as appropriate to the product. Identify roles, approvals, exceptions and messages sent. Observe what happens in the application and its surrounding tools.
Important rules are not always in a document. Some live in a calculation, an export, a scheduled job or a team habit. Ask about special cases and known workarounds. Distinguish expected operation, current behaviour and problems temporarily accepted.
The fictional scenario below illustrates a point to investigate. It describes neither a Gaspa client incident nor a client result.
Describe a dependency clearly
- 01
Trigger
The action, schedule or event that starts the process.
- 02
Information
Data read, created or changed, and the system of record.
- 03
Exchange
The service, recipient or file involved in the journey.
- 04
Failure and recovery
Error signals, the person to inform and how to resume processing.
06
Establish a baseline and order priorities
Before initial changes, gather available operational information: known incidents, errors, response times and pending jobs, according to the service. Record the observation period and conditions. If visibility is insufficient, identify the first checks to establish.
Google SRE describes monitoring as a way to assess service health, investigate problems and compare behaviour before and after a change. Choose signals connected to important usage and specify who reviews them. A dashboard should support a decision to act.
Classify actions with your team: an incident to address, a risk to reduce, missing information to obtain or an improvement to prepare. Connect each priority to a product consequence and next action. An old dependency and a defect blocking a journey do not necessarily call for the same response.
An understandable priority register
- 01
Finding
Behaviour or missing information, with evidence and context.
- 02
Consequence
Affected users, data, processes or ability to intervene.
- 03
Action
A fix, check or information needed to move forward.
- 04
Owner
The person responsible for the next step and its acceptance condition.
07
Prepare a limited, verifiable first intervention
Choose a change with an understood scope and purpose. Describe affected journeys, surrounding areas to verify and acceptance criteria. The first intervention also confirms that the team can prepare, test and release a version under the planned conditions.
Specify who authorises release, how results will be observed and when to stop. Examine returning to a previous version alongside affected data and processes. If information has changed in the meantime, reconciliation or replay may be necessary rather than blindly restoring an older state.
After delivery, verify selected journeys and signals, record results and inform the business team. Lessons from the first work package help adjust subsequent interventions. A broader redesign or rewrite decision can then be prepared from these findings and future needs.
Conditions to verify before release
- Shared scope, purpose and acceptance criteria
- Current version identified and preparation of the new version understood
- Tests of journeys and effects on connected services
- Data and recovery options examined
- Authorisation, stopping conditions and owners identified
- Post-release checks and communication to relevant people
Choose a direction after taking over
08
Make the takeover useful for subsequent work with Gaspa
By the end of this initial phase, the team should be able to explain how the service works, which access it controls and which limitations remain open. Deliverables should connect technical information to decisions and responsibilities: an inventory, working procedures, critical journeys, a baseline and an action plan.
Gaspa supports UX and technical audits, maintenance and application redesign. Our method provides one main contact, conversations with relevant specialists and shared approvals. Takeover objectives, information to hand over and support arrangements should be clarified with your team before interventions.
Handover continues as the product evolves. Update documentation, access and procedures after changes affecting them. The intended outcome is a lasting ability to understand, maintain and evolve the application, with priorities understood by business and technical teams.
Initial takeover deliverables
- 01
Verified inventory
Access, accounts, code, data, services and owners.
- 02
Usable procedures
Environment setup, publication and recovery, including limitations.
- 03
Journeys and baseline
Essential scenarios, known incidents and initial monitoring signals.
- 04
First intervention plan
Priorities, remaining checks, responsibilities and acceptance criteria.