The reasoning is usually sound at the time. The organisation already has Salesforce. It already has licences, a Salesforce admin, and years of institutional data in it. Someone — often a consultant — has demonstrated that it can be configured to handle applications, track statuses, and send notification emails. The cost of building on existing infrastructure seems lower than procuring a specialist platform.
Both premises are true. Salesforce is configurable. And a custom build on existing infrastructure does have a lower upfront cost. The problem is what those premises don't account for: the ongoing cost of maintaining a custom grants system inside a CRM that was designed to do something else entirely.
This article is for the grants manager or IT lead who is living with that custom build and noticing that the costs are no longer hidden.
Salesforce's proposition in the grants context is typically one of three things:
The organisation is already paying for it. Adding grants management to an existing Salesforce implementation looks like utilising sunk cost rather than creating new cost. That logic is correct as far as it goes.
The organisation's primary grants need at the time is relationship management — tracking foundation contacts, recording conversations with grantees, managing a discretionary giving portfolio. For that use case, a CRM is genuinely appropriate. The problem is when intake and assessment are added, then milestone tracking, then payment management, then accountability reporting — one feature at a time over several years.
A consultant or internal champion has demonstrated that it can be done. Salesforce can handle grant application intake via custom forms. It can display a scoring summary. It can send emails at defined workflow stages. These demonstrations are usually accurate. The question they don't answer is: what does this cost to maintain, and what happens when Salesforce updates its platform?
A Salesforce grants build typically starts with application intake. Custom objects are created to represent applications. A form tool — usually a third-party product, since Salesforce's native forms are not built for public-facing intake — is connected to create application records. Workflow rules or Flow automations handle status transitions.
That phase usually works. The problems begin when the organisation tries to add the next layer.
Assessment rubrics require weighted scoring across multiple criteria linked to individual assessor records. In a purpose-built grants system, this is a native feature with a configuration interface. In Salesforce, it requires custom object relationships, formula fields, and either a custom Lightning component or a third-party managed package. Someone has to build it. Someone has to maintain it. When Salesforce deprecates a Lightning API (which it does, regularly), someone has to rebuild it.
Conflict-of-interest management requires the system to detect a relationship between an assessor and an applicant and automatically restrict access to that record. In Salesforce, that means custom logic in Apex code or a complex sharing rule configuration. It is not a feature; it is a development project.
Milestone-triggered payments require the system to monitor evidence submission, route it for approval, and then trigger a payment action in a finance system. None of those steps exists natively in Salesforce. Each requires custom automation, custom integration code, and ongoing maintenance as both systems evolve.
By the 18-to-24-month mark, many organisations have a Salesforce instance that handles their grants workflow — as long as nothing changes. The moment it needs to change, the cost becomes visible.
There are five functional areas where a purpose-built grants platform differs structurally from a CRM, regardless of how much Salesforce has been customised:
1. Weighted assessment rubrics with blind review. A grants assessment rubric assigns different weights to different criteria (Innovation 40%, Methodology 30%, Team 30%, for example) and aggregates scores across multiple assessors. Blind review anonymises applicant names and institutions during the scoring phase to reduce assessor bias. Neither of these is a CRM function. In Salesforce, both require custom development.
2. COI auto-recusal. When an assessor declares a conflict of interest, the system should immediately and automatically block their access to that application's data — not send them a reminder email. Enforcing that restriction at the data-access level requires custom Salesforce sharing rules and Apex triggers. It is technically achievable, but it is not a configured setting.
3. Milestone-evidence linking. Tranche payments are supposed to be conditional on evidence review and approval. In practice, if your milestone tracking lives in Salesforce and your payments are managed elsewhere, the link between approval and payment is a manual step. That step is where things go wrong.
4. Finance system integration at the transaction level. Generating a payment in your finance system when a milestone is approved — not exporting a CSV, not copying data between tabs, but having the bill created automatically in Xero — requires a purpose-built integration. Salesforce has a Xero connector, but configuring it to respond to grants-specific events requires custom development and ongoing maintenance.
5. Public register and accountability reporting. Crown entities and community funders are often required to publish a register of funded projects. That output needs to draw on accurate, current data from the grants system. Generating it from a Salesforce custom build typically requires a reporting tool, a data export, and manual formatting.
This is where total cost of ownership calculations usually go wrong. The cost of a Salesforce custom grants build is not just the initial development. It is the ongoing cost of:
Salesforce admin time. Every time something breaks or needs to change, someone with Salesforce admin access has to fix it. If that person is internal, it is opportunity cost: they are not working on something else. If that person is a contractor, it is a line item.
Release management. Salesforce releases three major updates per year. Each release has the potential to affect custom configurations, Flow automations, and Apex code. Regression testing after a release is not optional — it is required.
Integration maintenance. Third-party tools connected to Salesforce (form builders, Xero connectors, DocuSign integrations) each have their own release cycles. When one updates, the integration may need to be re-tested or reconfigured.
Knowledge retention. Custom Salesforce builds accumulate institutional knowledge in the person who built them. When that person leaves — and they will eventually leave — the organisation loses the ability to maintain what it has. Rebuilding that knowledge is expensive.
None of those costs appear on the original procurement decision. They accumulate invisibly as operational overhead until they reach a threshold where someone asks why the grants team is spending so much time maintaining their system instead of running their programme.
A fair total cost of ownership comparison between a Salesforce custom build and a purpose-built grants platform needs to include:
A purpose-built grants platform like Tahua typically implements in six to eight weeks using a train-the-trainer model. The configuration for weighted rubrics, COI management, milestone tracking, and Xero integration is native — it does not require custom development. Change requests that would require a Salesforce developer are typically configuration changes in the admin interface.
That does not make migration free. There are data migration costs, staff training time, and a transition period where both systems may run in parallel. But those are one-time costs. The maintenance overhead of a Salesforce custom build is permanent.
The decision to migrate is not purely a technology question. It involves weighing three things honestly:
What is the current system actually costing? Track admin hours spent on Salesforce maintenance over the next quarter. Include release testing, integration fixes, change requests, and troubleshooting. Multiply by the appropriate hourly rate. Compare that to the annual cost of a purpose-built platform.
What is the capability gap? List the features your grants programme needs that the current Salesforce build doesn't deliver — or delivers unreliably. Weighted blind assessment, COI auto-recusal at the data level, milestone-to-payment automation, and accountability reporting are the most common gaps. If those features matter to your programme, the question is not whether to migrate but when.
What does migration actually involve? A migration from Salesforce to a purpose-built grants platform typically involves extracting application and grantee data, mapping it to the new data model, importing historical records, and configuring the new platform for your programme structure. It is not trivial, but it is bounded. The implementation timeline is known upfront; the maintenance cost of staying on Salesforce is not.
If you are approaching a Salesforce renewal decision, that is the natural evaluation point. The renewal cost covers another period of known maintenance overhead. The alternative is a migration that replaces that overhead with a platform purpose-built for what your team is actually trying to do.
To see the end-to-end grants lifecycle — application intake through milestone-triggered payment — in a 30-minute walkthrough, book a migration conversation with the Tahua team. No obligation, and no pitch for features you don't need.