How Should a Live Project Handover Be Managed When Changing Web Software Agencies?

Why should an agency transition be managed as a separate process?

An agency transition should be managed separately because live system continuity carries different risks from new feature development. If the incoming team does not yet understand the history of the codebase, business rules, sensitive integration points, and operating habits, starting development immediately can lead to unexpected outages, incorrect interventions, or changes that are difficult to reverse.

What is the primary objective of the handover?

The primary objective is to let the new agency observe the system safely before changing it and to clarify the conditions under which responsibility will transfer. This approach does not exclude the previous provider; instead, it reduces knowledge loss and gives the incoming provider a chance to see the system as it actually operates before separately planning maintenance, improvements, and new development. It also gives management a clearer basis for deciding which risks must be closed before takeover and which can move into the subsequent maintenance plan.

• Make every component supporting the live service visible
• Identify critical access and ownership gaps before the transition
• Verify backup and rollback methods before the first intervention
• Document responsibility boundaries between the outgoing and incoming teams
• Separate maintenance work from new development requests

Programs must be written for people to read, and only incidentally for machines to execute. - Harold Abelson and Gerald Jay Sussman

Which assets should the pre-handover technical inventory include?

The pre-handover technical inventory should not be limited to a source code list; it should cover all technical assets that keep the application running and the ownership relationships around them. Code repositories, domains, DNS records, servers, databases, file storage, email services, certificates, scheduled jobs, queues, and third-party accounts should be assessed together.

Why should the inventory be prepared as a relationship map?

Knowing the name of an asset is not enough; the new team also needs to see which systems depend on which services. In projects connected to APIs, ERP, CRM, payment, email, or identity services, mapping integration and data management relationships in the same inventory helps the incoming agency understand which other components could be affected by a change. Showing the technical owner, business owner, and access owner separately also helps the team reach the right person quickly during an incident.

• Source code repositories and the main branches in use
• Production, test, and development environments and databases
• Domain, DNS, SSL, and email service accounts
• Third-party API keys and critical integrations
• Scheduled jobs, queues, backups, and monitoring tools

Which access should the new agency receive before taking over?

Before taking over, the new agency should receive role-based and traceable access that is sufficient to inspect the system without enabling uncontrolled changes. Exact needs vary by architecture, but source code, server or cloud environment, database, domain management, logs, monitoring tools, and the third-party services used by the application are core review areas.

In what order should access be granted?

A more controlled model starts with read-only or limited review access and expands operational privileges only after responsibilities are verified. Especially for cloud and server management, keeping administrative accounts under company ownership instead of tying them to individual agency email addresses makes future provider transitions more resilient.

• Git or equivalent source code repository access
• Server, cloud console, and deployment infrastructure access
• Database and secure backup access
• DNS, domain, and certificate management access
• Log, monitoring, and third-party service access

Which areas and risks should the initial technical review cover?

The initial technical review should go beyond checking whether the system is running and should assess architecture, security, data, deployment, and operational risks together. The incoming agency should not begin by hunting for faults; its first objective is to understand how the system works, which components are critical, and what protective steps are necessary before making changes.

What outputs should be expected from the review report?

The review report should classify observations by importance and intervention need while avoiding unsupported recommendations for large-scale rewrites. When response behavior, error logs, monitoring coverage, backup restorability, and bottlenecks are assessed, a performance and continuity approach should also be treated as a natural part of the technical takeover.

• Application architecture and technology components in use
• Dependencies, packages, and areas exposed to update risk
• Authentication, authorization, and sensitive data flows
• Backup, restore, and deployment mechanisms
• Logging, monitoring, error alerts, and critical operational points

How does a codebase assessment affect the takeover decision?

A codebase assessment plays a central role in determining the new agency's maintenance capacity and initial intervention plan, but code quality alone is not an agency selection criterion. Judging a project only by formatting or coding conventions can be misleading unless business value, test coverage, documentation, dependencies, deployment practices, and the history behind major decisions are considered together.

How should the incoming agency review the code?

The initial assessment should focus on practical questions such as the understandability of critical modules, repeated structures, testability, configuration management, storage of secrets, and the path to production. The goal is not to grade the previous team, but to expose the points that could increase maintenance risk and the technical debt that may affect future development velocity. The review should also show which areas should remain untouched and where small, safe improvements can be prioritized.

• Understandability of folder and module structure
• Test coverage and ability to validate critical flows
• Dependency health and version conflict risk
• Management of environment settings and sensitive secrets
• Deployment, rollback, and change tracking practices

How should knowledge transfer with the outgoing agency be planned?

Knowledge transfer with the outgoing agency should not be compressed into a single meeting; it should be planned as a structured handover organized by topics and owners. The incoming team should prepare the technical inventory and its initial questions, while the outgoing team should explain unusual system behavior, manual operations, critical integration dependencies, and commonly encountered failure scenarios.

Which records should be kept during knowledge transfer?

Meeting notes, architecture diagrams, deployment steps, emergency procedures, and open issues should be maintained in a shared record. Any information that exists only in the memory of a previous team member should be converted into written process documentation, with a clear owner, validation method, and next action for every unresolved point. This reduces the need for the incoming team to repeatedly return to the previous provider with the same questions after transfer.

• Architecture and critical business rule walkthroughs
• Production deployment and rollback procedures
• Manually operated processes
• Known defects and temporary workarounds
• Open development items, pending decisions, and technical debt topics

Who should own the first response when a live incident occurs?

When an urgent issue occurs in production, first-response ownership should already be documented before the transition begins; responsibility should follow takeover status, not assumption. If the new agency is still in review mode, production intervention should not automatically be treated as its duty. The boundary among the outgoing provider, the internal team, and the incoming agency must be explicit.

How should an emergency response matrix be structured?

For each critical incident, the company should know who receives the alert, who starts technical diagnosis, who approves a production change, who communicates with stakeholders, and who performs a rollback if necessary. The new agency's responsibility can be tied to acceptance conditions such as completed access, verified backups, and acquisition of essential system knowledge. Production responsibility should not be assumed to have silently transferred before those conditions are met.

• The party responsible for receiving the alert and first notification
• The team running technical diagnosis and its permission level
• The person or role approving production changes
• The party deciding on and carrying out rollback
• The owner of incident records and stakeholder communication

How should access and account ownership be secured in transition?

Access and account ownership should be addressed at the beginning of an agency transition, not at the end; corporate ownership of critical accounts is a core handover control. If the domain, cloud account, code repository, email service, analytics tools, and third-party platforms are tied only to personal accounts at the current agency, the company carries a continuity risk.

When and how should old access be removed?

Removing all old access before new access is verified can create an outage, while leaving unnecessary accounts open after the transition creates a security risk. Contract scope and ownership terms around permission changes should be evaluated together with broader vendor governance topics such as what a web agency contract should include.

• Keep account ownership with the company or an authorized company user
• Manage multi-factor authentication through a corporate method
• Separate administrator, developer, and read-only roles
• Remove former users through a planned process
• Record permission changes with date and responsible owner

Why should handover and ongoing maintenance be quoted separately?

Handover and ongoing maintenance should be quoted separately because they have different goals, uncertainties, and deliverables; takeover work focuses on diagnosis and safe transition, while maintenance focuses on continuing operational responsibility. This separation prevents a company from committing to a long-term scope before seeing the initial review and makes it clearer what each candidate agency will own at each stage.

Which deliverables should be used to compare proposals?

The first phase can define a takeover checklist, technical review report, access matrix, risk list, and transition plan; the maintenance phase can separately define intervention scope, working method, change management, and reporting. When candidates are evaluated, an approach for comparing software company proposals helps make scope and responsibility differences visible instead of focusing only on total price.

• Takeover checklist and current-state inventory
• Initial technical review and prioritized risk report
• Access, ownership, and responsibility transition plan
• Maintenance scope and change request management method
• Separate handling of periodic reporting and development requests

How should post-handover monitoring and maintenance begin?

The post-handover period should not begin with major changes by the new agency; it should start as a period of observation, validation, and controlled improvement. The incoming team should monitor logs, error notifications, deployment flow, backups, and critical integrations, comparing assumptions from the initial review with the system's actual production behavior.

What operating framework should be established with the new agency?

The company and agency should establish a shared way of working for emergency communication, change approval, classification of maintenance requests, quotation of development work, and the content of technical reporting. In this model, a seamless project transition becomes more than a one-time delivery; it becomes a service relationship managed through measurable responsibilities.

• Observe critical system behavior on an ongoing basis
• Keep maintenance and new development in separate workflows
• Preserve approval and rollback steps for production changes
• Update the risk list with findings from live operation
• Present technical reporting in a form decision-makers can use