Recover a clear picture before committing to a new plan
A stalled web project rarely arrives with one tidy problem. There may be unfinished features, uncertain ownership, missing access, an unstable release process and several different accounts of what remains to be done. The immediate temptation is to start fixing whatever is most visible. That can create more work before anyone understands the delivery risk.
At Midoriweb, we begin by establishing what exists, what the business needs next and which evidence supports the current state. A rescue plan should make the project easier to control. It should not replace one vague promise with another deadline that has no technical basis.
This checklist helps you prepare for a structured recovery. It complements our project rescue team service. If the live store is currently unable to trade, use emergency support for the immediate incident; restoring service and replanning a wider project are related but different pieces of work.
Establish the business boundary
Write down the next outcome that matters. It might be releasing a working checkout, completing a migration or handing a maintainable application to an internal team. Separate that outcome from features that would be useful later. A rescue scope cannot stay controlled if every postponed idea becomes a launch requirement.
Record the trading constraints: critical dates, current manual workarounds, affected staff and any dependency on another supplier. State which dates are fixed externally and which are targets that can be reconsidered. This helps the team discuss trade-offs without pretending every requirement has the same urgency.
Identify a person who can make decisions about scope and acceptance. Technical work slows down when conflicting instructions arrive from several directions. A clear decision owner does not need to make every engineering choice, but should resolve business priorities and approve changes to the agreed outcome.
- 01EstablishOutcome, ownership and evidence
- 02TriageImpact, uncertainty and dependencies
- 03DeliverSmall releases with acceptance checks
- 04HandoverSource, operations and known limits
Collect an access and ownership inventory
List the repository, hosting, domain, DNS, deployment service, CMS, monitoring and important third-party integrations. For each, record the business owner, the current administrator and how authorised access will be arranged. Confirm that the business can retain control when a supplier relationship changes.
Do not paste credentials into the project brief or ordinary email. Use the agreed secure access mechanism, give only the access needed and record who can revoke it. If ownership is disputed or access cannot be granted, treat it as a delivery dependency rather than trying to work around the boundary.
Also gather licences, source agreements and existing handover documentation. A repository containing code is not the same as a reproducible build, and a working server is not proof that the business has the rights or access needed to maintain it. Resolve those gaps before promising a handover date.
Establish what is actually deployed
Identify the source revision running in each environment and how it got there. Compare the live installation with the repository where practical. Unrecorded server edits can disappear during a routine release, while a repository may contain work that has never reached production.
Record the platform and runtime versions, important dependencies and environment-specific configuration without exposing secrets. Locate the build instructions, deployment procedure and any rollback notes. Ask whether another authorised engineer could reproduce the release from the available material.
Check backups and restoration evidence. A successful backup job is useful, but it does not by itself demonstrate a complete recovery. Confirm what is included, how long restoration is expected to take and which changes would need reconciliation afterwards. Do not test a destructive restore on a trading environment.
| Area | Evidence to collect |
|---|---|
| Ownership | Business owner and authorised administrator for each service. |
| Source | Repository, deployed revision and any unrecorded changes. |
| Environment | Runtime, dependencies and reproducible build instructions. |
| Recovery | Backup coverage and evidence of an appropriate restoration test. |
| Acceptance | Complete business journeys, exceptions and named approver. |
| Handover | Release procedure, operational owner and known limitations. |
Worked example: “nearly finished” checkout
Imagine a fictional ecommerce project described as almost ready, with only checkout polish remaining. A review finds that a customer can place an ordinary order, but payment failure leaves an unclear page, delivery eligibility is inconsistent and the warehouse has not received a test order.
The project is not best described by a percentage complete. It has an incomplete order journey with several different acceptance gaps. The rescue plan should define the required states: successful payment, rejected payment, interrupted confirmation, valid delivery choices and confirmed downstream order handling.
The team then separates defects from missing requirements. A button styled incorrectly is a presentation defect. No agreed rule for a remote delivery area is a business decision. No test of the warehouse connection is a verification gap. Treating all three as “bugs” hides the different work and decisions needed to finish.
Triage by impact, uncertainty and dependency
Build a short issue register with a reproducible description, affected journey, evidence and proposed next action. Prioritise the items that prevent trading, threaten data correctness or block several other tasks. Keep cosmetic improvements visible, but do not let them obscure a broken business process.
Mark uncertainty explicitly. If an integration has never been exercised, allocate a discovery task before estimating its repair. If the cause of a failure is known, record the evidence and proposed correction. This makes the plan more credible than assigning precise effort to every unknown on the first day.
Group related work around outcomes. “Complete and verify order fulfilment” is more useful than a long disconnected list of API changes and screen edits. The technical tasks still matter, but the business should be able to see which completed journey they support.
Agree acceptance before restarting delivery
For each release outcome, define who will test it, which environment will be used and what evidence demonstrates completion. Include important exceptions, not only the normal path. The acceptance criteria should be understandable to the person approving the result.
Separate functional checks from content, accessibility, performance and operational checks where the scope requires them. A page can look finished while its form sends nothing; an integration can return success while producing the wrong business state. Verify the result at the point where the customer or staff member relies on it.
For Magento changes, our upgrade testing checklist offers a useful set of business journeys. For a platform move, use the migration checklist to cover catalogue, orders, URLs and release recovery.
Release in steps that can be reviewed and reversed
Choose a release boundary that fits the problem. A contained correction with a clear rollback may be appropriate before a larger improvement. Avoid mixing an urgent repair with unrelated redesign or dependency changes unless they are genuinely required for the outcome.
Record the source revision, configuration changes, data changes and verification for each release. A rollback plan must explain what happens to new business activity created after deployment; restoring old code does not automatically undo an order or reverse a data transformation.
Agree who watches the release and how an issue is escalated. The first period after deployment should have a named owner, meaningful checks and a decision point. “We will see if anyone reports a problem” is not a release verification plan.
Finish with a handover the business can use
The recovered project should leave a clear record of the system, its owners, release procedure and known limitations. Include the source location, important dependencies, operational tasks and the acceptance evidence. Keep a prioritised backlog for improvements that were deliberately left outside the recovery scope.
Ask the receiving team to walk through a normal release and a representative incident using the documentation. Gaps found during that exercise are cheaper to address while the delivery team is still involved. A handover is complete when the next team can understand and operate the agreed system, not merely when a folder has been shared.
To start a discussion with Midoriweb, bring the intended outcome, current blockers and whatever source or delivery evidence is available. Missing information is common in a rescue. The first useful step is to make those gaps visible and agree a practical route through them.