What should a custom software exit plan let you take with you?
Format: Article.
An exit plan should say what your team can take to a new provider and how it will get there. Agree on the records, files and help you need in writing. “You own it” does not say which files you will receive, whether you can open them or who will help with the move.
Plan the exit while the relationship is healthy. The point is not to predict a dispute. It is to avoid discovering, during a deadline, that an export has no attachments or that the only administrator belongs to a departing vendor.
Specify a usable package
A large export is not always a useful one. Ask which records it holds, how they link and what each field means. The next team needs IDs that stay the same and dates it can read. It also needs to know why a case is open, not just that it is open.
Use this checklist in the scope discussion. Mark each item included, excluded or unresolved, with a written term reference.
| Exit item | Practical deliverable | Test before dependence grows |
|---|---|---|
| Records | Agreed CSV, JSON or other readable format with field definitions | Open a sample without the original application |
| Relationships | Stable IDs and links between related records | Rebuild one complete case from the export |
| Attachments | Original files where permitted, plus an index linking them to records | Open a file and match it to the correct record |
| History | Agreed changes, approvals and unresolved states | Explain why a sampled item is held |
| Configuration | Documented rules, mappings and relevant settings within scope | Identify what a successor must recreate |
| Access transfer | Account ownership, admin roles and approved transfer method | Verify the receiving administrator's access |
| Third-party dependencies | Components, licenses, provider accounts and restrictions | Identify what can transfer and what needs a new agreement |
| Assistance | Named tasks, timing, fees if any and deletion responsibilities | Confirm who handles the final reconciliation |
Keep passwords and access tokens out of the export. Agree on a separate process to transfer accounts and replace secrets, with the right person's approval. Check the provider's terms before assuming an account can move. Being able to sign in does not settle the right to transfer it.
Distinguish source rights from operating access
Check the written terms for the code. Some may transfer to you. Some may stay under a license or be excluded. Outside software and hosted services can have their own terms. Ask a qualified contract reviewer to check them. Do not assume the whole system becomes your property because you paid for the build.
SPDX provides a format for sharing details about system parts and how they relate.[8] A list of those parts can help you see which outside code and services the build needs. The list itself does not give you the right to use, change or share those parts.
Ask the builder to list custom work apart from outside code and services. For each item, ask what rights the next team needs to keep it running. Record open questions for the contract reviewer. A label such as “open source” is not a substitute for checking the actual license and intended use.
A hypothetical export that falls short
Imagine an established company moving its internal review queue to a new provider. The old vendor supplies a spreadsheet with case names and current statuses. It looks complete until the operations lead tries to resume an open case.
The case refers to an attachment stored behind the old application's login. Its export row contains only a temporary link. The reason for the hold is in a comment history that was not included. The successor cannot safely infer either fact from the final status.
In this hypothetical example, ask the next team to rebuild an open case, a closed case and a case with a file. Can they find the right file from its case ID? Can they explain the hold? Those checks test whether the export preserves the links and history they are allowed to take.
If attachments cannot be transferred under the agreed terms, record that limit early and define an alternative, such as an authorized retention arrangement. Do not leave the receiving team to discover missing rights after the original service has ended.
Reconcile at the cutoff
A sample export proves a format can work. It does not prove a final export includes the latest changes. Define the last accepted source update, the export cutoff and how work arriving during transition will be handled.
Keep a count and exception report for the agreed record types. Match IDs, not just totals. Two exports can contain the same number of rows and still omit a critical case. Preserve unresolved items with their owner rather than forcing them into a completed state.
Check that the next team can open the package before closing the old access. Deleting data is a separate step that needs approval. Agree on what happens to backups and copies held by providers. Record any contract exceptions. Do not promise that every copy will vanish as soon as the move ends.
Make exit evidence part of the agreement
Ask for a sample package, a successful interpretation test and a list of known exclusions. Keep the test dated and tied to the relevant version. Revisit it when new data types or providers enter the build.
Core Agentic defines handoff and ownership terms per engagement. Bring the exit checklist. Book a Demo to discuss what a custom design should leave your team able to understand and take forward.
Sources
- SPDX / Linux Foundation: Overview.
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.