Skip to main content

What are you looking for?

Explore our services and discover how we can help you achieve your goals

Software project rescue assessment: facts first, then the first safe step

A software project rescue assessment establishes what is actually running, who controls it, what is broken and what the first safe action is. You should come away with an access inventory, a frozen factual baseline, a ranked risk list and one scoped next step with its own acceptance test, before anyone promises a recovery or a rewrite.

Submit a project Start a technical audit

Reviewed by Huy Nguyen (David), CEO · Updated 28 Sep 2026 · 9 min read

star

OutsourcingVN is operated by Netbase JSC, which sells assessment and recovery work, so apply the same questions to any provider, including us. This guide draws on a recovery scope and a platform migration Netbase has delivered, and on what those projects showed about deciding between repair, transition and stopping.

Which route fits your symptoms?

Start from the symptom, not from the solution a supplier prefers. Each symptom has a different first action and a different owner.

Symptom First action Owner Likely route
Outage or broken core journey Contain and restore service from a known version Technical owner Bounded repair
Suspected compromise Preserve evidence, restrict access, then investigate Security owner Investigation, then recovery and hardening
Stalled roadmap Compare the backlog with what is actually deployed Product owner Revised brief and new milestones
Supplier dispute Secure access and request a structured handover Business sponsor Transition
Missing access Inventory accounts and recover ownership Business sponsor Access recovery before any engineering
Platform at end of life Assess migration against repair Technical owner Migration

If two symptoms apply, handle containment and access first. Engineering on a system you do not control only creates a second problem.

What should the assessment deliver?

A useful assessment leaves material that survives a change of people, a pause or a new supplier.

  • Access inventory. Every repository, cloud account, domain, deployment tool, third-party service and admin login, with its current holder.
  • Factual baseline. Running version, environments, recent releases, open incidents and the latest deployed artefact, recorded before anything changes.
  • Dependency map. Integrations, scheduled jobs, external services and the people whose knowledge the system relies on.
  • Risk list. Observed problems ranked by impact, each with its source and date, separating what was seen in the system from what a previous team said.
  • First bounded scope. One next action with an acceptance check, a rollback route and an owner.

Keep this material with the buyer, not only in a supplier's workspace. It is what makes a pause, a transition or an internal decision possible without repeating the investigation.

What did a real recovery scope contain?

Netbase scoped a three-phase recovery of a compromised Magento store for an existing client. The phases show how an assessment turns into work a buyer can approve step by step.

  1. Investigation

    Security scan with cause analysis; full source-code and database malware scan; server log, permission and abnormal-file checks; damage assessment

    Output
    Infected-file report and recovery plan
    Buyer decision
    Approve the recovery plan
  2. Cleaning and recovery

    Malware and backdoor removal; Magento core files restored at the matching version; permissions fixed; database cleaned

    Output
    A clean, running system
    Buyer decision
    Accept the recovered system for hardening
  3. Restore, recode and harden

    Damaged files, modules and themes repaired; Magento security patches applied; server and administrator area hardened

    Output
    A patched, hardened store
    Buyer decision
    Accept handover and next steps

The whole scope typically takes 6 to 13 days depending on the damage; that is a typical range, not a commitment. Recovery is never guaranteed, and the scope excluded rewriting modules or themes from scratch. The Magento recovery and hardening record describes the scope without naming the client.

The practical lesson is the order: investigation produces a report and a plan before any cleaning starts, and the buyer approves each phase on its output.

When is transition better than repair?

Sometimes the honest answer is to move rather than mend. A platform at end of life, an extension set nobody maintains or a codebase that cannot be patched safely may justify migration. For Netztech, Netbase delivered a Magento 1 to Magento 2 Commerce migration in 35 working days, including migrating 11 extensions with installation, configuration, customisation and data transfer. The Netztech migration record shows what a bounded migration scope contains.

Transition is also a governance exercise. Ask the outgoing team for repository ownership, deployment instructions, environment variables, architecture notes, known defects, backlog status and contacts; the handover and exit guide gives a transfer checklist. Check ownership too: for custom development the client owns the IP created for it; Netbase productized modules and products are licensed, not transferred. The IP ownership guide covers what to confirm with any previous supplier.

How should the first review run?

  1. Name the owner and the immediate risk

    Decide who authorises access and who accepts the first result.

  2. Restrict and record access

    Grant the assessor only what the first step needs, and log every account used.

  3. Freeze the baseline

    Record versions, environments, credentials in use, incidents and pending releases.

  4. Inspect the smallest relevant path

    Reproduce one reported problem or review one blocked capability before any broad clean-up.

  5. Separate facts from explanations

    Mark each finding as observed, reported by someone, or still a hypothesis.

  6. Define one bounded next action

    Give it an acceptance check, a rollback route and an owner.

  7. Decide whether to continue

    Repair, transition, a new delivery scope or closure are all valid outcomes.

The data security and compliance guide covers the access questions behind steps 2 and 3.

Worked scenario: a store that starts redirecting customers

An online store's customers report being sent to an unknown site at checkout. The previous developer has left, and the owner is not sure who holds the hosting login.

  1. Contain

    Checkout is paused with a maintenance message; payment keys are rotated

    Owner
    Business owner with hosting provider
  2. Recover access

    The hosting, domain and admin accounts are traced to their holders; passwords and MFA are reset

    Owner
    Business sponsor
  3. Preserve

    Logs, the current code and a database copy are saved before any change

    Owner
    Assessor
  4. Investigate

    Code and database are scanned, logs and file permissions checked, and injected files listed

    Owner
    Assessor
  5. Decide

    The infected-file report and recovery plan go to the owner, who approves cleaning and hardening

    Owner
    Business owner
  6. Accept

    Checkout reopens only after the recovered system passes an agreed test of the payment journey

    Owner
    Business owner and assessor

Nothing in step 4 starts before steps 1 to 3. Skipping preservation to "just fix it" is the most common way evidence of the cause is lost.

What are the red flags in a rescue proposal?

  • A fixed recovery date before anyone has looked. The damage is unknown until investigation ends.
  • A rewrite as the first recommendation. It may be right later, but it should follow an inspection.
  • Broad production access requested on day one. The first step needs less.
  • No preserved baseline. Changes start before the current state is recorded.
  • A guaranteed outcome. No honest assessor guarantees full recovery of a compromised system.
  • Upgrades bundled with recovery. Combining them makes it impossible to tell what fixed or broke what.

Which questions should you ask an assessor?

  • What will we have at the end of the assessment? Expect the five outputs listed above.
  • What access do you need first, and why? Look for a minimal, logged list.
  • How do you separate observed facts from reports? Expect each finding to carry a source and a date.
  • What are your security practices? At Netbase, security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request.
  • How will you report progress? Netbase delivery runs with weekly reviews and a named project manager; ask any assessor for a named contact and a rhythm.
  • What is excluded? Look for explicit exclusions such as rewriting modules from scratch.

How this guide is sourced and where it stops

This guide draws on two Netbase delivery records approved in the OutsourcingVN claim register, the recovery scope and the Netztech migration, and on the security, IP and review practices registered for Netbase. It is written for technical, product and operations leads facing a troubled project. It does not replace forensic, legal or insurance advice where an incident requires it, and the durations quoted describe specific scopes rather than estimates for yours.

Plan the next step for your project

Common questions

Often, if access and ownership can be established first. The assessment should state what is missing, such as credentials, deployment knowledge or undocumented integrations, and whether it can be recovered. Where it cannot, the first scope becomes access recovery rather than engineering.

Rarely as a first step. A rewrite may be right once the current behaviour, data and dependencies are understood, but deciding it before inspection risks rebuilding the same problems. An assessment should compare repair, migration and rewrite on evidence, then recommend one bounded next step.

It depends on the size of the system and how much access exists. As one registered example, a three-phase recovery of a compromised Magento store typically takes 6 to 13 days in total depending on the damage, including its investigation phase. Ask for a fixed first step with a defined output.

Where possible, yes, for a structured handover of access, source, deployment steps, known risks and open work. Keep requests factual and written. If the relationship has broken down, the assessment can proceed from what the buyer controls, and list what is still missing.

Repository and account ownership, deployment instructions, environment configuration, architecture notes, the defect list, backlog status and third-party contacts. Record what was received and when, so the next team knows what was handed over and what was reconstructed.

Start with the facts you can share

Bring the system, the immediate risk, who controls access and which decision is blocked. The Technical Audit Sprint is the bounded service for an assessment. Once findings are accepted, project delivery turns them into milestones, the software project brief template restates the outcome, and Custom Product Engineering covers a subsequent build with its own acceptance decision. The methodology explains how the records on this page are sourced.

OutsourcingVN is Netbase's own outsourcing-services platform. Submit a project with what you know so far, and a person will reply with whether a bounded assessment is the right next step.

Custom product engineering for a bounded release outcome Custom product engineering for a bounded release outcome

One defined release of your product, built to named outcomes and handed over with acceptance evidence.

Learn More
line
Technical audit sprint: a bounded evidence pack, not an opinion Technical audit sprint: a bounded evidence pack, not an opinion

A timeboxed project that answers one question with an evidence pack and a decision.

Learn More
line

Tell us what you want to build or automate.

Submit a project