Secure access and ownership
Confirm repositories, domains, hosting, databases, third-party accounts, licences and credentials are controlled by the appropriate party before changing suppliers.
- Source repository
- Hosting/cloud
- Domain/DNS
- Third-party services
Assess the code and environments
Establish whether the repository matches deployed code, whether staging is reliable, how releases work and where undocumented changes may exist.
- Branch/release history
- Environment differences
- Build/deploy process
- Configuration/secrets
Reconcile scope and status
Compare agreed requirements with actual functionality. Separate unfinished features, defects and entirely new expectations.
- Original scope
- Delivered functionality
- Known bugs
- Changed requirements
Build a recovery sequence
Address security/data risks first, establish a stable release process, then prioritise the shortest path to a useful outcome.
- Critical risk
- Release control
- Functional blockers
- Deferred technical debt
Questions to consider before you start
Should a new supplier quote the remaining project immediately?
A confident fixed quote before technical assessment may be risky if the existing state is unknown.
Should we rewrite everything?
Not automatically. A review should identify which components are viable and which create unacceptable risk.
Can work continue while the audit happens?
Sometimes urgent fixes must continue, but uncontrolled parallel change can make assessment harder.
Can Midoriweb perform the review and then hand it to someone else?
Yes. A diagnostic engagement can produce a recovery plan without requiring Midoriweb to execute it.
Explore connected services
Have a project that is stuck?
Send the current supplier/project status, technology and most urgent concern. We can scope an initial technical assessment.