Your platform is live, but the relationship with your current IT team has broken down. You're wondering whether another company can take over the existing system, or whether you're locked into rebuilding from scratch. The answer is: it depends. Not on the quality of the code, but on how thoroughly the outgoing team documented their work and structured deliverables. A successful handover starts long before transition day, back when the first contract was signed.
This article presents a proven transfer plan, applicable to any business platform. It describes the steps that allow an incoming team to take over a project without rewriting everything, and it identifies what makes a handover impossible, meaning what you should have required from the start.
The signals that justify changing teams, and those that don't
Changing vendors costs real money and freezes your platform for three to six months. You need to be certain the problem isn't actually unclear internal communication or shifting objectives.
Good reasons to change:
- The team stopped delivering, despite multiple formal warnings and additional resources allocated.
- Vendor-side turnover hits 50 % annually, each new developer asks questions their predecessors already answered.
- Infrastructure is owned by the vendor, under accounts they refuse to transfer or document.
- Maintenance costs exceed original estimates by 40 %, with no scope increase or technical justification.
- Security audits reveal critical vulnerabilities that the vendor fixes half the time, with six-week delays.
Bad reasons to change:
- A single major error, even costly, if it was addressed quickly and preventive actions were implemented.
- A disagreement over feature priorities, when no formalized backlog has been shared between client and team.
- A language or framework perceived as "old," when the platform is stable, documented and handles load growth. Technical debt is measured in business risk, not Hacker News trends.
- Deadlines that slip because requirements change every week. Before blaming delays, measure the volatility of your own requests.
The rule: if the problem can be fixed by rewriting a contract or clarifying expectations, keep the team. If the problem persists after three documented improvement attempts, plan the handover.
The handover audit: what an incoming team must be able to read in ten days
A handover audit is not a code audit. It doesn't evaluate technical quality, but answers one question: can this platform be taken over by another team, without rebuilding everything?
The incoming team analyzes the following documents, which the outgoing vendor must provide within ten business days. If a document is missing or remains unclear after two exchanges, the handover is compromised.
-
Architecture diagram: schema of components (APIs, databases, workers, third-party integrations), with their relationships and data flows. Accepted in Draw.io, Miro, Figma or Lucidchart format, with PDF export capability. A PowerPoint screenshot is not an exploitable diagram.
-
Environment inventory: list of all environments (dev, staging, production), their URL, infrastructure (dedicated server, cloud, PaaS), application version and deployment procedure. If production runs on three different servers without justification, that's a signal.
-
Dependencies manifest: file generated by package manager (package.json, requirements.txt, composer.lock, pom.xml), with exact versions. An up-to-date manifest guarantees reproducible rebuilds. A manifest eight months old means the team deploys without knowing its dependencies.
-
API documentation: endpoints, HTTP methods, parameters, return codes and request examples. Postman collection, Swagger or OpenAPI are accepted. A well-commented integration test suite can compensate for missing formal docs, if it covers 80 % of routes.
-
Database schema: ERD diagram of main tables, or SQL export with constraints and indexes. The new team must understand the data model in one hour, without calling the outgoing team.
-
Secrets inventory: list of secrets used (third-party API keys, OAuth tokens, SSL certificates), with their location (.env file, cloud secret manager, system environment variables). You're not asked to provide the secrets themselves at this stage, only their inventory.
-
Backup and restore procedure: backup frequency, file location, retention duration and tested restoration procedure. A backup that's never been restored isn't a backup.
The audit produces a verdict in three levels:
- Immediate handover: all documents are current, incoming team can start recovery within the week.
- Conditional handover: two or three documents are missing or obsolete. Outgoing team must complete them before transfer, estimated delay between two and four weeks.
- Impossible handover: more than half the documents are absent or unusable. Rebuilding costs less than taking over.
The exit inventory: repositories, secrets, infrastructure, accounts, third-party contracts
When the handover is validated, the outgoing team establishes a comprehensive inventory of everything to be transferred. This contractual document engages their liability: any element omitted and discovered later in the year justifies a financial penalty, to be provided for in the contract termination amendment.
Code repositories
List of Git repositories, with their URL, main branch and current access rights. If repositories are hosted on a developer's personal account (GitHub, GitLab, Bitbucket), they must be transferred to the client's organization before the notice period ends. A fork is not sufficient, the original repository can disappear.
Secrets and credentials
Secure file (1Password, Bitwarden, encrypted vault) containing:
- API keys for third-party services (payment, email, SMS, analytics, monitoring).
- OAuth tokens and refresh tokens for SaaS integrations.
- SSL/TLS certificates and their private keys.
- Database administrator passwords.
- Root or administrator access to production servers.
This inventory must be delivered to the client, not to the incoming team. The client then decides what they share and when.
Infrastructure and cloud accounts
List of all cloud accounts (AWS, Azure, GCP, OVH, Scaleway) used for the platform, with the level of access held by the vendor. The inventory specifies:
- Active resources (servers, managed databases, CDN, object storage).
- Monthly costs observed over the last three months.
- Configured monitoring alerts and their destination (email, Slack, PagerDuty).
Account transfer happens in two steps: add client-side administrator as owner, then revoke outgoing vendor access after handover validation.
Third-party contracts and subscriptions
Modern B2B platforms rely on five to fifteen SaaS services. The inventory lists:
- The service (name, URL, usage).
- Contract type (free, monthly, annual, usage-based).
- Commercial contact (email, phone) if the service was negotiated directly.
- Renewal date and amount.
The goal is to prevent a critical service from expiring without anyone noticing, which cuts off the platform on the day of the missed renewal.
The handover period between outgoing and incoming teams
The handover is the period when both teams work together, under client direction. Its duration varies from two to six weeks depending on platform complexity. Less than two weeks, the incoming team doesn't have time to ask all their questions. More than two months, the budget explodes and responsibilities blur.
Week 1: Installation and first exploration
The incoming team clones repositories, installs local environment and deploys a staging environment mirroring production. They verify the build procedure works and automated tests pass. If blockers appear (missing dependencies, poorly documented secrets, failing tests), the outgoing team fixes them within 48 hours.
Week 2: Knowledge transfer session
Daily one-hour meeting between incoming team and outgoing expert, on specific modules:
- Day 1: overall architecture, data flows between components.
- Day 2: authentication, authorization, session management.
- Day 3: third-party integrations (payment, billing, notifications).
- Day 4: scheduled tasks (cron, workers, async jobs).
- Day 5: monitoring, logging, incident management.
Each session produces a written record validated by both parties. These documents replace missing documentation.
Week 3: Supervised deployment
The incoming team performs their first production deployment, under outgoing team supervision. The deployment concerns a minor fix or configuration adjustment, not a new feature. The goal is to test the deployment procedure and verify access has been properly transferred.
Week 4 and beyond: Degraded support
The outgoing team remains available by email to answer specific questions, with 48-hour response commitment. They no longer intervene directly on the platform, except for critical incidents blocking production (criterion: service unavailable for more than two hours).
The handover ends when the incoming team has deployed to production at least three times without help, and incident response times return below contractual SLAs.
What makes a handover impossible, and therefore what you should have required from the start
Certain practices transform a platform into a non-transferable asset. Here are six situations that make a handover technically or economically impossible.
1. Infrastructure owned by vendor, under their own accounts
If the platform runs on the vendor's AWS or Azure account, with billing rebilled to the client, transfer requires complete resource migration. Estimated cost: between 15,000 and 60,000 EUR depending on number of services used, with two to five days downtime. The clause to require from the start: "All cloud accounts are created in the client's name, vendor receives revocable delegated access."
2. Undocumented proprietary code with dependencies on vendor's internal libraries
If the application depends on private packages hosted on the vendor's internal registry, without redistribution license, the incoming team cannot rebuild the application. They must either rewrite affected modules or negotiate a license with the vendor, which can take six months. The clause to require: "All software dependencies must be open source or available via public registry. Internal libraries are delivered in source to the client with modification rights."
3. Database without documented schema and without integrity constraints
A database with 80 tables without foreign keys, without comments and without diagram is a black box. The incoming team spends three months tracing relationships between entities before being able to fix the slightest bug. The clause to require: "Database schema is delivered as ERD diagram updated quarterly, with documentation of critical columns."
4. No automated tests
Without tests, impossible to verify that a fix doesn't break another feature. The incoming team must manually test each scenario before each deployment, which triples delays and costs. The clause to require: "Unit and integration test coverage at 60 % minimum for business modules, measured quarterly."
5. Manual deployment without written procedure
If deployment is done "by hand" via FTP or copying files to the server, without script or CI/CD pipeline, each new deployment is a risk. The incoming team must rebuild the procedure by trial and error. The clause to require: "Automated deployment via CI/CD pipeline, with one-click rollback."
6. Secrets and credentials hardcoded in the code
API keys, OAuth tokens and passwords in clear text in source files are a leak vector and a nightmare in case of handover. The incoming team must track each occurrence in Git history and regenerate all keys. The clause to require: "All secrets are stored in environment variables or secret manager, never in source code or commits."
These six criteria constitute a project startup checklist. Refusing a vendor who won't accept them costs less than suffering an impossible handover three years later.
The real cost of changing vendors, and how to reduce it in advance
A platform transfer costs between 20,000 and 120,000 EUR depending on complexity, excluding redesign. This budget breaks down as follows:
- Handover audit: 3,000 to 8,000 EUR (10 to 20 days of senior technical expertise).
- Handover and knowledge transfer: 8,000 to 25,000 EUR (4 to 8 weeks at two developers on incoming side, one expert on outgoing side).
- Missing documentation to reconstitute: 5,000 to 30,000 EUR (if less than 40 % of docs exist).
- Infrastructure migration: 4,000 to 35,000 EUR (if cloud accounts in vendor's name).
- Rewrite of undocumented critical modules: 0 to 50,000 EUR (depends on code state and test coverage).
Add to this the opportunity cost: for three to six months, no new features are delivered, delaying business objectives.
Two levers reduce cost by 40 to 60 %:
Lever 1: Mandatory documentation clauses in initial contract
Impose quarterly documentation review, with 2 % monthly penalty for non-compliance. Expected deliverables: architecture diagram, API docs, database schema, deployment procedure. Doc maintenance cost: 2 to 4 days per quarter, under 3,000 EUR per year. Savings in case of handover: 15,000 to 40,000 EUR.
Lever 2: Cloud accounts and Git repositories in client's name from the start
The vendor receives delegated access, revocable at any time. In case of handover, just revoke access, no migration. Setup cost: half a day administrative. Savings in case of handover: 4,000 to 35,000 EUR.
These two measures must be negotiated before signing the first contract. Adding them mid-project is legally difficult and financially expensive.
Taking over without rewriting: the three-month no-new-features rule
The temptation after a handover is to immediately fix everything that looks wrong. This is a strategic error. Each modification introduces regression risk, and the incoming team doesn't yet have the business knowledge to prioritize.
The three-month rule works like this:
Month 1: Critical bug fixes only. Criterion: a bug is critical if it blocks a business process or exposes sensitive data. Everything else waits. Goal: stabilize the platform and understand real flows.
Month 2: Localized refactoring, one module at a time. The team identifies the three riskiest code areas (high cyclomatic complexity, no tests, obsolete dependencies) and refactors them one by one. Each refactoring gets code review and staging validation before production.
Month 3: First minor features. Add a new option in a form, CSV export of an existing table, notification email adjustment. Nothing touching business core. Goal: validate the team masters the complete cycle (development, tests, deployment, monitoring).
From month 4, the team can deliver business features at normal pace. Statistics show that a team respecting this rule reduces production incidents by 60 % compared to a team delivering from week 2.
Common mistake: promising management visible improvement within 30 days. Result: a rushed feature, two undetected regressions and a loss of trust lasting six months. Better three months of stability, then a solid roadmap.
FAQ
Can a vendor refuse to provide the exit inventory?
Legally no, if the initial contract includes a reversibility or knowledge transfer clause. In practice, a disgruntled vendor can make the process difficult by providing incomplete or obsolete documents. This is why the clause must specify an enforceable format (for example, "architecture diagram in exportable format, database as ERD diagram, deployment procedure testable by third-party team"). The presence of a financial penalty for non-compliance (for example, withholding 10 % of final invoice) encourages seriousness.
How long should the outgoing team remain available after handover?
Two months of degraded support, with 48-hour response, is average duration. Beyond this period, the incoming team must be autonomous. Provide for a spot support clause after this period (half-day billing) for exceptional cases, like discovering an undocumented critical module.
Can you take over a platform without access to source code?
No. A platform delivered only in binary form or hosted on inaccessible infrastructure is a blocked asset. The client owns a usage license, not technical control. In this case, the only option is to rebuild the platform with a new vendor, specifying from the start source code ownership and access to Git repositories.
What indicators measure handover success?
Three KPIs: incident response time (must return below SLA within two months), number of successful deployments without assistance (at least 5 out of 5 after three months), and regression rate (bugs introduced by fixes, must stay under 5 %). If these three indicators are green, the handover is successful.
Should you change tech stack during a handover?
Only if the current stack presents proven risk: end-of-life framework without official migration, dependency on inaccessible proprietary technology, or incompatibility with skills available on local market. Changing stack to follow a trend costs between 80,000 and 300,000 EUR and extends the project by six to twelve months. Better to modernize gradually once the handover is stabilized.
To explore best practices in custom development and secure your IT projects, consult our guide on digital audit in Morocco. Our teams also support companies with digital consulting to structure technical partnerships from the start.