Software takeover due diligence before changing suppliers

Verify ownership and access separately

List repositories, domains, cloud accounts, app-store records, certificates, vendor contracts and support channels. Confirm who legally owns the code and assets through the appropriate commercial review; an engineering inventory is not a legal opinion. Then verify operational access without moving secrets into shared documents. Record named owners, recovery methods and the process for changing permissions. A working administrator account is not enough if its recovery address belongs to a departing supplier. Include analytics and monitoring services that may be needed to understand the running product after the handover.

Reproduce the release path

Ask the incoming team to build a known revision and deploy it to an appropriate non-production environment. Compare it with the actual released behavior. Identify generated assets, local patches and configuration that are absent from version control. Check scheduled jobs, database migrations and external integration settings. Do not rotate or revoke production access casually while discovering dependencies; sequence those changes in an agreed transition plan. The handover should expose which operations are documented and which currently rely on a particular person’s memory. That knowledge is often more consequential than the number of source files delivered.

Check recovery and continuity

Review backups, restore instructions and the location of customer-uploaded data. Trace one failure report through the current support process. Deliver a takeover register with verified access, missing items, critical risks and the order of transition steps. Acceptance should include a clean build, a controlled deployment and a demonstrated recovery or a clearly documented recovery gap. Avoid interpreting a successful demonstration as proof that every hidden dependency has been found. Agree an observation period and a route for questions while the outgoing team is still available, rather than assuming all operational knowledge can be transferred in one meeting.

Agree how temporary access will be removed after the transition. The goal is to transfer ownership safely while avoiding both lingering unnecessary privileges and premature revocation that breaks a scheduled job nobody has yet connected to its credential.

Choose a staged commitment

The incoming team may need an initial assessment before promising full maintenance or a major feature release. Separate urgent continuity work from longer-term architecture changes so that supplier transition does not become an accidental rewrite. Arte Soft’s own published products establish a real software portfolio, not evidence of a particular client takeover. Bring the asset inventory, current supplier responsibilities and your next release requirement. A scoped due-diligence engagement can give you a list of conditions to resolve before transfer and a practical first maintenance boundary. That is more useful than accepting responsibility for a system whose release credentials have never been tested.

Relevant Arte Soft work

StoreFront Studio — our own product is our own product or engineering project. It provides context for the work we discuss here; it is not a claim of identical results for every client deployment.

Sources and further reading

• NIST Secure Software Development Framework ↗
• AWS Reliability Pillar ↗