Software delivery recovery

How to assess software inherited from another supplier

Before committing to deadlines or a rewrite, establish how the application operates, what the organisation owns and which unknowns could affect continuity.

By Chris Domville ยท 2 September 2026

Protect continuity before changing architecture

The first responsibility is to understand what must keep working. Identify critical users and workflows, recent incidents, service dependencies, recovery arrangements and any dates that create immediate operational risk.

A technically untidy system that runs the business is more valuable than a clean replacement that is not ready. Stabilisation and visibility come before ambitious change.

Confirm what the organisation actually controls

  • Source repositories, branches and build history
  • Cloud subscriptions, servers, domains and certificates
  • Database ownership, backups and restore evidence
  • Deployment pipelines, packages and external dependencies
  • Service accounts, secrets and third-party credentials
  • Licences, intellectual property and supplier agreements
  • Monitoring, incident records and support contacts

Reproduce the route from code to production

A repository is useful only if the application can be built, configured, tested and released. Establish whether a clean environment can reproduce the build, whether database changes are controlled and whether rollback or recovery is possible.

Document gaps as operational risks. Avoid making broad technical changes merely to prove familiarity with the codebase.

Map data, integrations and hidden responsibilities

Inherited software frequently relies on scheduled tasks, shared folders, spreadsheets, manual reconciliation and people who know which failures can be ignored. These dependencies may not appear in architecture diagrams but can be essential to the service.

Trace several important transactions end to end. This reveals ownership boundaries, data transformations and failure modes faster than reading every source file.

Separate urgent risks from technical preferences

Protect nowSecurity exposure, unsupported infrastructure, missing backups and single points of failure.
Stabilise nextMonitoring, repeatable builds, deployment safety, recurring incidents and performance.
Improve deliberatelyArchitecture, tests, maintainability, user experience and delivery throughput.
Defer consciouslyCosmetic refactoring and technology changes without a measurable outcome.

Produce a report that supports decisions

A useful assessment explains operational impact, confidence and recommended sequence in language that both technical and business stakeholders can evaluate. It should identify what remains unknown rather than disguising uncertainty with a numerical health score.

For a stalled programme or difficult supplier transition, Domville Tech offers a focused software project rescue and delivery recovery engagement.

Inherited a difficult system?

Establish control before making promises.

Discuss an assessment