The decision to switch grants management software — or to move from a manual process to purpose-built software — is typically made because the current approach is no longer working. Applications are being managed across disconnected systems. Staff are spending hours compiling reports that should be automatic. An audit or OIA request revealed gaps in the documentation trail that nobody realised were gaps until they were asked to fill them.
The problem is clear. The solution — switch to a new system — is also clear in principle. What is less clear is how to make that switch without disrupting the programmes that are currently running, while avoiding the mistakes that make system implementations fail.
Most grants management software implementations that fail do not fail because the software was wrong for the organisation. They fail because the implementation was treated as a technology project rather than a process change project.
Configuring a system to match a broken process. The temptation when implementing a new system is to replicate the current process in the new tool. If the current process involves ten approval steps and four spreadsheet columns for tracking conflicts of interest, the implementation team reproduces those ten steps and four columns in the new system. The system runs, but it still has the process problems that made the old system inadequate.
The right approach is to redesign the process when the system is being configured. Implementation is the moment when change is easiest to make. Using it to replicate the status quo is a missed opportunity.
Underestimating data migration complexity. Moving existing grant records from a spreadsheet or previous system into a new one is almost always harder than it looks. Data that was stored informally (applicant names in different formats, incomplete records, inconsistent category labels) needs to be cleaned, normalised, and validated before import. This takes time that is routinely underestimated.
No plan for parallel running. Many organisations try to "cut over" to a new system immediately — stopping the old process and starting the new one at the same time. This works in theory. In practice, ongoing programmes that are partway through their lifecycle cannot simply be moved. A grant round where applications are already being assessed in the old system cannot be cleanly migrated mid-assessment. A plan for which rounds will complete in the old system and which will start in the new one is essential.
Insufficient training. Assessors who are volunteers, programme staff who use the system sporadically, governance members who need to see reports — all of these users need to understand the new system. A one-hour training webinar delivered once is not sufficient for a team of non-technical users who will be using the system under deadline pressure.
Switching grants management systems requires a clear-eyed evaluation of the available options. The evaluation questions that matter most:
Does it handle your programme types? A system designed for simple single-year grants may not handle multi-year programme grants with complex milestone structures. A system designed for corporate foundations may not handle the probity requirements of a government grants programme. Before evaluating on price or interface, confirm the system can handle the specific programme types you run.
Can the application form be fully configured? The application form is the front face of your programme to applicants. If the system provides a fixed-format application form that you cannot customise to your exact questions and document requirements, you will need to work around it — typically by adding supplementary forms outside the system, which breaks the data integration.
How does the assessment workflow work? Does the system support your assessment structure — the number of assessors, the scoring methodology, the COI declaration process, the panel deliberation record? Systems that assume a simple scoring model may require workarounds for more complex assessment designs.
What does the audit trail look like? For government and public-sector funders, the audit trail is a non-negotiable requirement. Ask specifically: what actions are logged, with what timestamps and attribution? Can you produce a full record of every decision event for a specific grant? Can you export this record in response to an OIA request?
What is the vendor's approach to support and configuration? Some grants management vendors sell the software and leave configuration to you. Others provide onboarding support, configuration services, and ongoing customer success. The right model depends on your team's capacity and the complexity of your configuration. For most public sector and charitable trust funders, some level of vendor-supported configuration is more realistic than self-service.
What is the total cost of ownership? The licence or subscription fee is not the only cost. Implementation time (staff time), data migration effort, training, and any configuration or professional services costs all need to be factored in. A lower-cost system that requires more staff time to implement and operate may not be cheaper in practice than a more expensive system that is fully supported.
Not all historical data needs to be migrated. The goal of data migration is to ensure that:
- Active grants (grants that are currently in progress, with ongoing accountability obligations) are visible in the new system
- The history needed for re-application assessment (prior grant history, accountability performance) is accessible
- The documentation required for audit or reporting purposes is stored somewhere accessible
This typically means:
- A priority list of records that must be fully migrated (active grants, recent completed grants)
- A secondary list of records that can be migrated in summarised form or stored externally
- Historical records that can be archived outside the new system with a clear retrieval process
Attempting to migrate everything from a ten-year history of spreadsheet records is usually a mistake. It takes significant time and the data quality of old records is typically poor. A pragmatic migration that focuses on what is actually needed is almost always preferable to a comprehensive migration that delays go-live by six months.
Assessors — especially volunteer assessors who use the system infrequently — are often the most challenging user group in a system transition. They may have strong preferences for the familiar process, limited time to learn a new interface, and no institutional incentive to invest in system proficiency.
For the transition to work with assessors:
- The new system needs to be demonstrably easier for assessors to use, not just different
- Training should be role-specific (assessors get training on their workflow only, not the full system)
- The first round using the new system should have someone available to support assessors in real time
- Communication should emphasise what has improved for the assessor, not just that the organisation is moving to a new system
The most important thing an assessor needs to know: where are the applications I've been assigned, and how do I submit my scores? If those two things are easy in the new system, the transition will work.
If you are evaluating grants management software options and want to understand how Tahua approaches the configuration and implementation process, the government grants management and community foundations solution pages explain the relevant capabilities. To discuss your specific migration situation, book a conversation.