Build the exit capability before the engagement starts
Teams often treat handover as administrative work to be completed near contract termination. The real question, however, is not whether the vendor can deliver a ZIP file. It is whether another qualified team can build, deploy, monitor, recover, and modify the system without relying on undocumented knowledge. If the source code lives only in a vendor-owned repository, production requires one engineer's personal access, or cloud resources sit under the vendor's billing account, contractual ownership alone provides little operational control.
Exit terms should therefore be agreed during contracting and architecture design. Clarify ownership of custom code and data, licensing of third-party components, account ownership, delivery formats, transition timelines, and post-termination support. When a vendor uses proprietary platforms or reusable internal modules, identify what can be transferred, what remains licensed, and what would need replacement. A lower initial price may hide substantial switching cost if critical functions depend on components the customer cannot operate independently.
Source code must be reproducible, not merely delivered
Source-code acceptance should include a clean build by the receiving team. Ideally, code is continuously stored in a repository owned or jointly administered by the customer, with commit history, branches, release tags, and deployment configuration intact. A final code dump loses valuable context and can leave the team uncertain about which revision actually runs in production.
The handover should cover application code, infrastructure definitions, database migrations, dependency lockfiles, automation pipelines, and operating instructions. Secrets should never be embedded in the repository, but every required environment variable must be documented with its purpose, source, and rotation procedure. Ask an engineer who did not build the system to follow the documentation. If that engineer still needs extensive verbal guidance from the outgoing vendor, the package is not ready.
- Reproducible build: Record runtime versions, dependencies, build commands, and required external services.
- Traceable release: Map each production release to a commit, tag, database schema, and deployment record.
- Operable delivery: Document deployment, rollback, scheduled jobs, background workers, and failure recovery.
- Maintainable knowledge: Keep architecture diagrams, module boundaries, known limitations, and major technical decisions current.
Data handover requires meaning as well as files
A database backup is not a complete data handover. The receiving team must understand table relationships, field definitions, encodings, time zones, deletion rules, attachment locations, and identifiers shared with ERP, CRM, LINE, or other external systems. Data may also exist in object storage, search indexes, queues, analytics services, and SaaS platforms. Exporting only the primary database may leave the rebuilt application incomplete or internally inconsistent.
Create a data inventory that identifies each source, owner, sensitivity level, retention requirement, export method, and validation method. For a live system, choose deliberately among a maintenance-window migration, incremental synchronization, temporary dual writing, or phased cutover. Zero downtime is not automatically the best target. Consider how quickly records change, how long inconsistency can be tolerated, how difficult rollback will be, and whether the organization can validate two environments safely.
Validation should go beyond file size and row counts. Sample important business objects with their related records, open migrated attachments, verify timestamps and monetary values, test access controls, and reconcile important aggregates. Sensitive transfer packages should be encrypted, access-limited, and logged. The exit procedure should also require confirmation that the outgoing vendor has removed unnecessary copies after the customer accepts the migration, subject to legal retention obligations.
Return account and infrastructure control to the business
Accounts often delay an exit more than code does. Domains, DNS, cloud subscriptions, certificates, repositories, CI/CD, monitoring, email delivery, API providers, mobile stores, and official messaging accounts may all have different administrators. Primary accounts should use company-controlled email addresses, with billing ownership and top-level administration retained internally. Vendors should receive named, least-privilege access instead of becoming the permanent owner of business infrastructure.
Do not hand over access by sharing existing passwords. Inventory human accounts, service accounts, API keys, SSH keys, OAuth applications, webhook secrets, and automation tokens. Create new customer-controlled credentials, update the dependent systems, verify normal operation, and then revoke the old access. Transfer multi-factor authentication, recovery codes, and backup administrators as well; an account is not under control if the business cannot recover it independently.
- Inventory every asset: Record its owner, administrators, purpose, cost center, and dependent systems.
- Add before revoking: Let new administrators prove login and operational access before removing the vendor.
- Rotate credentials: Replace passwords, keys, tokens, and shared secrets rather than assuming they were not retained.
- Preserve evidence: Keep logs of permission changes, exports, deployments, and confirmed deletion activities.
Prove exit readiness through drills and acceptance tests
A detailed checklist does not prove that a system can be transferred. Run small drills during the engagement: have an internal engineer deploy a test environment, restore a backup, or respond to an alert without the original developer's help. These exercises expose stale documentation, missing permissions, manual steps, and dependence on one person while there is still time to correct them.
The final transition can be organized into inventory, transfer, parallel validation, cutover, and a defined observation period. Agree on objective acceptance evidence: the receiving team builds a named release, critical data reconciles, backup restoration succeeds, monitoring works, and customer administrators hold all required privileges. Track unresolved items with owners and deadlines. Where appropriate, link final payment to these verifiable outcomes rather than to the mere delivery of files.
Exit planning is not an expression of distrust; it is basic continuity engineering. If the business lacks an internal technical owner, an independent integration team can test the handover, but the asset inventory, highest-level access, and final decisions should remain with the business.