Planning a membership site migration
A membership site holds two kinds of things: pages, and records about people. Pages are the easy part. Members, their status, their renewal dates, their payments, and their event registrations are what make a migration go wrong. This is the order we plan one in.
Inventory what you have
- Membership types and their prices, including any discounts, gift memberships, or fee assistance.
- Member statuses as the old system defines them: active, in grace period, lapsed, pending. Write down what each one means in practice, because the new system will have its own definitions.
- Renewal dates and how they are calculated: a fixed month for everyone, or a year from each member's join date.
- Payment history, and where recurring payments are set up.
- Events, registrations, and any member-only prices.
- The directory: which fields are public, which are for members only, and who can edit them.
- Staff roles: who can see what, and who can change it.
- Every address that appears in an old email or a printed flyer, especially renewal and registration links.
Decide before you move
How much history moves? Most organizations move current members, recently lapsed members, and a fixed number of years of payments. Older records can go to an archive export that staff can search.
Can logins move? That depends on how the old system stores passwords. If they cannot move, plan a password-reset email to every member and a short script for staff to use when members call that week.
Can automatic renewals move? Card details are held by the payment processor, not by your website. If you are changing processors, ask both whether they can transfer stored payment methods. If they cannot, members on automatic renewal will have to enter a card again, and you need to tell them before their renewal date.
Pick the week
Do not launch in renewal month or while conference registration is open. Work back from the quietest month in your year. Lower the time-to-live on your DNS records a few days before the switch so the change takes effect quickly. Agree on a content freeze, the period when staff stop editing the old site, and keep it as short as the final import allows.
Rehearse it
Run the full import at least once on a copy of the new site before launch. Count members by status in the old system and in the new one, and find out why any number differs. Have a staff member who knows the members check twenty records by hand: a long-time member, a lapsed one, someone on fee assistance, a board member, someone with two memberships. Test a renewal, an event registration at the member price, and a directory edit, on a phone.
Launch and the first season
On launch day, run the final import, check the counts again, turn on the redirects from old addresses, and test a real payment. Then watch the first renewal cycle closely: abandoned renewals, calls to the office, and members who show as lapsed and should not. Most migration problems surface then, not on launch day.
Checklist
- A written list of membership types, statuses, and what each status means.
- A decision on how many years of history move, and where the rest is archived.
- An answer from the processor about stored payment methods.
- A plan for passwords that cannot move.
- A launch week outside renewal and registration season.
- One full rehearsal, with counts compared and twenty records checked by staff.
- A redirect list for every renewal and registration link in old emails.
- Someone assigned to watch the first renewal cycle.
If you want help with any part of this, describe the system you have now. The migration service and membership service pages describe how we do the work.