Migrating To A Different Membership Plugin: Is It Worth The Hassle?

You might be at a point now where you’re unhappy with your membership plugin and are seriously considering moving to a different solution. But quite naturally, you have some doubts.

Will this new platform really work better? Will I be trading one set of issues for a whole ‘nother set of issues? What if I can’t integrate with XYZ? Won’t my members’ billing get all messed up and out of sync?

I’ve now participated in several migrations from one membership plugin to another. And when I’m asked by clients to assess whether or not a migration is worth doing, I’ll generally suggest one of three possibilities:

A) Stay with the current plugin.

B) Keep your current members on the current plugin and run another membership plugin in parallel to accept new members (and to enable you to do the things your current plugin doesn’t allow for.)

C) Switch completely from your current membership plugin to another plugin.

Since each situation is different, it’s impossible for me to provide a blanket recommendation on what to do in your particular case. But one important point to consider before anything else is:

>> Are your members being charged on a recurring basis or was their membership a one-off fee? 

One of the biggest difficulties in migrating to a new membership plugin is making sure that your members will continue getting billed on the correct schedule and that their access to the members area will be accurately extended (or not) based on whether they’ve paid that month (or not).

So if you have any recurring billing happening on your site, it automatically complicates the migration by an order of magnitude. Not only do you have to make sure that instant payment notifications (IPNs) are forwarded to the new membership script and are being intercepted correctly (which may require writing .htaccess redirect rules) but you also have the problem of importing members with the correct access start and end dates.

MemberMouse, for instance, doesn’t have the ability to export a user’s access start/end dates. So if you have hundreds or thousands of members, you have to manually go through and note the start date/end dates for each member before importing them into a new system. Otherwise, you’ll have to give everybody access on the day of import, with the result that some members will get more days of access than they paid for, and others will get less.

Another example:

If your current membership plugin (e.g. MemberMouse) connects to your email autoresponder (like Aweber) via API, and your target membership plugin adds subscribers with an email parser (e.g. DAP), you’ll lose the ability to remove subscribers from a list upon membership cancellation, and you also won’t be able to turn off confirmed opt-in.

If you deliver your paid content via Aweber, as was the case for one of my clients, this could be a deal breaker (since not being able to remove cancelled members from an Aweber list would result in that member continuing to receive paid content after stopping his payments.)

There are several more niggling technical issues that can pop up and make your migration suddenly unfeasible. And even if you know your membership plugins like the back of your hand, it’s unlikely that you’ll be able to anticipate all issues if and before they materialize.

For these reasons and more, I generally suggest saving ‘full’ migration from one membership platform to another as an absolute last resort.

*A caveat: if you have a very simple membership site setup with few (or no) 3rd party integrations and the members are not being billed on a recurring basis, then switching plugins can actually be done pretty smoothly. But again, this is assuming that no unforeseen technical hurdles appear.

Running Two Membership Plugins At The Same Time:

Another potential solution to your membership plugin woes is to install a new membership plugin to run side by side with your current membership plugin.

This way your legacy members won’t experience any interruption to their access or billing. That is, in an ideal world. I say “in an ideal world” because this is assuming that the new plugin won’t conflict with the old plugin. And it might.

For example, one of my clients uses aMember, which is a decent membership script overall. However, we’ve found that certain tasks that should be simple, such as embedding signup forms into WordPress pages or customizing templates, are inordinately difficult by the very nature of how aMember is coded, and require extensive customization work, which equals time and money.

We’re toying with the idea of keeping aMember active to serve legacy members but using DAP to accept new members.

This, too, is not without its challenges. It means we’d have to create a duplicate member’s area, otherwise both aMember and DAP will be trying to protect the same content. It also means double the administration tasks. It also means twice the complexity when troubleshooting bugs (is aMember causing it or DAP? Gotta check both…) You get the picture.

>> Also, put this in your pipe and smoke it: some membership plugins conflict with one another.

Off the top of my head I know that OptimizeMember and MemberMouse don’t play nice. OptimizeMember causes WordPress to ignore the member’s home page for MemberMouse users. Which means that if you log in to your MemberMouse member’s account, you won’t get redirected to the correct member’s home page based upon your membership level, which would probably annoy you.

Conflicting plugins:

OptimizeMember + MemberMouse

Non-conflicting plugins (based on what I’ve seen; YMMV):

DAP + MemberMouse

DAP + OptimizeMember

DAP + ZaxaaMember

So as you can see, neither the option of full migration, nor running two membership scripts in parallel, is particularly appealing. That leaves the third option: keeping the status quo with your current plugin.

I understand that this can be a frustrating “solution”. Your membership plugins sucks and you have no choice but to stay on it. I’ve had several clients choose to remain with a sub-par platform that stifled their ability to grow and market their site simply because the cost, time, and inconvenience to their members involved in migration was too great.

I wish I had a panacea to offer for this kind of situation. But it doesn’t exist. I can, however, provide a pre-migration assessment that includes general suggestions to improve your membership site. Please contact me for this.

I hope this serves as a stark reiteration of how important it is to choose the right software for your membership site from day one, even if it means spending a few extra bucks.