---
title: "Software Project Takeover: 30-Day Provider Change Plan"
canonical: https://wavect.io/blog/software-project-takeover-provider-change/
language: en
description: "Changing software providers? Use this 30-day takeover plan, risk register and provider scorecard to protect access, releases, data and continuity."
image: "https://wavect.io/img/blog/headers/header_software-project-takeover-provider-change.png"
---

[**Back**](/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/)

[Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt

14 min read · 13 Aug 2026 Last reviewed August 13, 2026

[**Next**](/blog/software-agency-proposal-teardown/)

# Software Project Takeover: A 30-Day Provider Change Plan

TL;DR

A software-project takeover succeeds when the incoming team can build, deploy, observe, roll back and restore the product without the outgoing provider. Spend days 1 to 5 securing ownership and baselining production, days 6 to 10 mapping architecture and business-critical journeys, days 11 to 20 proving release and recovery paths, and days 21 to 30 shipping one bounded low-risk change. Choose the new provider on brownfield evidence, operational control, security, transition method and commercial clarity. Reject anyone who promises a rewrite or fixed delivery plan before inspecting the system.

**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](/software-development-guide/software-handover-checklist/) for the full outgoing artifact list, the [software agency selection guide](/software-development-guide/how-to-choose-a-software-agency/) for a broader buying decision, and Wavect's [software takeover service](/services/software-takeover/) 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.

| Situation | Best first move | Why |
| --- | --- | --- |
| The team is capable, but priorities and ownership are unclear | Reset governance and decision rights | A new provider would inherit the same management problem. |
| Delivery is slow, but the system is stable and transparent | Run a bounded independent assessment | You need evidence before paying the transition cost. |
| Code, cloud or data remain in provider-owned accounts | Prepare an exit and control-recovery plan | Operational dependency is already a business risk. |
| Security, data integrity or production continuity is at risk | Start controlled emergency triage | Contain the risk before negotiating the long-term roadmap. |

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](https://csrc.nist.gov/pubs/sp/1326/final).

- **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.

| Phase | Primary objective | Exit evidence |
| --- | --- | --- |
| Before day 1 | Agree authority, scope, communication and exit obligations | Signed transition charter, owner map and access protocol |
| Days 1 to 5 | Regain control and baseline production | Asset register, access matrix, current health snapshot |
| Days 6 to 10 | Map architecture, data and business-critical journeys | System map, risk register, verified local build |
| Days 11 to 20 | Prove deployment, rollback, restore and incident response | Witnessed operational tests and prioritised stabilisation plan |
| Days 21 to 30 | Ship one bounded change and decide the roadmap | Production change, post-release review and 90-day plan |

### 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](https://www.gov.uk/government/publications/guidance-on-the-mid-tier-contract/the-mid-tier-contract-guidance-for-buyers-html).

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:

| Class | Meaning | Example action |
| --- | --- | --- |
| P0: active exposure | Current security, data-loss or severe continuity risk | Contain now, preserve evidence, notify the responsible owner |
| P1: release blocker | The team cannot change or recover the system safely | Restore build, deploy, rollback, backup or observability path |
| P2: delivery drag | Known friction slows every change | Fix selectively where the next roadmap work touches it |
| P3: improvement | Useful, but not required for safe ownership | Place in the normal roadmap with an explicit business case |

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](https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained).

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](https://eur-lex.europa.eu/eli/reg/2016/679/oj).

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](https://digital-strategy.ec.europa.eu/en/policies/cra-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](https://csrc.nist.gov/pubs/sp/800/218/final) provides high-level practices that can be integrated into different development lifecycles. For web applications, [OWASP ASVS 5.0](https://owasp.org/www-project-application-security-verification-standard/) 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?

| Failure mode | Early signal | Control |
| --- | --- | --- |
| Credentials are rotated in the wrong order | Unknown consumers and shared service accounts | Map dependencies, rotate in waves, keep client-controlled rollback |
| The handover becomes a video archive | Many calls, no runnable runbooks or decisions | Turn every session into an owned artifact and verified task |
| The new provider sells a rewrite before diagnosis | Estimate and architecture appear before access | Buy a bounded assessment with explicit reuse-versus-replace criteria |
| The outgoing team leaves too early | No overlap for a deploy or incident walkthrough | Retain targeted transition assistance until independence gates pass |
| Feature pressure overrides stabilisation | Roadmap dates are fixed before the risk register exists | Separate takeover budget, stabilisation budget and roadmap budget |
| Licences or accounts cannot transfer | Core services sit under provider contracts or personal identities | Inventory contracts, export paths and replacement cost before cutover |
| A serious finding is handled informally | Security issues stay in chat without an owner or severity | Use a confidential escalation path, evidence controls and decision log |
| Success means “the repo was delivered” | No deploy, rollback or restore test | Make operational independence the acceptance criterion |

## 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:

| Criterion | Weight | Evidence to request |
| --- | --- | --- |
| Brownfield and takeover evidence | 20 | Anonymised assessment, inherited-system case or risk register |
| Transition method | 20 | First-30-day plan, independence gates and outgoing-team protocol |
| Release and recovery competence | 15 | How the team proves build, deploy, rollback, backup and restore |
| Security and data handling | 15 | Access model, escalation route, evidence handling and deletion process |
| Commercial and contract clarity | 10 | Assessment scope, assumptions, exclusions, IP, exit and follow-on model |
| Product and roadmap judgment | 10 | Examples of keeping, changing or rejecting work for business reasons |
| Communication and continuity | 10 | Named lead, actual delivery team, absence cover and decision cadence |

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](/case-studies/ftw-ventures/), 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](/services/software-quality-assurance/).

## Software takeover FAQ

## Frequently Asked Questions

### How long does a software-project takeover take?

Use 30 days as an initial control and assessment window, not a universal completion promise. Small products may reach independence sooner. Regulated, distributed or poorly documented systems often need longer overlap and staged cutovers. Define completion through build, deploy, rollback, restore and incident-response evidence.

### Can a new provider take over software with no documentation?

Often yes, if the client can lawfully provide code, infrastructure and stakeholder access. Expect more discovery cost and uncertainty. The new team must reconstruct architecture and operating knowledge from repositories, configuration, telemetry, tickets and interviews, then write the missing runbooks as it verifies them.

### Should the new provider rewrite the software?

Not before assessment. First compare continued maintenance, targeted stabilisation, boundary-by-boundary modernisation and replacement. A rewrite is justified only when evidence shows that the total cost and risk of preserving the current system are worse than replacement.

### What if the outgoing provider refuses to cooperate?

Preserve contracts, invoices, correspondence and current access. Identify what the client already owns and controls, avoid unauthorised access, and have qualified counsel assess rights and remedies. Technically, prioritise backups, account recovery, service continuity and a documented unknowns register.

### What should a takeover assessment deliver?

At minimum: asset and access inventory, system and data-flow map, build and deployment status, operational and security risk register, dependency and licence concerns, documentation gaps, stabilisation priorities, reuse-versus-replace options, team needs and a costed next-step proposal with assumptions.

### How do I compare software takeover providers?

Give finalists the same redacted scenario and score evidence, not confidence. Weight brownfield experience, transition method, release and recovery ability, security and data handling, commercial clarity, product judgment and team continuity. Require a written assessment that remains useful if you choose someone else for implementation.

## Final thoughts

A safe software-provider change transfers capability, not just files. The incoming team must be able to explain the system, operate it under pressure and make a small change through the real release path. That is why the first month should move from control, to understanding, to operational proof, and only then to roadmap delivery.

Choose the provider that is most precise about unknowns, evidence and decision gates. The best takeover pitch is rarely the biggest promise. It is the clearest method for reducing dependency while keeping the product and business running.

## You may also like..

[**Software Agency Proposal Teardown** After choosing a takeover provider, inspect the scope, acceptance, IP, security and exit clauses before signing.](/blog/software-agency-proposal-teardown/) [**Wavect vs a generalist development agency** Compare founder-led product judgment, senior continuity and clean handover with capacity-first delivery.](/compare/wavect-vs-dev-agencies/)

Software buying and funding

## Continue through this cluster

Agency selection, contracts, pricing, grants and the commercial mechanics of delivery.

[Start with the cornerstone**Software Agency Proposal Teardown: 12 Clauses That Change Price, Scope and Ownership**](/blog/software-agency-proposal-teardown/)

- [What "Dienstleister" Commits Your Vendor To](/blog/werkvertrag-vs-dienstvertrag-software-austria/)
- [Software Agencies in Tyrol Compared 2026](/blog/software-agencies-tyrol-comparison-2026/)
- [Software Agency Proposal Teardown: 12 Clauses That Change Price, Scope and Ownership](/blog/software-agency-proposal-teardown/)
- [AI Consulting in Austria 2026: An Honest Guide for SMEs](/blog/ai-consulting-austria-2026/)
- [AI Funding in Austria 2026: aws, FFG, Premium, KMU.DIGITAL](/blog/ai-funding-austria-2026/)

Inbox, without the noise

## Follow the work that matters to you

Get a short email when we publish something new. Follow the whole blog or only the problems you care about.

[**Back**](/blog/overview/)

[![Kevin Riedl](/img/team/kevin.webp)](/team/kevin-riedl/)

[Kevin Riedl](/team/kevin-riedl/) https://linkedin.com/in/wsdt

14 min read · 13 Aug 2026 Last reviewed August 13, 2026

[**Next**](/blog/software-agency-proposal-teardown/)

New posts by email ×

×

Get new posts by email

A short email when we publish. Free, no tracking.

## Structured Data

```json
{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@id": "https://wavect.io/#organization",
      "@type": [
        "Organization",
        "ProfessionalService",
        "LocalBusiness"
      ],
      "employee": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "founder": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "legalRepresentative": [
        {
          "@id": "https://wavect.io/team/kevin-riedl/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Kevin Riedl",
          "url": "https://wavect.io/team/kevin-riedl/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        },
        {
          "@id": "https://wavect.io/team/christof-jori/#person",
          "@type": "Person",
          "jobTitle": "Managing Director",
          "name": "Christof Jori",
          "url": "https://wavect.io/team/christof-jori/",
          "worksFor": {
            "@id": "https://wavect.io/#organization",
            "@type": [
              "Organization",
              "ProfessionalService",
              "LocalBusiness"
            ]
          }
        }
      ],
      "name": "Wavect GmbH",
      "subjectOf": {
        "@id": "https://wavect.io/verified-claims.json#dataset",
        "@type": "Dataset",
        "creator": {
          "@id": "https://wavect.io/#organization",
          "@type": [
            "Organization",
            "ProfessionalService",
            "LocalBusiness"
          ]
        },
        "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.",
        "inLanguage": "en",
        "isAccessibleForFree": true,
        "license": "https://creativecommons.org/licenses/by/4.0/",
        "name": "Wavect verified publication claims",
        "url": "https://wavect.io/verified-claims.json"
      },
      "url": "https://wavect.io/"
    },
    {
      "@id": "https://wavect.io/team/kevin-riedl/#person",
      "@type": "Person",
      "jobTitle": "Managing Director",
      "name": "Kevin Riedl",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q139796365",
        "https://www.linkedin.com/in/wsdt",
        "https://github.com/wsdt"
      ],
      "url": "https://wavect.io/team/kevin-riedl/",
      "worksFor": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      }
    },
    {
      "@id": "https://wavect.io/team/christof-jori/#person",
      "@type": "Person",
      "jobTitle": "Managing Director",
      "name": "Christof Jori",
      "sameAs": [
        "https://www.wikidata.org/wiki/Q139796367",
        "https://www.linkedin.com/in/jocr77/",
        "https://github.com/jo-chris"
      ],
      "url": "https://wavect.io/team/christof-jori/",
      "worksFor": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      }
    },
    {
      "@id": "https://wavect.io/#website",
      "@type": "WebSite",
      "inLanguage": [
        "en",
        "de",
        "es",
        "zh"
      ],
      "name": "Wavect",
      "potentialAction": {
        "@type": "SearchAction",
        "query-input": "required name=search_term_string",
        "target": {
          "@type": "EntryPoint",
          "urlTemplate": "https://wavect.io/search/?q={search_term_string}"
        }
      },
      "publisher": {
        "@id": "https://wavect.io/#organization",
        "@type": [
          "Organization",
          "ProfessionalService",
          "LocalBusiness"
        ]
      },
      "url": "https://wavect.io/"
    },
    {
      "@id": "https://wavect.io/blog/software-project-takeover-provider-change/#webpage",
      "@type": "WebPage",
      "dateModified": "2026-08-13",
      "inLanguage": "en",
      "isPartOf": {
        "@id": "https://wavect.io/#website",
        "@type": "WebSite"
      },
      "lastReviewed": "2026-08-13",
      "url": "https://wavect.io/blog/software-project-takeover-provider-change/"
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "abstract": "A software-project takeover succeeds when the incoming team can build, deploy, observe, roll back and restore the product without the outgoing provider. Spend days 1 to 5 securing ownership and baselining production, days 6 to 10 mapping architecture and business-critical journeys, days 11 to 20 proving release and recovery paths, and days 21 to 30 shipping one bounded low-risk change. Choose the new provider on brownfield evidence, operational control, security, transition method and commercial clarity. Reject anyone who promises a rewrite or fixed delivery plan before inspecting the system.",
  "articleBody": " Blog overview/Business and regulation/Software buying and funding Software Project Takeover: A 30-Day Provider Change Plan TL;DR A software-project takeover succeeds when the incoming team can build, deploy, observe, roll back and restore the product without the outgoing provider. Spend days 1 to 5 securing ownership and baselining production, days 6 to 10 mapping architecture and business-critical journeys, days 11 to 20 proving release and recovery paths, and days 21 to 30 shipping one bounded low-risk change. Choose the new provider on brownfield evidence, operational control, security, transition method and commercial clarity. Reject anyone who promises a rewrite or fixed delivery plan before inspecting the system. 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. SituationBest first moveWhy The team is capable, but priorities and ownership are unclearReset governance and decision rightsA new provider would inherit the same management problem. Delivery is slow, but the system is stable and transparentRun a bounded independent assessmentYou need evidence before paying the transition cost. Code, cloud or data remain in provider-owned accountsPrepare an exit and control-recovery planOperational dependency is already a business risk. Security, data integrity or production continuity is at riskStart controlled emergency triageContain the risk before negotiating the long-term roadmap. 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. PhasePrimary objectiveExit evidence Before day 1Agree authority, scope, communication and exit obligationsSigned transition charter, owner map and access protocol Days 1 to 5Regain control and baseline productionAsset register, access matrix, current health snapshot Days 6 to 10Map architecture, data and business-critical journeysSystem map, risk register, verified local build Days 11 to 20Prove deployment, rollback, restore and incident responseWitnessed operational tests and prioritised stabilisation plan Days 21 to 30Ship one bounded",
  "articleSection": "Engineering",
  "author": {
    "@id": "https://wavect.io/team/kevin-riedl/#person",
    "@type": "Person",
    "name": "Kevin Riedl",
    "sameAs": [
      "https://www.wikidata.org/wiki/Q139796365",
      "https://www.linkedin.com/in/wsdt",
      "https://github.com/wsdt"
    ],
    "url": "https://wavect.io/team/kevin-riedl/"
  },
  "citation": [
    {
      "@type": "WebPage",
      "name": "NIST SP 1326, Cybersecurity Supply Chain Risk Management: Due Diligence Assessment",
      "url": "https://csrc.nist.gov/pubs/sp/1326/final"
    },
    {
      "@type": "WebPage",
      "name": "UK government guidance on exit management",
      "url": "https://www.gov.uk/government/publications/guidance-on-the-mid-tier-contract/the-mid-tier-contract-guidance-for-buyers-html"
    },
    {
      "@type": "WebPage",
      "name": "European Commission's Data Act explainer",
      "url": "https://digital-strategy.ec.europa.eu/en/factpages/data-act-explained"
    },
    {
      "@type": "WebPage",
      "name": "official GDPR text on EUR-Lex",
      "url": "https://eur-lex.europa.eu/eli/reg/2016/679/oj"
    },
    {
      "@type": "WebPage",
      "name": "European Commission's Cyber Resilience Act summary",
      "url": "https://digital-strategy.ec.europa.eu/en/policies/cra-summary"
    },
    {
      "@type": "WebPage",
      "name": "NIST's Secure Software Development Framework",
      "url": "https://csrc.nist.gov/pubs/sp/800/218/final"
    },
    {
      "@type": "WebPage",
      "name": "OWASP ASVS 5.0",
      "url": "https://owasp.org/www-project-application-security-verification-standard/"
    }
  ],
  "dateModified": "2026-08-13",
  "datePublished": "2026-08-13",
  "description": "A software-project takeover succeeds when the incoming team can build, deploy, observe, roll back and restore the product without the outgoing provider. Spend days 1 to 5 securing ownership and baselining production, days 6 to 10 mapping architecture and business-critical journeys, days 11 to 20 proving release and recovery paths, and days 21 to 30 shipping one bounded low-risk change. Choose the new provider on brownfield evidence, operational control, security, transition method and commercial clarity. Reject anyone who promises a rewrite or fixed delivery plan before inspecting the system.",
  "headline": "Software Project Takeover: A 30-Day Provider Change Plan",
  "image": "https://wavect.io/img/blog/headers/header_software-project-takeover-provider-change.svg",
  "inLanguage": "en",
  "keywords": "Engineering, Software Takeover, Vendor Management",
  "mainEntityOfPage": {
    "@id": "https://wavect.io/blog/software-project-takeover-provider-change/",
    "@type": "WebPage"
  },
  "publisher": {
    "@id": "https://wavect.io/#organization",
    "@type": [
      "Organization",
      "ProfessionalService",
      "LocalBusiness"
    ]
  },
  "url": "https://wavect.io/blog/software-project-takeover-provider-change/",
  "wordCount": 2793
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "BreadcrumbList",
  "itemListElement": [
    {
      "@type": "ListItem",
      "item": "https://wavect.io/",
      "name": "Home",
      "position": 1
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/blog/overview/",
      "name": "Blog overview",
      "position": 2
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/blog/topics/business-regulation/",
      "name": "Business and regulation",
      "position": 3
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/blog/clusters/software-buying-funding/",
      "name": "Software buying and funding",
      "position": 4
    },
    {
      "@type": "ListItem",
      "item": "https://wavect.io/blog/software-project-takeover-provider-change/",
      "name": "Software Project Takeover: 30-Day Provider Change Plan | ",
      "position": 5
    }
  ]
}
```

```json
{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": [
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Use 30 days as an initial control and assessment window, not a universal completion promise. Small products may reach independence sooner. Regulated, distributed or poorly documented systems often need longer overlap and staged cutovers. Define completion through build, deploy, rollback, restore and incident-response evidence."
      },
      "name": "How long does a software-project takeover take?"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Often yes, if the client can lawfully provide code, infrastructure and stakeholder access. Expect more discovery cost and uncertainty. The new team must reconstruct architecture and operating knowledge from repositories, configuration, telemetry, tickets and interviews, then write the missing runbooks as it verifies them."
      },
      "name": "Can a new provider take over software with no documentation?"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Not before assessment. First compare continued maintenance, targeted stabilisation, boundary-by-boundary modernisation and replacement. A rewrite is justified only when evidence shows that the total cost and risk of preserving the current system are worse than replacement."
      },
      "name": "Should the new provider rewrite the software?"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Preserve contracts, invoices, correspondence and current access. Identify what the client already owns and controls, avoid unauthorised access, and have qualified counsel assess rights and remedies. Technically, prioritise backups, account recovery, service continuity and a documented unknowns register."
      },
      "name": "What if the outgoing provider refuses to cooperate?"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "At minimum: asset and access inventory, system and data-flow map, build and deployment status, operational and security risk register, dependency and licence concerns, documentation gaps, stabilisation priorities, reuse-versus-replace options, team needs and a costed next-step proposal with assumptions."
      },
      "name": "What should a takeover assessment deliver?"
    },
    {
      "@type": "Question",
      "acceptedAnswer": {
        "@type": "Answer",
        "text": "Give finalists the same redacted scenario and score evidence, not confidence. Weight brownfield experience, transition method, release and recovery ability, security and data handling, commercial clarity, product judgment and team continuity. Require a written assessment that remains useful if you choose someone else for implementation."
      },
      "name": "How do I compare software takeover providers?"
    }
  ]
}
```