Moving from one grants management system to another is one of the most significant operational projects a grants team undertakes. It involves data migration, process change, staff training, and a period of running two systems simultaneously. Done well, migration leads to better administration and improved programme delivery. Done poorly, it results in lost data, broken workflows, and staff who can't find what they need.
This guide covers the key considerations for a successful grants management system migration.
Outgrowing spreadsheets. Many organisations start managing grants in spreadsheets and eventually hit the ceiling of what spreadsheets can handle — too many active grants, too complex a workflow, too many people trying to work in the same file.
Legacy system limitations. Older grants management systems — particularly on-premises systems or early SaaS platforms — may have limitations that newer systems don't: poor mobile experience, limited integration, outdated reporting, missing workflow features.
Consolidation. Organisations running multiple systems (different systems for different programmes, or grants management separate from CRM) may consolidate onto a single platform.
Vendor changes. A vendor being acquired, going out of business, or significantly changing their pricing or product direction may prompt a switch.
Programme redesign. A major programme redesign — new eligibility, new assessment approach, new reporting requirements — may be the trigger to move to a system better suited to the new design.
The scope of a migration depends on how many historical records need to move to the new system. Typical data categories:
Organisation records. Every organisation that has ever applied to your programme — name, registration number, address, contact details. Organisation records may extend back many years and involve thousands of entities.
Grant records. The core grant history — every application submitted, every grant approved, every payment made, every report received. For active grants, this data is operationally critical; for historical grants, it's important for reference and organisational learning.
Application content. The actual content of applications — answers to questions, budgets, supporting documents. This is the most voluminous data and the hardest to migrate cleanly, because it may be in a mix of structured data and unstructured documents.
Assessment records. Assessor scores, assessment notes, panel minutes, decision records. Required for probity and audit purposes.
Correspondence and communications. Emails, letters, notifications sent to and from applicants. May be held in the grants management system or in email systems outside it.
Financial records. Payment amounts, payment dates, payment references, acquittal status. Financial records may need to match your accounting system.
Contacts. Individual contact records — staff at applicant organisations, assessors, funder contacts — with their associations to organisations and grants.
Full historical migration. Moving all historical data from the old system to the new system. Provides continuity — staff can find everything in one place. This is the most complex and expensive option.
Active grants migration. Moving only active (in-progress) grants and current organisation records, leaving historical data in the old system (read-only or archived). Simpler and faster than full migration, but requires maintaining access to two systems for historical reference.
New programme migration. Starting clean in the new system for new programmes while running out existing grants in the old system. Simplest transition but takes longest to achieve full consolidation.
Cut-over migration. Moving everything on a specific date, after which the old system is no longer used. Requires thorough data migration, extensive testing, and high confidence in the new system before cut-over.
Phased migration. Moving one programme or data category at a time. Reduces risk but extends the transition period and may require temporary dual-system operation.
Migration is an opportunity — and a requirement — to clean up data quality. Before migration:
Audit what you have. What data exists in the current system? How complete is it? What are the gaps?
Resolve duplicates. Duplicate organisation records, duplicate contact records, and duplicate grant records need to be resolved before migration to avoid carrying the duplication into the new system.
Validate active grant data. For active grants that will be migrated, confirm that all the relevant data is complete and accurate — payment amounts match accounting records, contact details are current, report status is correctly recorded.
Classify historical data. Decide which historical records will be migrated and which will be archived. Not everything needs to come across — records from many years ago for closed programmes may be better archived in a separate system.
Data export formats. Can your current system export data in formats that the new system can import? Standard formats (CSV, Excel, JSON, XML) are generally more portable than proprietary export formats.
Document migration. Supporting documents — PDFs, Word files, images attached to grant records — are often the hardest part of a migration. Large volumes of documents require automated migration tools or manual re-upload.
Data mapping. Fields in the old system rarely map exactly to fields in the new system. Building a data mapping document — this field in the old system becomes this field in the new system — is an essential planning step that surfaces gaps and mismatches early.
Transformation requirements. Some data may need to be transformed during migration — date formats changed, option fields re-coded, address formats standardised. These transformations need to be defined, tested, and validated.
Testing. Migration should always be tested before go-live — migrating a sample of records and validating that they look correct in the new system. Testing catches data quality issues and mapping errors before they affect production data.
The period during migration is operationally risky — both systems need to work, staff need to know which system to use for what, and no data should be entered into the old system after the cut-over point without a plan for migrating it.
Freeze dates. Agree a date after which no new data is entered into the old system. New applications, new payments, new reports all go into the new system from this date.
Running grants in transition. Grants that were started in the old system and are still active at migration need specific plans — when will they be migrated, how will milestone tracking continue, who is responsible for ensuring they're correctly reflected in the new system?
Staff training before cut-over. Staff should be trained in the new system before the cut-over date — ideally with a test environment they can practice in. Cutting over to a system staff haven't used before is a recipe for errors.
Parallel operation period. Running both systems briefly in parallel — using the new system as the primary but able to fall back to the old — provides a safety net if issues emerge post-migration.
Underestimating data quality problems. Data that looks clean in a spreadsheet or old system often has significant quality issues when examined systematically. Allow time for data cleanup.
Insufficient testing. Migrating to production without thorough testing of a sample dataset leads to data integrity issues that are expensive to fix after the fact.
No rollback plan. If the migration fails or the new system has critical issues post-cutover, what's the plan? Having a clear rollback process — even if you hope never to use it — is essential risk management.
Leaving active grants behind. Failing to migrate active grants means staff have to maintain two systems simultaneously for an extended period — with the associated risk of inconsistencies.
Staff not ready. Going live with a new system before staff are trained and comfortable is a common cause of operational disruption during migration periods.
Tahua's implementation team supports migrations from spreadsheets, SmartyGrants, Fluxx, Salesforce, and other platforms — with data mapping, testing, and managed cut-over.