Move the charity's CRM over a weekend, and be able to move it back
A CRM migration is not like other software changes: the data has to exist in exactly one place, which forces a short, sharp cutover rather than a gradual one. This explains, for trustees with no technical background, why a weekend window and a rehearsed rollback plan are the two things worth insisting on.
A charity comes to the board with a proposal to replace its donor database. The current system is fifteen years old, only two people understand it, the supplier has stopped answering support tickets, and the finance team maintains a spreadsheet alongside it because the reports do not add up. Nobody disputes that it has to change. The question the board ends up arguing about is not whether, but how: do we move everything at once, or ease into it over a few months?
With most software, easing into it is the right answer. You put the new system alongside the old one, route a slice of the work to it, watch, then route more. Martin Fowler called this the strangler fig pattern, and it is how we prefer to replace almost anything. It is low drama and you can stop at any point.
A CRM is the awkward exception, and it is worth understanding why before you approve a plan.
The problem is the data, not the software
Your CRM is mostly a single list: people, and what each of them has done. Donations, memberships, event attendance, consent preferences, Gift Aid declarations, safeguarding notes, the fact that one particular donor should never be phoned after 6pm.
That list has to exist in exactly one authoritative place. The moment there are two copies and both can be edited, you have a reconciliation problem. A fundraiser updates an address in the new system on Tuesday. A finance officer updates the same record in the old system on Wednesday, because that is where the batch of cheques gets entered. Which one is correct on Thursday?
You can build machinery to synchronise the two. It is real work, it is fiddly, and it is machinery you will throw away as soon as the migration is done. In our experience the cost of building and operating a two-way sync for six weeks is usually higher than the cost of a well-planned weekend, and it introduces a class of bug that is very hard to explain to a trustee: records that are silently wrong rather than obviously broken.
So the incremental approach still applies, but to the surrounding parts rather than the core. You can move reporting off the old system months early. You can point the website donation form at the new system's API before cutover, or after. You can leave the retail till system alone entirely for a year. What you cannot sensibly do is run two donor lists in parallel and hope they agree.
That is the argument for a short, decisive cutover. The rest of this is about making that cutover safe.
Why a weekend specifically
Not because weekends are magic. Because you need a window in which nothing new arrives.
During the cutover, staff cannot enter data anywhere. The old system goes read-only, the data is exported, transformed and loaded into the new system, the results are checked, and only then does anyone start typing again. That freeze is unavoidable. The only question is how long it lasts and who notices.
For most charities, Friday evening to Sunday evening is the cheapest 48 hours in the week. Direct Debit collections are not being submitted, the office is shut, fundraisers are not on the phone, and finance is not running month end. A two-day freeze on a Tuesday would be genuinely disruptive. The same freeze over a weekend is mostly invisible.
But check your own calendar rather than assuming. If you run a crisis helpline, weekends are your busiest period. If you have a fundraising event weekend, or shops that report takings on a Sunday, or a campaign peak in December, the quiet window is somewhere else. One charity's safe Saturday is another's worst possible day. Ask which specific weekend, and why that one.
There is a real cost here and it should be stated plainly. Weekend work is more expensive, and it is done by people who are tired by Sunday afternoon. That is an argument for rehearsal and for a short window, not an argument for doing it on a Wednesday.
What a tested rollback plan actually means
This is the part that gets nodded through and should not be.
"We'll take a backup" is not a rollback plan. A rollback plan answers four questions, in writing, before the weekend starts:
What are the abort criteria? Decided in advance, not in the moment. For example: if the donation totals in the new system do not match the old system to the penny, we abort. If more than a small number of Direct Debit mandates fail validation, we abort. Writing these down beforehand stops a tired team at 11pm on Saturday from talking itself into "it's probably fine".
Who decides? One named person, with one named deputy. Not a committee, and not the trustees. The board's job is to insist that this person exists and has the authority to say stop.
By when? There is a point after which rolling back costs more than going forward, because real work has happened in the new system. Usually that is when staff start entering data on Monday morning. So the go/no-go decision happens on Sunday, with hours to spare, and it is a decision to open the doors on Monday, not a decision to keep watching.
How long does going back take, and has anyone timed it? This is the tested part. Restoring the old system from a snapshot, switching the web address back, re-enabling the integrations: someone should have done all of that at least once, on a copy, with a stopwatch. An untested rollback is a hope.
Rehearsal is most of the work
The weekend itself should be boring, because it will be the third or fourth time the team has done it.
A rehearsal means running the full migration against a copy of the real data, in an environment nobody uses, and checking the output. Not a sample. All of it. The checks that matter are the ones a finance trustee would recognise:
Record counts. Same number of donors, donations, memberships, mandates in and out, with any differences explained line by line.
Money. Total donations by year, matching to the penny, and matching the accounts.
Consent and preferences. Everyone who has opted out of contact is still opted out. This is the one to be most careful about. Getting it wrong is a UK GDPR problem and a reputational one, and nobody notices for weeks.
Gift Aid. Declarations intact, with their dates, so claims can still be substantiated.
Hand checks. Pick thirty real records, including the messy ones: the donor who is also a volunteer and a trustee's relative, the legacy pledge, the person with two duplicate records that were merged in 2011. Have someone who knows the data look at them on screen.
Rehearsals also surface the surprises. Old systems accumulate fields used for something other than their label. A "notes" box containing structured information the team relies on. A date field where 1900 means unknown. You want to find those on a Tuesday afternoon in advance, not at midnight during the cutover.
What to ask before you approve it
You do not need to understand the technology to hold this plan to account. Ask for these, in writing:
The specific weekend, and why that weekend is quiet for us.
A timeline for the window, with the go/no-go decision point marked, and slack in it.
The abort criteria, as numbers rather than adjectives.
The name of the person who can call it off, and their deputy.
Confirmation that a full rehearsal has been run against real data, and the reconciliation report from it.
The rollback procedure, with the measured time it took when someone actually did it.
The plan for Monday: who is on hand, what staff do if something looks wrong, and the paper or spreadsheet fallback for taking a donation if the system is unavailable for an hour.
What stays on the old system, and when the old system is finally switched off. Keeping it available read-only for a few months is cheap insurance and makes awkward historical questions answerable.
If the answers to most of those are confident and specific, the weekend is likely to pass without incident and you will hear very little about it. If the plan is a single Saturday with no rehearsal and a reassurance that there is a backup somewhere, that is the thing to push back on, and the cost of pushing back is a few weeks of delay rather than a year of cleaning up donor records by hand.