Custom software takeover: prove the handover works

Before the technical review, name the activities whose interruption would have immediate consequences: entering orders, preparing deliveries, invoicing or retrieving a customer file. Give each activity a business owner and an expected result. Identify periods that complicate an intervention, such as financial close, payroll or seasonal demand. The handover schedule should reflect those constraints, and the people accepting the result should be available.

A takeover can preserve much of the existing system while replacing a fragile component. An assessment of a custom web application should distinguish defects that prevent operation, risks to address before the switch and improvements that can wait. That separation gives the transfer a workable boundary and avoids making every handover decision dependent on a complete redesign.

Build the inventory with a company representative and both technical teams where possible. For each account, record the owning organization, administrator, recovery method, payer and dependent services. Shared credentials may work today while making it impossible to identify who changed a configuration. Plan named accounts and an administrative backup. Avoid putting passwords or recovery codes in the handover report itself; reference the approved storage location.

Moving a repository does not automatically move every company asset. GitHub’s documentation describes consequences specific to repository transfers; it does not replace an inventory of hosting, licences and integrations. Check contractual rights to the code and its components as well. Possessing a file does not establish a right to modify or redistribute it. Resolve ownership questions with the appropriate company representative before relying on access alone.

Ask the incoming team to work from a clean machine or environment using its own accounts. It should retrieve the agreed repository version, install dependencies and produce an operational build. Record tool versions and the required steps. If a command works only on the previous supplier’s computer, document that dependency and resolve it. A successful screen demonstration on that computer does not settle the reproducibility question.

Next, demonstrate data recovery. A backup described as daily should be restored in isolation and checked with the business owner. Verify that expected records and attachments exist and their relationships remain usable. NIST’s contingency planning guidance helps frame these exercises; it does not establish that any particular restoration succeeded. Keep the observed result with the backup date, environment and application version used during the exercise.

Then run a complete workflow. For a custom CRM or ERP, that might involve creating a fictional record, approving it and exporting the result. Use accounts with different roles. Retain the observed outcome, relevant logs and the business owner’s decision. This guide describes an acceptance method and does not report tests performed on a customer’s application.

Imagine a distributor whose application prepares orders. The company owns the code repository, but notifications still pass through a former administrator’s personal account. In a test environment, the incoming team creates an order successfully and the confirmation message fails. The handover remains incomplete even though the main page loads and users can browse the order list.

In this hypothetical example, the handover record requires a company-owned email account, the appropriate authorization and a repeated acceptance scenario. The existing operational route remains available until acceptance. No timeline or measured gain is assumed. The exercise identifies a missing proof and the person responsible for producing it. The company can now distinguish a repairable dependency from a vague statement that the system is ready.

A condition should identify a specific defect, its impact, an owner and a review date. It should not conceal an inability to operate the application. The business signatory accepts operational consequences, while the technical signatory records the evidence produced. A rejection should explain what is needed for another acceptance review without treating an untested hypothesis as a final diagnosis.

Before switching, decide when data entry pauses, who watches the new environment and what event triggers a return. Restoring an older backup can remove recent operations. Define how the team will recover and reconcile changes entered after that backup. The decision must cover data as well as the software version. Record who can authorize the return and how staff will learn which system to use.

CRM and ERP automations deserve their own inventory: scheduled jobs, webhooks, queues and manual recovery actions. During an overlap, two processes may read the same event. Check which system may write and how it recognizes a previously handled operation. Keep a change log during the transfer window so an investigation does not depend on someone remembering a configuration change.

Retire previous access using an approved list and rotate affected secrets. Avoid premature revocation that would prevent an agreed return. OWASP ASVS provides useful criteria for discussing access controls and logging. The final handover package should let another authorized person find the evidence and operate the documented process without relying entirely on the incoming supplier’s memory.