1. Establish who owns the system.
Name a business sponsor and technical owner. List the current developer, implementation partner, host, license provider and any other party needed to operate the application. Distinguish access to an account from ownership of the underlying code or service.
- Record the organization that owns each repository, domain and hosting account.
- Locate contracts, license records and third-party dependencies.
- Confirm who can approve access and production changes.
- Identify critical operational dates and current escalation contacts.
2. Recover access through an agreed process.
Inventory the accounts and service identities used to operate the system. Use the organization’s authorized credential-management process to transfer access and review it. Do not collect passwords in a spreadsheet, email thread or website form.
- List administrator access for application, hosting, database and deployment tooling.
- Identify service accounts, integrations and scheduled jobs.
- Assign an owner for credential rotation and recovery.
- Review departed-user access without breaking an undocumented service dependency.
3. Make the application reproducible.
A source-code archive is not a complete handover. Someone else must be able to identify the production version and understand how to build, configure and release a change.
For an ERP, include custom-object source, extensions, configuration packages and the development tools needed for that release. If source or permissions are unavailable, record that constraint before committing to maintenance.
- Identify the production release and matching source revision.
- Document dependencies, build commands and configuration locations.
- Separate secrets from code and general documentation.
- Record test environments and the release/rollback procedure.
- Ask a second engineer to follow the instructions and record missing steps.
4. Demonstrate recovery, not just backup creation.
Record what is backed up, how often and who can restore it. A successful backup job alone does not prove that an application can be recovered. Agree a non-production recovery exercise appropriate to the environment.
Document data stores, files and external services that must be recovered together. If the original product is a hosted service approaching shutdown, establish export options and a transition plan while access still exists.
- Inventory databases, files, configuration and external dependencies.
- Record retention, restore access and recovery responsibilities.
- Demonstrate a restoration in an agreed safe environment.
- Validate the recovered workflow with its business owner.
5. Capture the work that crosses system boundaries.
List the critical imports, exports, scheduled tasks and manual handoffs. Document where records come from, how they are matched and what a failed run looks like.
Work through one failure with the operator. The resulting notes should explain what to check, when a retry is safe and who must approve a correction.
| For each workflow | Record this |
|---|---|
| Business owner | Who needs the output and accepts the result. |
| Source and destination | Systems, record types and relevant identifiers. |
| Schedule and identity | When it runs and which restricted service account it uses. |
| Failure and recovery | Alerts, diagnostic steps, duplicate checks and escalation. |
| Validation | How source and destination records are reconciled. |
6. Agree a realistic support boundary.
Separate incident triage, fixes to existing functionality and new development. Establish covered components, working hours, response targets, change windows and escalation. Record what depends on a vendor entitlement or another provider.
A successful handover ends with a named owner and usable documentation. It may also conclude that an unsupported dependency needs an upgrade before ongoing care can be responsibly offered.
- Prioritize immediate issues and known limitations.
- Agree who receives and triages incidents.
- Confirm access to manufacturer patches or specialist support where needed.
- Review runbooks and escalation with the receiving team.
- Keep the inventory current after each material change.
Put the plan into practice.
Bring one workflow and the systems involved. We can help define the support, implementation or integration scope.