The first 90 days on new membership software
Most migrations do not fail at the import. They fail six weeks later, when the first renewal run goes out against a date field that imported wrong, or when half the board is still using the old thing because nobody told them to stop.
This is the order to do it in. The organising principle is that nothing which sends email or takes money gets switched on until the data underneath it has been checked by a human.
Week one — nothing goes out
- 01
Reconcile the three numbers
Total records, active members, dues outstanding. Against the old system, not against your memory of it. Do this before anything else, because every task below assumes the data is right.
- 02
Check the renewal dates, specifically
Sort by renewal date and look at both ends. A block of members all renewing on the import date means the field did not map. A member renewing in 1970 or 2087 means a date parsed wrong. These are the two errors that automated renewal reminders turn into an embarrassing all-member email.
- 03
Turn off every automated email until you have read it
New platforms ship with renewal reminders, welcome sequences and payment receipts enabled and templated in somebody else's voice. Read each one as a member would. The first automated email your members get from a new system sets what they think of the switch.
- 04
Give exactly two people admin access
You and one other. Wider access comes in week three, once you know what the roles actually do. A migration is the worst possible moment to be debugging who could see what.
Weeks two to six — go live, narrowly
- 05
Send one real email to a real list
Something ordinary and useful — a newsletter, a meeting notice. Not the announcement of the new system. You are testing deliverability and the member's experience of it, and you want to find the problems on a message that does not matter.
- 06
Take one real payment
One member, one renewal, end to end, including the receipt they get and the reconciliation on your side. Then stop and check the money actually arrived in the right account. Do this before you point every member at the payment page.
- 07
Announce it once, plainly, with a person's name on it
What changed, what they need to do (usually nothing), and who to reply to if something looks wrong. One email from a named human beats three from the system.
- 08
Freeze the old system
Read-only, on an announced date, with the date in the announcement. Running both is the most reliable way to end up with two rosters and no way to tell which is current.
Weeks seven to twelve — the parts you deferred
- 09
Turn the automation on, one thing at a time
Renewal reminders first, since that is the one with revenue attached, and a week apart from anything else so you can tell which change caused which question.
- 10
Embed the public pieces
The member directory, the calendar, the join form — into the website you already have. This is deliberately late: it is the most visible change and the one you want to make when the data behind it is known good.
- 11
Hand over to the next person
Write down what you set up and why, in the system if it will hold it, in a document if it will not. The test is the same as the spreadsheet test: could a new treasurer take this over in an evening? If the answer needs you in the room, the migration is not finished.
- 12
Go back and check the three numbers again
Ninety days of real use later, against what you would expect. This is what catches the slow errors — the ones that were not wrong at import and became wrong through use.
Free to use, adapt and hand to whoever does this job next. If something here is wrong or missing, tell us and we will fix the page — contact us.