The biggest reason grants teams delay switching from spreadsheets isn't cost or decision-making — it's fear of the migration. The worry that moving to a new system mid-programme will create gaps, lose historical data, or confuse applicants.
These risks are real but manageable. The key is planning the migration carefully rather than treating it as a technical task you hand off to IT.
This guide walks through a practical migration approach for grants teams.
Before you configure a new system or import a single row, spend time documenting your current setup. This serves two purposes: it gives you a clear picture of what needs to migrate, and it reveals the gaps and inconsistencies in your current data that you'll want to clean up before they follow you into the new system.
Document your current programmes:
- What programmes are active, and what stage is each application in?
- What programmes are closed, and do you need historical data accessible?
- What are the key fields for each programme (applicant details, grant amounts, status values, payment records)?
Audit your data quality:
- Are status values consistent? (If some rows say "Approved" and others say "approved" or "APPRV", normalise these before migrating)
- Are there duplicate records?
- Are key fields complete, or are there gaps you'll need to fill?
- Do you have all supporting documents, or are some attached to emails?
Identify your must-haves:
- Which historical data do you need to be searchable in the new system?
- Which data is useful to keep for reference but doesn't need to be live in the system?
- What does your team need to be able to do on day one of going live?
The worst time to switch systems is mid-round — when you have active applications in assessment, payments pending, or acquittals overdue.
The best time is between grant rounds: after one round has closed and before the next opens. This gives you a clean break point where data is settled and you can stand up the new system without disrupting active work.
If your programmes are staggered and there's no clean gap, prioritise migrating programmes in sequence — close out one programme in the old system, migrate it, and run the next round in the new system. Don't try to run the same programme across two systems simultaneously.
It's tempting to import data first and configure later. Don't. You'll end up importing data into a structure that doesn't fit your programmes and spending more time cleaning up than if you'd set up the system first.
Work through configuration in this order:
Once configuration is complete and your team has tested it, then import your historical data.
Import in the following order, validating at each step before proceeding:
Layer 1: Active applications
These are your highest priority — any errors here affect live work. Import active applications first, verify every record manually, and confirm status values are correct before proceeding.
Layer 2: Recent closed programmes
The last two or three grant rounds you'll need to reference regularly for grantee management, acquittals, and reporting. Import these next and spot-check a sample.
Layer 3: Historical archive
Older closed programmes that you want searchable for reference. These can be imported in bulk with less manual verification, as they're unlikely to affect active decisions.
Layer 4: Documents
If your system supports document attachment, attach key documents (applications, assessor notes, grant agreements) after the record import is stable.
For the first two to four weeks in the new system, keep your spreadsheets current as a fallback. This isn't ideal — it creates double-handling — but it protects you if something goes wrong in the new system during the transition.
Set a date for the spreadsheet cutover. Once the team has confidence in the new system and the data has been validated, stop updating the spreadsheets. Archive them in a read-only folder and move fully to the new system.
Don't extend the parallel period indefinitely. It creates data drift and makes the cutover harder the longer you wait.
The most common implementation failure is training the team on the new system after they're already using it. By then they've developed workarounds and the training feels disruptive.
Run training sessions before go-live:
- Admin and programme managers: full system training, focus on configuration and data management
- Assessors: focused training on the assessment portal — they only need to use a small part of the system
- Finance and reporting users: focused training on reporting, dashboards, and payment workflows
Record sessions if your team is spread across locations. Keep training focused on tasks, not features — people learn better when they're doing their job in the system than when they're watching a general product tour.
A grants team running three programmes that migrates well will typically spend:
- Two to three weeks on audit and documentation
- One to two weeks on system configuration and testing
- One week on data import and validation
- Two to four weeks of parallel running
- One day of cutover
Total: six to ten weeks from decision to full cutover. That's not long. The teams that drag it out are usually the ones who try to migrate while maintaining full programme operations, without dedicated time for the project.
If you can assign one person half their time to the migration for two months, you'll get there cleanly.
This article is part of the complete guide: The Hidden Cost of Managing Grants in Spreadsheets.