Get a clearer picture of the software you inherited.

Investigate the failing task, access gaps and release process before committing to a complete replacement.

Reproduce what hurts the business

Start with an error or a repeated interruption and the people affected. We ask for the steps, recent changes and last known working behaviour, then inspect the relevant paths within your authorised access. A redacted example is often enough to begin.

An investigation can cover code structure, dependencies, logs, deployment steps, backup arrangements and third-party connections. We distinguish a verified cause from an unresolved lead and explain which missing access or vendor constraint limits the next step. The outcome should support a decision rather than present a long list of unfamiliar technologies.

Repair with a reviewable boundary

Where practical, reproduce the issue away from production and agree the check that demonstrates the repair. Consider adjacent records and workflows before release. A useful fix should preserve the parts staff depend on and leave a recovery route if the change fails an important check.

Improve the handover

Record how to run, release and support the application within the agreed scope. Keep account ownership with your organisation and identify ongoing maintenance responsibilities. An inherited system may need incremental repair while the team plans a later migration.

Investigate the handoff that stopped

Consider a fictional inherited application used by a Singapore service business. Appointment confirmations still work, but the job-to-invoice handoff stops after a supplier account or plan change. That timing is a lead, not a diagnosis. Begin with a read-only comparison of a fictional completed visit, the application's attempted transfer and the provider's documented account capability. The organisation's account owner asks the supplier what is currently supported; development access alone cannot settle that contractual question.

If the required operation is unavailable under the account arrangement, explain that dependency and the supported fallback before calling it a code defect. If an application error is reproduced, agree a staged correction in a private environment, including duplicate-attempt and rejection checks. A later authorised release needs evidence that the repaired handoff works and the previously working appointment remains intact. This illustrates a bounded investigation, not a claim that we have inspected a customer's application, gained provider approval or established a repair result without access.

Bring the error, current hosting arrangement and an inventory of access you control. Avoid sending passwords through the initial enquiry. For a planned move of records or content, see migration services.