--- title: "What Happens to Donor-Funded Software When the Funding Ends" date: 2026-10-29 author: "Tobias Rast" featured_image: "https://static.pegotec.net/uploads/2026/09/donor-funded-software-funding-cliff.webp" categories: - name: "Pegotec News" url: "/category/news.md" --- # What Happens to Donor-Funded Software When the Funding Ends Here is a detail that makes the point better than any statistic. For fifty years, USAID ran the Development Experience Clearinghouse — the public archive of what happened to donor-funded projects. It went offline in early 2025. As of September 2026, the domain still does not resolve, and no official replacement exists. Volunteers and research groups have rebuilt parts of it privately. None of them is obliged to keep it online. The record of what happens to donor-funded software when the money stops was itself donor-funded software. It stopped too. ## Donor-funded software outlives its budget. Anyone who has worked in the sector knows the pattern. A three-year program procures a platform. The program closes. Afterward, the platform either keeps running or stops. Notably, procurement usually decided which, years earlier. This article covers what the contracts actually transfer, what independent evaluations found, and the handful of decisions that change the outcome. It speaks to the people who sign before anyone builds anything. ## Donor requirements are weaker than most people assume Start with what is actually mandatory, because the answer surprises people. The World Bank’s Investment Project Financing Directive does not require a sustainability plan, an exit plan, or a handover plan as an appraisal deliverable. Life-cycle costing in its Procurement Regulations is recommended rather than required—it “should be used whenever possible,” and the binding obligations attach only once a borrower opts in. The ADB is stricter. It requires financial analysis of a project’s recurrent-cost burden *before* the investment decision. Furthermore, where the operating agency probably cannot fund that burden, the analysis must record a sustainability risk. Meanwhile, the Principles for Digital Development, revised in 2024, ask a program to present the long-term cost of ownership — licenses, operations, maintenance and capacity building — and to name who pays afterward. Note the distinction that matters. Principles are advisory. An appraisal requirement is not. Consequently, do not assume your donor mandates an exit plan simply because good practice describes one. ## The word “software” does not appear This is the finding worth taking to your next contract review. Under the standard General Conditions for EU-financed grant contracts, the mandatory end-of-action asset transfer covers “equipment, vehicles and supplies.” The 34-page document never uses the word **software**. That transfer clause therefore does not cover your source code, although most people assume it does. Ownership follows the same pattern. Under those conditions, intellectual property vests by default in the implementing beneficiary, not the Commission or *the partner government*. The World Bank’s standard information-systems contract does vest custom-software IP in the purchasing government, but only for items its appendices actually enumerate. So the ministry that will operate the system may not own it, unless somebody wrote that down. ## Escrow is off unless you switch it on. One more default worth knowing. In the World Bank’s information-systems contract, source-code escrow “shall not be required” unless the Special Conditions say otherwise, and the template ships without it. US federal guidance takes a stronger line, and it is worth borrowing regardless of your funder. Code should live in a repository the government controls *throughout the build*, rather than arriving at the end. Additionally, a software contractor should not also host the software. Otherwise, the code never enters the agency’s custody at any point in its life. ## The affordability fallacy The ADB names a specific argument a “fallacy”: that a new system is affordable because its running cost is a small percentage of the agency’s total IT budget. Small percentages of large budgets are still unfunded if nobody assigns them. Procurement itself has a related trap. The World Bank’s own guidance warns that bidders can legally move cost out of the evaluated bid price and into post-warranty recurrent costs, chiefly by choosing annual licensing over perpetual. The winning bid looks cheapest precisely because the expensive years fall outside the evaluation window. ## What evaluations actually found In the ADB’s 2025 validation round, **sustainability ranked as the second most common reason for downgrading completed projects** from successful to less than successful. It appeared in 7 of 13 downgraded completion reports. One validation of an ADB-financed ICT project in Nepal found that nobody ever analyzed the resources needed to operate and maintain the e-government applications it delivered. Moreover, the team fully developed a vehicle registration system and never rolled it out. Staff turnover at the restructured national ID agency then suspended live services within two years. A Global Fund audit of transition management recorded an average **33% funding gap** in transitioning countries. It also documented services ceasing or declining after withdrawal. Separately, another audit found a donor upgrading logistics software in Mozambique without matching investment in the hardware, maintenance, training and supervision needed to run it. ## “We will open-source it” is not an exit plan Open licensing is good practice, and several funders now require it. The UNICEF Venture Fund, for instance, makes an OSI-approved license a dated contractual milestone at month six rather than an aspiration. However, publishing a repository does not create anyone to maintain it. The Digital Public Goods Alliance’s own ecosystem report names maintenance funding as a leading unresolved gap and issues a substantial funding appeal to address it. Notably, that standards body does not claim open-sourcing solves the problem. The clearest evidence comes from DHIS2, a health platform that some eighty governments use as a system of record. In May 2026, its stewards introduced a voluntary Shared Services Fee. Their stated reason: donors who historically funded core development had “pivoted toward focusing their funding on country-level systems, leaving a gap in funding for the core DHIS2 platform.” Indicative rates start at 5,000 US dollars a year for low-income public-sector instances, with a flat 7,500 for NGOs. The software nevertheless remains free and open source. If the most successful donor-funded platform in the world had to ask, assume your project will too. ## Abandoned infrastructure becomes someone else’s asset A closed program leaves live accounts behind, and they do not become harmless. Researchers re-registered roughly 150 orphaned cloud storage bucket names for about 400 US dollars and logged over eight million requests to them. Systems that no longer exist were still calling those addresses, and whoever holds the name now receives whatever they send. Accordingly, closure needs an inventory. Hosting accounts, domain registrations, certificates, third-party API keys, paid subscriptions and administrator credentials. UNDP’s digital standards make a related point: handing over code, servers, credentials, and vendor details does not, by itself, constitute a handover. Someone must also write down the daily operating processes. ## What to settle before procurement 1. **Name who pays in year four.** Not “the ministry” — a budget line. The Principles require this, and most programs still skip it. 2. **Write software into the transfer clause.** If the template says equipment, vehicles and supplies, it does not cover your source code. 3. **Put the repository under the operating institution from day one,** not at closure. 4. **Do not let the builder also be the host.** Otherwise, the code never enters the owner’s custody. 5. **Evaluate bids on life-cycle cost,** since annual licensing hides expense beyond the evaluation window. 6. **Choose technology the local market already knows.** The validation credited exactly that choice for Nepal’s surviving e-government applications. 7. **Hand over during the** program**, not at the end,** and include operating processes, not just credentials. ## How Pegotec helps We build for donor-funded and government programs across Southeast Asia, so we scope the handover at the start rather than in the final quarter. We’d rather write the exit into the contract than discuss it when the budget is already closing. If you are designing a program that will leave software behind, [talk to us](https://pegotec.net/contact-us/). ## Read next - [The True Cost of Deferred Maintenance](https://pegotec.net/true-cost-of-deferred-software-maintenance-2026-failure-benchmarks/) — what an unfunded system accumulates. - [Where Your Data Can Legally Live](https://pegotec.net/data-residency-southeast-asia-2026-decision-framework/) — jurisdiction constraints on public-sector data. - [Web-Based Enterprise Solutions](https://pegotec.net/service/web-based-enterprise-solutions/) — how we build systems meant to outlast a program. ## FAQ **Who owns software built with donor funding?**Often not the government that will operate it. Under the standard General Conditions for EU-financed grant contracts for external actions, intellectual property in the results vests by default in the implementing beneficiary — not in the Commission and not in the partner government. The World Bank’s standard information-systems contract does vest custom-software IP in the purchasing government, but only for the items actually enumerated in its appendices. Somebody therefore has to write ownership down deliberately, rather than assume it follows the funding relationship. **Do donors require a sustainability or exit plan?**Less often than assumed. The World Bank’s Investment Project Financing Directive does not require a sustainability plan, exit plan, or handover plan as an appraisal deliverable, and its Procurement Regulations recommend, rather than require, life-cycle costing. The ADB is stricter, requiring financial analysis of the recurrent-cost burden before the investment decision and recording a sustainability risk where the operating agency is unlikely to afford it. The Principles for Digital Development require naming who pays long term, but the principles are advisory rather than binding. **Is open-sourcing a valid exit plan for donor-funded software?**Open licensing is good practice, and some funders require it—the UNICEF Venture Fund makes an OSI-approved license a dated contractual milestone at month six. But publishing a repository does not create anyone to maintain it. The Digital Public Goods Alliance’s ecosystem report names maintenance financing as a leading unresolved gap. DHIS2, used as a government system of record in around eighty countries, introduced a voluntary Shared Services Fee in May 2026 because donors had shifted funding to country-level systems and left the core platform underfunded. Treat open source as a licensing decision, not a funding one. **What should a software handover actually include?**More than code and credentials. UNDP’s digital standards state that transferring source code, servers, access credentials, and vendor details is insufficient on its own and requires a handover guide covering daily operating processes. Build an inventory of everything that requires renewal or billing: hosting accounts, domain registrations, certificates, third-party API keys, paid subscriptions, and administrator accounts. Abandoned infrastructure is not harmless — researchers re-registered around 150 orphaned cloud storage buckets for about 400 US dollars and logged over eight million requests still being sent to them.