The single most common reason nonprofits stay on software they know is inadequate is fear of migration. Not cost. Not features. Fear. Fear of losing data. Fear of breaking historical reporting. Fear of a migration that takes six months and leaves the team unable to close the books.
That fear is often justified by experience — either the organization's own bad migration story, or one told by a peer at a conference. But the fear is also a trap. Staying on a system that cannot produce accurate fund accounting, restricted fund reporting, or grant compliance documentation is itself a risk. The question is not whether to migrate but how to migrate without the horror stories.
Nonprofit data migration is the process of transferring financial records, donor data, and historical transactions from one software system to another — and with proper planning, it can be completed without losing data, disrupting operations, or breaking historical reporting.
What Needs to Be Migrated
Before planning the migration, inventory what you are moving. For a nonprofit switching accounting and fund management software, the migration typically includes:
Chart of accounts. The account codes and structure from the old system need to map to the new system's chart of accounts. If you are taking the opportunity to restructure your chart of accounts, this is the right time — but it adds complexity.
Fund structure. Each fund in the old system needs a corresponding fund in the new system. This is particularly important for restricted funds with specific donor intent documentation.
Historical transactions. How many years to bring over is a judgment call. The standard recommendation is three to five years of full transaction detail plus older years in summarized form. For audit purposes, you need at least the current year and the prior year in full detail.
Open balances. All accounts payable balances, accounts receivable balances, grant receivables, and fund balances as of the cutover date must migrate correctly.
Grant and fund documentation. Award letters, restriction documentation, and grant period dates are not typically stored in accounting systems but should be inventoried and transferred alongside the financial data.
The Migration Timeline
A standard nonprofit accounting migration follows five phases.
Phase 1: Pre-Migration Cleanup (Weeks 1–2)
The best migrations start with data cleanup in the old system, not in the new one. Before you export anything, reconcile your balance sheet accounts, clear outstanding reconciling items, write off uncollectible receivables, and document any funds or accounts that are no longer active but still carry balances.
Migration is not the time to discover that your old system has five years of unreconciled bank statement items. Clean the data at the source.
Phase 2: Data Mapping (Weeks 2–3)
Data mapping is the most intellectually demanding part of migration. For every data element in the old system, you need a defined destination in the new system. Account codes, fund identifiers, grant codes, project dimensions, and department tags all need explicit mapping.
Build a mapping document — typically a spreadsheet — that shows the source field, the destination field, and any transformation logic needed. For example: "Old system account 5100 (Salaries — Program) maps to new system account 5100 with program dimension HOUSING."
Data mapping errors are the primary cause of migration failures. Invest the time here.
Phase 3: Test Migration (Weeks 3–5)
Before touching the production system, run a complete test migration using a copy of your data. Import the test data into the new system and validate:
- Do all account balances match the source system?
- Do restricted fund balances reconcile?
- Do grant balances match current grant tracking?
- Can the system generate the same financial statements from migrated data as the old system?
Run the validation reports against both systems. Any discrepancy needs a root cause — either a mapping error, a data quality issue in the source, or a structural difference between systems that requires reconciliation.
Plan for at least two test migrations. The first reveals the problems; the second validates the fixes.
Phase 4: Cutover Planning (Week 5–6)
Cutover is the moment you stop using the old system and start using the new one. Choose a cutover date at a natural financial boundary — month-end or fiscal year-end is easiest. Avoid mid-month cutover if possible.
Before cutover:
- Complete all transactions in the old system through the cutover date
- Lock the old system to prevent new entries after cutover
- Perform final reconciliation of all accounts
- Export final backup of all data from the old system
Cutover weekend:
- Run the production migration
- Validate opening balances in the new system
- Confirm fund balances match
- Confirm grant balances match grant tracking documentation
Phase 5: Parallel Operations and Validation (Weeks 6–8)
Run both systems in parallel for at least one month-end close cycle. This is your safety net. If something was missed in migration, you can still access the old system for reference.
During parallel operations, reconcile every report from the new system to the corresponding report from the old system. Any discrepancy needs investigation.
After a clean parallel period, decommission the old system — but retain read access for the retention period applicable to your records (typically seven years for financial records).
Migration Timeline Template
| Week | Phase | Key Activities |
|---|---|---|
| 1–2 | Pre-Migration Cleanup | Reconcile all accounts, clear open items, document inactive funds |
| 2–3 | Data Mapping | Build account/fund/grant mapping document; document transformation logic |
| 3–5 | Test Migration | Run test import; validate balances; identify and fix mapping errors; run second test |
| 5–6 | Cutover Planning | Lock old system; run final reconciliation; execute production migration; validate opening balances |
| 6–8 | Parallel Operations | Run both systems; reconcile month-end reports; decommission old system after clean close |
The Emotional Barriers to Migration
Data migration is a technical process with a significant human dimension. Controllers and CFOs who have lived through bad migrations carry genuine trauma. It is worth addressing the emotional barriers directly.
"We'll lose historical reporting." Historical reporting depends on data structure, not software. If your historical data is migrated with correct account and fund mappings, the new system can produce the same reports from the same data. The key is the mapping document — it is your guarantee that historical data lands correctly.
"The timing is never right." There is no perfect time. Avoiding year-end and audit season is sensible; beyond that, waiting for the perfect moment is a form of avoidance. A mid-year migration with a clean test process is better than another year on software that cannot produce the reports you need.
"What if we need to go back?" The old system should remain accessible (read-only) for at least one parallel close cycle. Keeping a complete data export plus the old system on read-only access for the full retention period eliminates the risk of permanent data loss.
sherbertOSOS includes pre-built import profiles for organizations migrating from Aplos, Bloomerang, QuickBooks, Sage Intacct, and generic CSV exports. Rollback capability on test migrations means you can validate without risk — if something looks wrong in the test, reset and fix the mapping before running the production migration.
Frequently Asked Questions
How long does a nonprofit data migration take?
Typically four to eight weeks for a standard migration. Complex migrations — large databases, multiple legacy systems, significant chart of accounts restructuring — can take eight to twelve weeks. The timeline is driven primarily by the data mapping and test migration phases.
Should I migrate all historical data?
Migrate at least three to five years of full transaction detail. Older years can be migrated in summarized form (account balances by period) rather than transaction-by-transaction. All donor giving history should migrate in full regardless of age — donors expect you to know their complete gift history.
What is the biggest migration risk?
Data mapping errors, where fields from the old system do not map correctly to the new system. This is why test migrations with full validation reports are essential. A discrepancy in the test is a fixable problem. The same discrepancy discovered after go-live is an emergency.
What should I do with the old system after migration?
Keep read-only access for the applicable retention period — seven years for financial records. Export and archive a complete data backup. Do not delete the old system data until the retention period expires.
Do we need to migrate at year-end?
Year-end or month-end is easiest because it creates a clean financial boundary. Mid-year migrations are possible with careful opening balance management, but they add reconciliation complexity. If you have a choice, a fiscal year-end migration simplifies the process significantly.
The Bottom Line
The organizations that have bad migration experiences almost always share a common characteristic: they rushed the data mapping phase or skipped the test migration. Both shortcuts produce the same result — data quality problems discovered after go-live, when fixing them is expensive and disruptive.
The organizations that migrate smoothly are the ones that treat migration as a project with defined phases, dedicated staff time for validation, and a clear go/no-go decision point after the test migration.
Migration is a one-time investment. The cost of staying on inadequate software — in staff time, compliance risk, and reporting gaps — compounds indefinitely.
→ Request a demo to see how sherbertOSOS's migration process works, including pre-built import profiles and test migration validation.
Frequently Asked Questions
How long does a nonprofit data migration take?
Typically 4-8 weeks for a standard migration. Complex migrations (large databases, multiple systems, custom fields) can take 8-12 weeks.
Should I migrate all historical data?
Migrate at least 3-5 years of financial data and all donor giving history. Older data can be archived rather than migrated.
What is the biggest migration risk?
Data mapping errors — where fields from the old system don't map correctly to the new system. Test imports with validation reports catch these before go-live.
Related Articles
See sherbertOS in action
Schedule a personalized walkthrough with our team.