Taking over existing software: what to assess first

If your business has an IT team and a system that is still operating, the first question is what work to commission from a new vendor. Separate receiving the assets, understanding the system and implementing an improvement. Having the code does not tell you which scheduled job changes the data or which integration depends on an old business rule.

Our custom software handover guide covers receiving code, accounts and documentation. This guide addresses a separate decision: what assessment you need before committing to continued development or replacement. Maintenance scope defines subsequent recurring coverage; it does not replace the initial assessment.

Describe the journey that needs a decision: who starts an operation, which system stores the result, which team uses it and what observable failure motivates the change. Include frequency and impact your business can verify. A complaint that everything is slow does not yet distinguish a database query, an external service and a screen.

Agree which version, environments and components will be examined, authorized access, permitted tests and exclusions. Every finding should state how it was reproduced and what remained outside scope. A module review should not be described as a system-wide assessment. If an integration could not be tested, preserve that uncertainty in the conclusion.

Use a decision record containing the observed fact, operational consequence, evidence, unknown and next test. The vendor should explain what finding would change its recommendation. This is a Duotach proposal for comparing scopes, not a certification or a comprehensive security audit.

For example, an export task returning an error when the same batch is repeated can be investigated. A statement that the architecture is wrong needs evidence of where it prevents the required outcome. An inventory of old libraries can guide assessment, but does not determine whether the process should be rebuilt.

Request alternatives for the same operational outcome and constraints. Retaining the system may suffice when the problem is localized and the relevant journey can be tested. Replacing one component deserves evaluation when a clear boundary can be established. A rebuild needs to explain why bounded interventions cannot meet the objective and how transition will be verified.

AWS documents the Strangler Fig pattern for incremental migration from monoliths to microservices, with conditions and tradeoffs. It is a specific reference, not a reason to turn every application into microservices. Microsoft describes an adaptation layer between systems with different models, including latency, consistency and operational considerations. Both references were consulted on November 5, 2026.

A gradual approach retains dependencies during coexistence. Compare which system writes each record, how discrepancies are detected and when the previous component can be retired. Rolling back a deployment is not a sufficient answer when a change has already modified records or triggered external actions.

A fictional business uses an internal application to record requests and export them to another system. It wants to change vendors because retries produce duplicate records. Its bounded objective is that repeating an export must not create the same operation again at the destination. This teaching scenario is not a customer case or a measured improvement.

The assessment should follow the identifier from the request to the destination and establish what happens when the response is lost. If a stable identifier exists and the receiver allows the outcome to be queried, a correction to that part can be evaluated. If the receiver cannot distinguish operations, that limitation must be documented before a fix is promised. A new screen does not remove the unknown.

Agree an isolated acceptance exercise using authorized data: a normal send, a repeated send and recovery after an uncertain response. Record expected and observed results in both systems. The business accepts the agreed behavior, not merely a passing test or a successful demonstration.

Ask for a document connecting reviewed scope, reproducible findings, prioritized risks, alternatives and a proposed first intervention. Each alternative should state dependencies, limits and conditions for estimation. If access or evidence is missing, request the scoped activity needed to resolve it. A fixed figure without that boundary may price a different assumption.

Identify who validates the business rule and who authorizes the technical change. Agree which result permits continued work, which requires reassessment and who keeps the process operating meanwhile. Assessment, implementation and subsequent coverage need explicit scopes. Understanding and testing an existing system is commissioned work, not an implicit part of a sales inquiry.

Duotach develops custom business software. If you need to continue or extend an existing system, describe the affected process, intended change and documentation and access your business holds. Technical fit and scope must be checked before committing to intervention; receiving a repository does not mean every system can be accepted.

The form opens a project inquiry. Do not attach passwords or user data to explain the problem. Specific discovery, a code review or testing your systems requires an agreed scope of work.