Walk into the back office of almost any small American nonprofit and you'll find something that predates the current staff. A donor database bought in 2011. A desktop accounting file that lives on one laptop and gets emailed to the bookkeeper each month. A workbook with a tab for every fiscal year going back further than anyone can explain. A membership list a board member built one weekend and then, sensibly, retired.
The reflex is to read this as a competence problem. It almost never is. The people running these systems usually know exactly how old they are and exactly what they cost — they can tell you which report doesn't reconcile, and which one has to be rebuilt by hand every quarter. What they're up against isn't ignorance. It's a set of incentives that, taken one at a time, all point in the same direction: not this year.
Those incentives are worth naming, because you can't fix the thing until you understand why it's there.
Most nonprofits are far smaller than the sector's headlines
The nonprofit sector includes hospital systems and universities as well as food pantries, parishes, youth leagues, historical societies, and lodges. This article focuses on smaller organizations where staff or volunteers combine financial administration with other responsibilities.
The IRS provides different filing routes depending on an organization’s circumstances. Eligible organizations with gross receipts normally $50,000 or less may submit Form 990-N. The general 990-EZ thresholds are gross receipts below $200,000 and assets below $500,000, with exceptions. See the IRS filing guidance for the applicable rules.
Scale matters here because nearly all business software is priced and designed for a buyer with an IT budget, a systems administrator and a procurement process. A 200-person nonprofit is a normal software customer. A four-person one is not — and it may need a different approach to implementation and support.
The accounting treats technology as the thing to minimize
This is the big one, and it's structural rather than cultural.
For organizations that complete functional expense reporting, Part IX of Form 990 distinguishes program services, management and general, and fundraising. Technology costs are not automatically overhead: allocation depends on their use. The IRS instructions for Form 990 explain the reporting categories and allocation principles.
When a board treats a low overhead ratio as its main measure of effectiveness, a system upgrade can become difficult to justify. The cost is visible immediately, while the benefit of cleaner records and fewer manual handoffs may be harder to put into a single number.
A financial ratio alone cannot explain whether a tool helps an organization deliver its work. The useful question is what the system enables, how its cost is allocated, and what the organization loses by continuing with its current process.
Review the technology costs in your own records with the person responsible for expense allocation. Ask what each system supports and where that use is documented. A software label alone does not determine its reporting category.
Restrictions can limit the available budget
The funding side compounds the problem.
A gift or grant may limit how the organization can use it. Depending on those terms, a technology purchase may be covered, partly covered, or outside scope. Before treating a fund balance as available for new software, the finance team needs to check the relevant restrictions and budget.
Indirect cost recovery can contribute to shared operating expenses, but the amount and permitted treatment depend on the award. Software competes with other needs within that budget. The practical step is to check the award terms and applicable rules with the person responsible for grant accounting.
So the organization ends up with money it can spend and money it can't — and the money it can spend is precisely the money everyone is watching.
The system is nobody's job
Most small nonprofits employ no one whose title contains the word "technology." Systems get chosen and maintained by whoever was closest at the time: an operations manager, a bookkeeper, a long-serving volunteer, a board member with a technical day job.
That produces three failure modes, all of them common:
- The volunteer-built system. Someone capable builds something genuinely useful — a membership database, a dues tracker, a reconciliation workbook — and then moves on. The tool keeps working and nobody can change it. The organization's process is now frozen at the moment its builder stepped away.
- The single point of knowledge. One person knows where the file lives, which login works, and why the March numbers have always been off by that amount. When that person leaves, institutional knowledge can leave with them. For whoever inherits it, changing nothing is the safe move.
- The orphaned account. The subscription renews on a former executive director's personal card. The bank login sends its codes to a treasurer who rotated off two years ago. Nobody wants to touch it because nobody is certain what breaks.
None of these are technology problems. They are staffing problems that present as technology problems.
The switching cost is the data, not the license
Ask why an organization is still on a 2012 donor database and the answer is almost never the price of a new one. It's that twenty years of giving history, pledge schedules, soft credits, tribute gifts, membership tenure and lapsed-donor flags live in the old one — and that history is among the organization's most valuable assets. A donor's twenty-year record is what makes the next ask work.
Migrations of that kind are genuinely hard. Fields don't map cleanly. Custom fields added by four different people over fifteen years hold three different conventions for the same thing. And the work can't happen during audit season, or the year-end appeal, or the gala, or the grant reporting crunch — which can leave very little uninterrupted time for the work.
Add a reasonable fear that the replacement turns out to be worse, and "we'll do it next year" isn't procrastination. It's a defensible risk assessment. The trouble is that it's equally defensible the following year.
Free and donated software has its own gravity
The sector has a real and generous discount ecosystem: TechSoup's donated licenses, Google's grant program for search advertising, steeply discounted nonprofit tiers from most major vendors. These are good programs and they have saved the sector an enormous amount of money.
They also shape the stack in a particular way. When a tool arrives free, the decision to adopt it never passes through an evaluation — nobody weighs it against alternatives, because there's nothing to weigh. Years later the organization is running a set of systems each chosen for being free rather than for fitting together, and the integration work between them is being done by a person with a CSV export.
The same gravity applies to affiliate mandates. Chapters of national organizations — scouting councils, fraternal lodges, diocesan parishes, league affiliates — often run whatever the national body specified, on the national body's timeline. A local chapter can be entirely clear-eyed about its software and have no authority whatsoever to change it.
The decision takes longer than the work
A material technology purchase may need board awareness, approval, or finance committee review. That can span several meeting cycles, especially when a key person leaves or a grant deadline becomes more urgent. A useful migration plan has to account for the organization’s actual decision process.
Meanwhile the current system keeps working. Badly, expensively, but it works. There is never a quarter in which replacing it is the most urgent item on the agenda.
What the old system actually costs
The honest case for changing isn't that old software is embarrassing. It's that the costs don't disappear — they move off the budget line, where they are visible and countable, and into staff hours and risk, where they aren't.
| Shows up in the budget | Shows up nowhere |
|---|---|
| Software subscriptions | Hours re-keying data between systems |
| The annual audit fee | Extra audit hours caused by messy records |
| Payment processing fees | Gifts lost to a checkout that fails on a phone |
| Staff salaries | The month a resignation freezes all reporting |
| Insurance premiums | Breach exposure on unsupported software |
That last row deserves attention. Standard support for Windows 10 ended on October 14, 2025, although eligible devices can receive security updates through Microsoft’s Extended Security Updates program and some editions have different lifecycles. Check the Microsoft support guidance for the devices in use. Software can continue holding sensitive records after its standard support ends.
What actually moves this
None of this gets solved by a lecture about digital transformation. What moves it, in practice, is small and unglamorous:
- Give the systems an owner. One named person, in writing, responsible for the accounts, the logins and the renewals. Not a new hire — an existing person with it added to their job description.
- Write the inventory down. Every system, what it costs, who pays for it, whose card it's on, when it renews, who holds admin. Most organizations doing this for the first time find at least one subscription nobody remembered and at least one account tied to someone who left.
- Budget technology as a line, and say so out loud. Put it in the budget, put it in grant applications, and claim the indirect rate you're entitled to rather than the one you think looks modest. Confirm what each award actually permits.
- Migrate the data you'll use, not all of it. Full-fidelity migration of twenty years of custom fields is where these projects die. Giving history, contact records and open pledges need to come across intact. Much of the rest can be archived as a read-only export.
- Move at the start of a fiscal year. Run the old and new side by side for one cycle. That's the difference between one difficult month and one difficult audit.
- Check the exit before you take the entrance. Ask any prospective vendor, in writing, how you get your data out and in what format. The answer tells you a great deal about the next ten years.
The reason so many US nonprofits run old software isn't that the sector is behind. It's that every individual decision to defer was reasonable, given how the money is restricted, how the ratios are read, and who was available to do the work.
Which is the useful thing about naming the incentives: most of them have shifted. The overhead conversation has moved. The indirect rate has moved. The tooling is cheaper and no longer requires anyone on staff to keep a server running. The reasons for holding on to the 2011 database are, for the most part, reasons from 2011.