Software Project Takeover: A 30-Day Provider Change Plan

A software-project takeover is the controlled transfer of technical and operational responsibility for a live product to a new team. It is complete only when the incoming team can build, deploy, observe, roll back and restore the system without the outgoing provider. Receiving a repository is one input, not the acceptance test.

This guide owns the transition question: what to do before, during and after a software provider change. Use the software handover checklist for the full outgoing artifact list, the software agency selection guide for a broader buying decision, and Wavect's software takeover service when you need a team to perform the assessment and inherit the codebase.

Should you change software providers?

Change when the cost and risk of staying are higher than the cost and risk of transition. A missed milestone alone is not enough. Look for a repeated operating pattern: releases cannot be predicted, defects recur without root-cause work, access or documentation remains provider-controlled, material risks are hidden, or commercial incentives no longer match the product.

Do not announce a hard cutover before checking the contract, rights, notice period, payment state, data-processing terms and access reality. If rights or release obligations are disputed, involve qualified counsel. This article is operational guidance, not legal advice.

What should you verify before the incoming provider gets access?

Shortlist the replacement team before exposing production credentials or customer data. In July 2026, NIST finalised a supplier due-diligence guide that frames an ICT assessment around provenance, resilience, foundational cyber practices, supply-chain tiers and ownership or control considerations. That is a useful correction to portfolio-only selection: investigate how the provider operates, not just what it has shipped. See NIST SP 1326, Cybersecurity Supply Chain Risk Management: Due Diligence Assessment.

• Identity and accountability. Which legal entity signs, who leads the takeover, who can access production, and who owns an incident decision?
• Brownfield evidence. Ask for an anonymised takeover report, risk register or first-30-day plan, not only greenfield screenshots.
• Delivery boundary. Confirm whether the same people who assess the system will stabilise and extend it.
• Security practice. Ask how access is approved, logged, reviewed and revoked; how secrets are handled; and how findings are escalated.
• Commercial independence. Make the assessment useful even if you do not award the follow-on work.

Grant named, time-bound, least-privilege access through client-owned identities. Start with read-only access where possible. Never email a password dump. Agree how evidence may be stored, who may see it, and when the provider must delete it.

The 30-day software takeover plan

Thirty days is a planning frame, not a universal promise. A small web product may move faster. A regulated platform, mobile estate, industrial system or product with 24/7 obligations may need parallel teams and a longer overlap. The sequence matters more than the calendar.

Before day 1: write the transition charter

Name one accountable client owner, one outgoing-provider owner and one incoming-provider owner. Define the systems in scope, emergency channel, change authority, meeting rhythm, evidence repository, overlap window and independence test. Separate ordinary exit from emergency exit. The current UK Mid-Tier Contract guidance treats exit management as something prepared during the relationship, including a maintained virtual library, exit plan, re-competition help and termination assistance. Your contract may be smaller, but the operating principle scales down. See the UK government guidance on exit management.

Keep the outgoing provider in a clear paid transition role where possible. A hostile handover produces worse evidence and higher business risk. Pay for specific deliverables and sessions, record unresolved questions, and avoid using the new provider's findings to stage a public blame exercise.

Days 1 to 5: secure control without causing an outage

1. Inventory before rotating. Map repository hosts, cloud, DNS, certificates, domains, stores, databases, queues, email, analytics, observability, support tools, package registries and commercial licences.
2. Confirm ownership. Record the legal account owner, billing owner, admins, recovery contacts and transfer route for every asset.
3. Preserve evidence. Take authorised backups, exports and configuration snapshots. Keep audit logs and Git history intact.
4. Rotate in dependency order. Replace personal and shared credentials only after you know what uses them. Keep rollback access under client control.
5. Baseline production. Capture traffic, error rate, latency, queue depth, backup status, open incidents, support volume and known release state.

A change freeze should be selective. Freeze risky roadmap work, schema changes and infrastructure redesign. Keep an emergency patch lane open with named approval. A blanket freeze with no patch route can preserve a known vulnerability just as effectively as it preserves stability.

Days 6 to 10: build a system map and risk register

The incoming team should trace three to five business-critical journeys from user action to data and external effects. Examples include sign-in, purchase, payout, document creation, device command or scheduled billing. For each journey, record entry point, services, data stores, third parties, permissions, monitoring, failure modes and manual recovery.

Classify findings instead of producing one long technical-debt list:

Do not let code aesthetics outrank operating risk. An unfashionable framework with a reproducible build and tested recovery is usually safer on day 10 than a rewrite plan with no production evidence.

Days 11 to 20: prove the operational paths

Run witnessed tests in the safest representative environment available. The incoming team should demonstrate a fresh setup, repeatable build, deployment, smoke test, rollback, backup verification, restore rehearsal and incident escalation. Production changes require the normal risk and approval process.

For cloud and SaaS dependencies, confirm export paths and switching obligations rather than assuming “the client owns the data” is enough. The EU Data Act has applied since 12 September 2025 and sets minimum requirements for switching between data-processing services, including cloud and edge services. The Commission explains that providers must remove switching obstacles and, for PaaS and SaaS, provide open interfaces and at least commonly used, machine-readable exports. Scope and exceptions matter, so verify the actual service and contract. See the European Commission's Data Act explainer.

If a provider processes personal data for you, the exit must also match the data-processing agreement. GDPR Article 28 requires the processor, at the controller's choice, to delete or return personal data after the service ends unless law requires storage. That makes data inventory, export, deletion evidence and revoked subprocessors part of the transition, not administrative cleanup. Check the official GDPR text on EUR-Lex.

For products with digital elements in CRA scope, identify who will own the cybersecurity risk assessment, technical documentation, support-period commitments and vulnerability handling after the provider change. The obligations depend on the product and economic-operator role. The European Commission's Cyber Resilience Act summary explains the manufacturer and vulnerability-handling duties and the main application dates.

Days 21 to 30: ship one bounded change

A takeover is not proven by a slide deck. Choose a low-risk change that touches the real path from issue to production: a contained defect, observability improvement, dependency patch or small workflow correction. Require normal review, automated checks, deployment evidence and post-release observation.

Use an explicit security baseline for the inherited software. NIST's Secure Software Development Framework provides high-level practices that can be integrated into different development lifecycles. For web applications, OWASP ASVS 5.0 provides testable security requirements and is explicitly designed for use in procurement as well as verification. Select requirements based on risk; do not claim blanket compliance because a scanner ran once.

The day-30 decision should be one of four paths: continue with cautious maintenance, stabilise before adding features, modernise selected boundaries, or replace the system when evidence shows replacement has the better total cost and risk. “Rewrite everything” is a conclusion, not a starting method.

What can go wrong during a software-provider change?

How to choose the new software provider

Use the same evidence pack and scenario for every finalist. Give them a redacted system map, constraints, one critical journey and the desired takeover outcome. Ask for risks, unknowns, access needs, first two weeks, team roles, decision gates and commercial assumptions. Do not reward the longest generic proposal.

Wavect's practical scoring model totals 100 points:

Set the decision rule before receiving bids. Our default is at least 70 points with no hard stop. Hard stops are: no named accountable lead, no safe production-access model, no written assessment deliverable, unclear rights to the output, or a fixed rewrite promise before inspection. Adjust weights for your product, but do not let a polished sales call compensate for a failed control.

Where Wavect fits, and where it does not

Wavect is a good candidate when you have a live or stalled custom product, can provide legitimate stakeholder and system access, and want an assessment before committing to maintenance or further development. Our commercial preference is simple: understand the system, document the risks, stabilise what matters, then quote follow-on work from evidence. You keep the written assessment.

We are not the right choice for a blind rewrite, anonymous staff augmentation, a generic 24/7 IT helpdesk, or a takeover where nobody can authorise access to the system. Sometimes the correct recommendation is to keep the current team and fix governance. Because this is Wavect's article, treat the scorecard as a disclosed point of view and ask every shortlisted provider, including us, for the same evidence.

A relevant example is the FTW Ventures case study, which shows how we communicate our contribution and delivery evidence. For an independent quality baseline before or during transition, review our software quality assurance service.

Software takeover FAQ