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.
-
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
-
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
-
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?
-
Name the owner and the immediate risk
Decide who authorises access and who accepts the first result.
-
Restrict and record access
Grant the assessor only what the first step needs, and log every account used.
-
Freeze the baseline
Record versions, environments, credentials in use, incidents and pending releases.
-
Inspect the smallest relevant path
Reproduce one reported problem or review one blocked capability before any broad clean-up.
-
Separate facts from explanations
Mark each finding as observed, reported by someone, or still a hypothesis.
-
Define one bounded next action
Give it an acceptance check, a rollback route and an owner.
-
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.
-
Contain
Checkout is paused with a maintenance message; payment keys are rotated
- Owner
- Business owner with hosting provider
-
Recover access
The hosting, domain and admin accounts are traced to their holders; passwords and MFA are reset
- Owner
- Business sponsor
-
Preserve
Logs, the current code and a database copy are saved before any change
- Owner
- Assessor
-
Investigate
Code and database are scanned, logs and file permissions checked, and injected files listed
- Owner
- Assessor
-
Decide
The infected-file report and recovery plan go to the owner, who approves cleaning and hardening
- Owner
- Business owner
-
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.
(opens the full-size diagram in a new tab)
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.
Related services and solutions
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
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