Switching software development vendors is not complete when the old vendor sends you a ZIP file of the source code. The transition is complete only when the new team can build, deploy, monitor, back up, restore, and operate the service without relying on the previous vendor's people or personal accounts.
For most live web, mobile, and SaaS products, the safest approach is a two-to-four-week transition in which the outgoing and incoming teams overlap. This guide gives business owners and IT managers a practical 25-point checklist for transferring the system while reducing downtime, security exposure, and unexpected costs.
When should you consider changing development vendors?
A difficult meeting or a delayed feature does not automatically justify replacing a vendor. First confirm that your own priorities, decision makers, acceptance criteria, and change-request process are clear. A transition becomes reasonable when several of the following problems continue after they have been raised:
- The vendor cannot explain the cause of incidents or provide a credible recovery estimate.
- Your company does not control the Git organization, cloud account, domain, or app-store account.
- Production can only be deployed from one developer's laptop or personal account.
- Features repeatedly fail acceptance because requirements and decisions are not recorded.
- Maintenance invoices do not show what was changed, investigated, or monitored.
- Backups exist, but nobody has tested whether they can actually be restored.
- Every staffing change causes critical system knowledge to disappear.
If a security incident or active outage is already in progress, stabilize the service and preserve evidence before beginning a normal vendor transition. Do not make uncontrolled changes to databases, logs, or access records while the cause is still being investigated.
Five principles for a safe vendor transition
- Protect business continuity before assigning blame. Secure access, backups, and operational knowledge even when a commercial dispute exists.
- Your company should own every critical account. Vendors should receive role-based access rather than becoming the permanent owner of your infrastructure.
- Verify outcomes, not document delivery. A runbook is useful only if the incoming team can follow it successfully.
- Create a transition baseline. Preserve the current code revision, infrastructure configuration, database backup, and unresolved-issue list before changes begin.
- Agree on an exit acceptance test. Define the assets, demonstrations, access-removal date, and post-handover question period in writing.
The 25-point software vendor handover checklist
In the tables below, “received” does not simply mean that a file or password was sent. It means that your company can access the asset under a company-controlled account and the incoming team has verified that it works.
1. Contracts, rights, and project scope
#
Item
Acceptance evidence
1
Contract and change orders
The final scope, maintenance obligations, exit terms, and paid deliverables are consolidated.
2
Intellectual property and licenses
Custom code, vendor-owned modules, third-party software, designs, fonts, and content are classified separately.
3
Open work and defects
Every item is marked complete, in progress, deferred, or defective, with an owner and supporting evidence.
4
Third-party agreements
The contracting party, renewal date, usage limits, and cancellation terms are known for every external service.
Do not assume that paying the final invoice automatically transfers every underlying right. A project can contain code written specifically for you, pre-existing vendor frameworks, open-source packages, commercial SDKs, stock media, and customer-provided materials. The contract should state what you own, what you are licensed to use, and what cannot be transferred.
2. Accounts and digital assets
#
Item
Acceptance evidence
5
Source-control organization
Your company is an owner and can access all repositories, branches, tags, releases, issues, and audit history.
6
Cloud organization and billing
Your company controls the root or organization account, billing profile, support plan, and recovery contacts.
7
Domains, DNS, and certificates
The registrar, DNS provider, TLS certificates, renewal settings, and alerts are company-controlled.
8
Mobile app stores
Apple and Google developer accounts, signing keys, certificates, bundle identifiers, and review history are available.
9
External SaaS administrators
Owners are confirmed for analytics, monitoring, email, SMS, payments, maps, AI APIs, and support tools.
A password to an account created with a contractor's personal email address is not durable ownership. Move critical services into a company organization, use group email addresses for recovery, enforce multi-factor authentication, and assign each vendor the minimum role it needs.
3. Source code and reproducible delivery
#
Item
Acceptance evidence
10
Complete source code
Frontend, backend, mobile apps, admin tools, scheduled jobs, database migrations, and infrastructure code are present.
11
Build instructions
Supported runtimes, package versions, commands, private registries, and required environment variables are documented.
12
CI/CD pipelines
Build, test, release, approval, deployment, and rollback steps are visible and usable by the new team.
13
Dependencies and licenses
Commercial SDKs, open-source licenses, expiring keys, unsupported packages, and known vulnerabilities are inventoried.
14
Independent reproduction
The incoming team builds and deploys the current version to a clean non-production environment.
Item 14 is the most important technical acceptance test. A repository may look complete while still depending on an undocumented environment variable, a private package, a manual server change, or a certificate stored on one person's computer. Do not sign off on the transition until the incoming team can reproduce a release independently.
NIST's Secure Software Development Framework provides a common language that software purchasers can use when discussing secure development practices with suppliers. OWASP's Software Component Verification Standard also recommends maintaining a machine-readable inventory of direct and transitive components, their versions, and their origin. These controls make future vulnerability response and vendor replacement substantially easier.
4. Infrastructure and data
#
Item
Acceptance evidence
15
Architecture map
The relationship between servers, databases, storage, caches, queues, CDNs, scheduled jobs, and integrations is accurate.
16
Database and data flows
Schemas, migrations, retention rules, sensitive data, and critical import/export paths are understood.
17
Backups
Schedules, retention, storage locations, encryption, access, and failure alerts are confirmed.
18
Restore test
A recent backup is restored in an isolated environment and the recovered application is validated.
19
Cost baseline
At least three months of cloud and API costs are available, with budgets and unusual-spend alerts configured.
A green “backup completed” message is not proof of recoverability. Record how long restoration takes, the timestamp of the recovered data, any manual steps, and who has authority to perform a production restore. Define acceptable downtime and data loss for each critical service.
5. Security and operations
#
Item
Acceptance evidence
20
Secret inventory and rotation
API keys, database passwords, SSH keys, signing keys, and webhook secrets have owners and rotation dates.
21
Access removal
Every employee, contractor, service account, and vendor role to be removed on the exit date is identified.
22
Security debt
Known vulnerabilities, unsupported versions, temporary exceptions, and incomplete remediation are disclosed.
23
Monitoring and logs
Dashboards, alert routes, log locations, retention, privacy controls, and incident contacts are verified.
24
Operational runbooks
Deployment, rollback, incident response, scheduled operations, customer support, and escalation paths are usable.
25
Signed transition acceptance
Gaps, remediation dates, the question-support period, account-removal date, and authorized signatories are recorded.
Rotate credentials after the new team has proven it can operate the system, not before. Then disable outgoing users, remove unused service accounts, rotate shared secrets, review recent access logs, and retain a record of the final permissions state.
A practical two-to-four-week transition plan
Period
Main activities
Exit criterion
Preparation: 2–3 days
Review contracts, appoint owners, inventory assets, and create baseline backups.
Every deliverable has an owner and due date.
Week 1
Transfer accounts, code, architecture knowledge, runbooks, and open-issue history.
The incoming team has read access to every required system.
Week 2
Build and deploy in a test environment, restore a backup, and rehearse incident response.
The system is reproduced independently and gaps are documented.
Week 3
Operate jointly and let the incoming team deliver a small production change.
The new team executes while the old team only reviews and assists.
Week 4
Transfer operational ownership, rotate secrets, remove old access, and sign acceptance.
The incoming team can operate the service without the old vendor.
A simple marketing website may require less time. A product that processes payments or personal data, includes mobile apps, runs background jobs, or connects to several enterprise systems often needs a longer overlap. Estimate the transition from operational dependencies and outage impact, not from the number of screens.
Common handover failures
- A ZIP file is treated as delivery. The incoming team cannot identify the production revision or reproduce a build.
- Documents are accepted without testing. The architecture diagram and runbook may no longer match the live environment.
- The old team's access is removed too early. The new team is left responsible for incidents before it can deploy or restore the system.
- Passwords are transferred through chat. Secrets remain in message history and their later rotation cannot be verified.
- Incomplete work and defects are mixed together. The parties cannot determine which fixes are included in the existing contract.
- The incoming team audits the system alone. Undocumented business rules and operational exceptions are missed.
What should the new vendor deliver first?
Do not begin with a large fixed-price feature estimate based on incomplete information. A paid one-to-two-week technical discovery is usually safer. Its deliverables should include:
- An as-is architecture map compared with the existing documentation
- Build, deployment, and restore-test results
- Security and operational risks ranked by severity
- Work divided into immediate, 30-day, and longer-term remediation
- A separation between keeping the current product stable and building new features
- A 90-day stabilization and ownership plan
This gives the incoming vendor enough evidence to estimate responsibly and helps the buyer identify costs that may be hidden behind an attractive initial quote.
Final transition decision table
Status
Evidence
Recommended action
Ready
Account ownership, reproducible deployment, restore testing, and operational runbooks are verified.
Complete the overlap period and switch ownership as planned.
Conditionally ready
Some documentation is missing, but the service can be deployed, monitored, and restored.
Record remediation owners and dates in the acceptance document.
Not ready
The company lacks cloud or domain ownership, the current source revision, or a restorable backup.
Secure critical assets before removing the existing team's access.
Incident response
Unauthorized access, data exposure, backup damage, or active service disruption is suspected.
Preserve evidence and involve security and legal specialists.
Frequently asked questions
How long does it take to switch software development vendors?
A well-documented, low-complexity service may move in one or two weeks. For a live web or mobile product, a two-to-four-week overlap is usually safer. Legacy systems, regulated data, payments, and multiple integrations may require a separate discovery and stabilization phase.
What if the previous vendor refuses to provide the source code?
Review the contract's deliverables, intellectual-property language, payment status, and termination clauses before taking technical action. Rights vary according to the agreement and the use of pre-existing vendor technology. Obtain qualified legal advice if ownership or access is disputed.
Is access to the Git repository enough?
No. The code may depend on undocumented environment variables, private packages, database migrations, cloud configuration, certificates, or manual deployment steps. Require the new team to build and deploy the current version in a clean environment.
When should the old vendor's access be removed?
Remove it immediately after the incoming team has passed the agreed operational and recovery tests and final acceptance is signed. On the exit date, disable users, rotate credentials and signing keys, and review access logs.
Can we change vendors without taking the service offline?
Usually, yes. Let the current team continue operating production while the new team audits with read-only access, reproduces the system in a test environment, and gradually takes responsibility for small changes. Prepare a rollback plan for DNS, payments, certificates, and app-signing changes.
How should we evaluate the replacement vendor?
Evaluate its ability to diagnose existing systems, document findings, operate cloud infrastructure, respond to incidents, and manage security—not only its ability to build new features. Ask for a written transition plan, first-30-day deliverables, named roles, and communication cadence.
Need to take control of an existing system?
Nextchain begins vendor transitions by verifying the current code, accounts, deployment process, and recovery readiness before committing to new feature development. If your product needs to move from another provider, review our IT consulting service and delivery process, or request an existing-system transition assessment.
This article provides general project-management information and is not legal advice. Consult a qualified professional for contract termination, intellectual-property, data-protection, or damages disputes.
