Blog

Build, Buy, or Bolt-On? What to Look for When Evaluating a Nonprofit-Specific ERP 

Woman thinking in front of a chalkboard with multiple arrows and question marks, representing the build, buy, or bolt-on decision nonprofits face when evaluating a new ERP system

In short: Nonprofits leaving Dynamics GP (mainstream support ends December 2029) or outgrowing QuickBooks face the same underlying choice, whether they realize it or not: build custom software, buy a system actually designed for nonprofit fund accounting, or bolt add-ons onto a general-purpose platform. Most organizations end up on “bolt-on” by accident, even after migrating to something modern like Business Central, unless they specifically evaluate for native fund accounting, data residency, flexible approval workflows, and real (not marketed) AI features.


Somewhere in a finance office right now, there’s a server running Microsoft Dynamics GP, doing exactly what it’s done for the last fifteen or twenty years. Across town at another nonprofit, someone’s logging into QuickBooks for the third time today, juggling a browser tab for the donor database and a spreadsheet that’s become the actual system of record for grant tracking. Neither team has touched the bigger question yet. There’s always something more urgent than a software decision that doesn’t feel urgent until suddenly it very much is. 

Here’s the number that should change that calculation for the Great Plains crowd specifically. According to Microsoft’s own 2024 Dynamics GP Customer Survey, 57% of current GP users have no plans to migrate within the next three years, and 46% have no plans within five. Microsoft has confirmed mainstream support for GP ends in December 2029, with security updates stopping for good by April 2031. With an estimated 30,000 organizations worldwide still running on Great Plains, that’s a genuinely enormous wave of nonprofits, school boards, and public sector organizations all going to hit the same implementation bottleneck around the same time, all trying to hire from the same limited pool of migration partners who actually understand nonprofit accounting. 

The QuickBooks crowd is facing another version of the same wall. There’s no end-of-life date forcing the issue, just the slow accumulation of workarounds, until one day the spreadsheet tracking restricted grants is doing more real accounting than QuickBooks itself. Often it’s growth that gets them there faster than they expected. Need for services hasn’t slowed down, inflation has only made the case for support more urgent, and a lot of organizations that started as a four-person operation running everything out of one shared inbox are now 140 people deep, managing a dozen grants and three times the program staff. QuickBooks was never built to grow alongside an organization like that, and at a certain size, finance simply can’t keep up with the rest of the org anymore. 

Either way, the decision in front of these organizations is bigger than “what do we replace it with.” It’s actually three separate paths, and most people don’t realize they’re choosing between them until they’ve already accidentally picked one. 

Build, buy, or bolt-on: the real decision nonprofits face

Build, buy, or bolt-on. It sounds like a framework from a business school case study, but it maps onto something very real for any nonprofit evaluating its next finance system. 

Build means custom development — hiring developers to construct something from scratch, tailored exactly to your organization. It sounds appealing in theory and is almost never worth it in practice for a nonprofit, for the simple reason that your mission isn’t software development, and neither is your budget. 

Buy means choosing a system that was actually designed around how nonprofits work: fund accounting, grant tracking, restricted versus unrestricted funds, all built into the core rather than added later. 

Bolt-on means taking a general-purpose platform — built for businesses, not nonprofits — and stacking add-ons, integrations, and spreadsheets on top of it to cover whatever it can’t natively do. 

Almost nobody consciously chooses bolt-on. It’s the path you end up on by default, one reasonable decision at a time. 

The bolt-on trap most nonprofit ERP migrations fall into

Here’s the part that’s easy to miss, and it isn’t unique to organizations leaving Great Plains. Microsoft’s own recommended path for GP customers is Dynamics 365 Business Central, and for a lot of organizations, that feels like the obvious, safe choice. It’s modern, it’s cloud-based, it’s still Microsoft. But Business Central, on its own, is designed primarily for small to mid-sized businesses, not nonprofits. Fund accounting, grant management, and the rest of the nonprofit-specific workflow your finance team actually lives in often need to be added through extensive customization or third-party add-ons. 

The same trap is waiting for anyone leaving a different legacy system, too — an aging on-premise accounting platform, a homegrown database somebody’s nephew built a decade ago, or a general business ERP a board member recommended because it worked well at their company. And it’s waiting for the organizations growing out of QuickBooks, who often default to “whatever the next tier up is” without asking whether that next tier actually understands fund accounting or just has a bigger price tag. In every case, the pattern is the same: leave the old system, land on something general-purpose and modern, and end up rebuilding the same patchwork of spreadsheets and add-ons on a newer foundation. 

Which means an organization can do everything right — leave a legacy system, modernize, move to the cloud — and still land right back in the bolt-on category, just with a newer, shinier base layer underneath the same workarounds it had before. The system changes. The actual problem doesn’t. 

What to look for in a true nonprofit ERP

This is where the real evaluation criteria live, and it’s worth being specific, because plenty of systems marketed as nonprofit-friendly are general business tools with a nonprofit-shaped coat of paint over them. 

  • Data residency and hosting. Where does your data physically live, and do you get to choose? For US health and human services organizations especially, this isn’t a nice-to-have. A system that lets you pick a US data center as your primary location, with full replication staying inside the country, gives you a level of control over your own data that a lot of platforms simply don’t offer as an option. 
  • SaaS versus on-premise. Most nonprofits don’t have a dedicated IT department, and that’s not a weakness, it’s just reality. A fully hosted SaaS environment means security, uptime, and infrastructure are someone else’s job, which matters enormously when your actual staff are busy running programs, not patching servers. 
  • Approval workflow flexibility. Not just whether a system has approval workflows, but whether they can actually flex to your organization’s real structure. Some systems offer a rigid, one-size-fits-all chain of sign-offs. Others let you build approvals around dimensions, dollar thresholds, sequential or parallel routing, with no hard ceiling on how many steps or rules you set up. If a vendor tells you, in essence, “go ahead and build it however complex your org actually needs it to be,” that’s a meaningfully different product than one that makes you compromise your process to fit the software. 
  • OCR and AI capabilities. Worth asking about, and worth a little skepticism. The genuinely useful version of this is narrow and concrete: scanning an invoice and automatically pulling the vendor, amount, and line items into the system, or recognizing a duplicate transaction before it gets paid twice. That’s real, practical time saved. Treat anything marketed as a sweeping AI transformation of your entire finance function with a bit more caution until you’ve actually seen it work on your own data. 
  • Fund accounting and grant tracking, native versus bolted on. This is the test that separates an actual nonprofit ERP from a relabeled commercial one. Ask to see fund-level reporting live, in the demo, not described to you on a slide. If the answer involves a third-party module, a custom report someone has to build for you, or “we can definitely set that up,” that’s useful information about which category you’re really looking at. 

Why a forced deadline is the right moment to choose deliberately

It’s tempting to think of a deadline like Great Plains’ end-of-life purely as a problem to manage. It’s also, genuinely, a forcing function that pushes a decision a lot of organizations would otherwise keep deferring indefinitely. The same is true of outgrowing QuickBooks, or realizing the homegrown spreadsheet system has finally buckled under the weight of a dozen active grants. Whatever the trigger, the moment an organization is forced to look at a new system is exactly the moment worth using to ask the bigger question, instead of just reaching for whatever feels like the safest, most familiar upgrade. 

Sparkrock exists in exactly the space this decision creates, regardless of which door an organization is walking through. It’s built directly on Microsoft Dynamics 365 Business Central, so organizations already comfortable in the Microsoft ecosystem don’t have to leave it behind to get something better, whether they’re migrating off Great Plains, finally graduating past QuickBooks, or retiring some other legacy system that’s run its course. Fund accounting, commitment and encumbrance tracking, and grant management are built into the core of the product, not stacked on top as an afterthought, which is the entire gap a generic platform migration leaves open no matter what system it’s replacing. It’s a way to actually land on “buy” instead of drifting into “bolt-on” while believing you’ve modernized. 

Questions to ask when evaluating a nonprofit ERP vendor

Whatever path you’re leaning toward, a handful of plain questions in any vendor demo will tell you a lot. 

  • Can you show me fund-level reporting live, right now, rather than describing it to me?
  • Is the nonprofit-specific functionality built into the core product, or is it a third-party add-on I’ll need to license and maintain separately? 
  • Where does my data actually live, and do I get to choose that? 
  • What happens to my approval process if my organization’s structure doesn’t match your default template? 

If a vendor can answer all four of those clearly and show you, not tell you, that’s a strong signal you’re looking at a real “buy,” not a bolt-on wearing a buy’s clothing. 

Great Plains, QuickBooks, and the decision still in front of you

The 30,000 organizations still running Great Plains aren’t all going to move at once, but a lot more of them are going to be forced into the decision around the same window than anyone currently expects, simply because more than half haven’t started planning yet. Plenty of other organizations are sitting on their own version of that same fork in the road right now, whether the trigger is a sunsetting legacy system, a QuickBooks setup straining under real growth, or just the slow realization that the current system was never built for a mission like this one. Whatever got you to this decision, it’s worth making the build, buy, or bolt-on choice deliberately, while there’s still room to choose well, instead of reactively, once the options have already narrowed. 

Watch the on-demand webinar — A Live Look at a Modern Finance System Built for Health Nonprofits — or book a demo with Sparkrock to see what a true nonprofit ERP, built natively rather than bolted on, actually looks like for your organization. 

Frequently asked questions

What happens when Microsoft ends support for Dynamics GP? Mainstream support for Dynamics GP ends in December 2029, with security updates stopping entirely by April 2031. Microsoft’s own 2024 customer survey found 57% of current GP users had no migration plans within three years, which means a large wave of organizations are likely to hit the same migration bottleneck around the same time.

What’s the difference between build, buy, and bolt-on for a nonprofit ERP? Build means custom-developing software from scratch, which is rarely worth the cost for a nonprofit. Buy means choosing a system with fund accounting, grant tracking, and restricted-fund handling built into its core. Bolt-on means taking a general business platform and stacking add-ons and spreadsheets on top to cover what it can’t do natively — usually the default outcome rather than a deliberate choice.

Is Dynamics 365 Business Central good for nonprofits on its own? Business Central is Microsoft’s recommended migration path off Dynamics GP, but on its own it’s designed for small to mid-sized businesses, not nonprofits. Fund accounting and grant management typically have to be added through customization or third-party add-ons, which can land an organization back in the “bolt-on” category even after a modern migration.

What questions should nonprofits ask when evaluating an ERP vendor? Ask to see fund-level reporting live rather than on a slide, whether nonprofit-specific functionality is built into the core product or licensed separately as an add-on, where your data physically lives and whether you can choose that, and what happens to your approval workflow if your organization’s structure doesn’t match the vendor’s default template.

Author

  • Bri-anna Ramsden has spent over a decade working in and alongside the kinds of organizations Sparkrock serves. As a former educator at Lambton College, a longtime instructor and program leader with the YMCA, and a researcher with Enactus, she brings firsthand experience with the operational and administrative realities facing nonprofits and educational institutions. Now at Sparkrock, she channels that sector knowledge into content that helps finance leaders, administrators, and school board teams make smarter decisions with confidence.

Related Posts