Migrating a 17-Year-Old Membership Site from aMember to Paid Memberships Pro

However, as technology evolved, aMember began to show its age. Its outdated architecture and lack of modern integrations made it increasingly difficult to maintain a high-quality membership experience. It was time for an upgrade—and Lisa chose Paid Memberships Pro (PMPro) as her new platform.

As it happens, we are Paid Memberships Pro developers and have a dedicated listing on the PMPro website. It's an awesome plugin run by a fantastic team so we love working with it. We also have very extensive experience doing all kinds of different migrations and really enjoy helping customers with them.

So we were pleased and excited when Lisa chose us to assist her in this migration over to PMPro.

🔗 Related: Our Membership Migration Services

---

The Initial Challenges

Lisa’s site had over 1,000 active subscriptions at the time of migration. One of the first issues we encountered was that PMPro no longer supported the legacy payment gateways she was using: PayPal Standard and PayFlow.

As of version 3.4, PMPro officially dropped support for these gateways (along with others that didn’t use modern API-based communication). This decision makes sense—API-less gateways are outdated and more prone to failure or rejection, especially with stricter payment processor standards today.

We attempted to re-enable PayFlow support in PMPro using a custom add-on. While technically successful, most payments were still being rejected—exactly the issue that led Lisa to consider leaving aMember in the first place.

---

From PayFlow to Stripe

Many people don’t realize that PayFlow is actually part of the PayPal ecosystem. Fortunately, Stripe offers a way to migrate customer objects (including saved payment details) from PayPal to Stripe.

To do this, Stripe requires a list of PNREFs (for PayFlow) or Transaction IDs (for PayPal Standard). The Stripe account holder needs to submit this information via Stripe’s official migration request form:

🔗 Request a Data Migration from Stripe

While the process may take up to two weeks, in our case, Stripe completed the migration in just 3–4 days.

---

Recreating Subscriptions in Stripe

It’s important to note: Stripe only migrates customer objects, not active subscription records. This meant we needed to manually recreate the subscriptions in Stripe using the data we extracted from aMember.

🔗 Related: Recreating Subscriptions in Stripe

Luckily, Stripe’s system made this process relatively smooth. With the customer data in place and our records from aMember, we were able to re-establish active subscriptions without requiring users to re-enter their payment details.

Here is a quick video where you'll be able to find the Stripe Subscription migration function:

You'll be downloading a Migration template, such as the file bellow, where you'll have to populate the rows with your subscription data from your members.

You'll have to extract your data from your membership platform and merge the customer data with the customer objects created on Stripe. In this case I did use my MySQL tables with a few mysql queries to get this done, but if you're not tech savvy, you can always just use Google Spreadsheets or AirTable as well.

Please note: All Date & Time fields needs to be converted to Unix timestamp. You should use the Developer tools or create a sandbox to test your data before recreating them in your live environment in Stripe.

Hint: You should check out this article by my teammate Edin on a similar topic: How to Update the Price of Existing MemberPress Subscriptions

---

Recreating Subscriptions in Paid Memberships Pro (PMPro)

Before importing subscriptions, it's crucial to connect Stripe to PMPro. This can be done easily by navigating to:

WordPress Dashboard → Memberships → Settings → Payment Gateway.

Once Stripe is properly connected, the next step is to import your subscriptions into PMPro.

Thankfully, the team at PMPro has created a helpful add-on called Import Members from CSV. This tool allows you to bulk import member records using a CSV file.

After installing and activating the add-on, you’ll find a new menu item under Users → Import Members.

Since our users were already registered in WordPress, we didn’t need to enable the option:

“Send new users an email with their username and a link to reset their password.”

Instead, we enabled the following recommended settings:

✅ “Process the import in batches using AJAX.”

✅ “Update existing users when a matching username or email address is found.”

PMPro also provides a sample CSV template to help format your data correctly. You’ll need to populate this file with your own membership details—such as level IDs, billing amounts, billing cycles, and other relevant data.

If you're migrating from aMember and have access to your MySQL database, here’s a handy SQL query you can use to export your member data. Be sure to update the membership level IDs, billing terms, and other fields to match your PMPro setup:

SELECT 
  u.`login` AS user_login, 
  u.email AS user_email,
  '' AS user_pass,
  u.name_f AS first_name,
  u.name_l AS last_name,
  CONCAT(u.name_f, ' ', u.name_l) AS display_name,
  'subscriber' AS role,
  '1' AS membership_id,
  '' AS membership_code_id,
  '49.95' AS membership_initial_payment,
  '49.95' AS membership_billing_amount,
  '1' AS membership_cycle_number,
  'year' AS membership_cycle_period,
  '' AS membership_billing_limit,
  '' AS membership_trial_amount,
  '' AS membership_trial_limit,
  'active' AS membership_status,
  a.begin_date AS membership_startdate, 
  a.expire_date AS membership_enddate,
  d.value AS membership_subscription_transaction_id,
  'paypalexpress' AS membership_gateway,
  a.invoice_id AS membership_payment_transaction_id,
  '' AS membership_affiliate_id,
  a.begin_date AS membership_timestamp
FROM 
    am_user u
INNER JOIN 
    am_access a ON u.user_id = a.user_id
LEFT JOIN 
    am_data d ON (d.`table` = 'invoice' AND d.id = a.invoice_id AND d.`key` = 'paypal-profile-id')
INNER JOIN 
    ppexport p ON p.`Col 1` = d.value
WHERE 
    a.product_id = 1 
    AND (a.expire_date >= CURRENT_DATE OR a.expire_date IS NULL)
    AND d.value IS NOT NULL
ORDER BY 
    u.user_id 
LIMIT 2000;

This will give you a good starting point for building your CSV file and completing the import into PMPro.

---

PayPal Standard

At the time of writing this article, Lisa is still using PayPal Standard on her website. This is a decision made by the client, and while we support it, we are also actively considering migrating her to Stripe.

Here are some key points you should be aware of:

Hardcoded IPNs

Subscriptions created via PayPal Standard in aMember have their IPN (Instant Payment Notification) URLs hardcoded into each individual subscription profile. This means that even if you update the IPN URL in your PayPal account to point to the PMPro endpoint, it won’t work—because the original IPN saved in each subscription takes precedence and cannot be updated. This is one of the major limitations of PayPal Standard (and frankly, one of the reasons we’re not big fans of it).

How do we bypass this limitation?

Just tick the following configurations in aMember:

PayPal Standard vs. PayPal Express

It’s important to understand that PayPal Standard and PayPal Express are entirely different gateways. PayPal Standard relies solely on the IPN system, while PayPal Express uses API-based communication. They are not interchangeable—you cannot manage Standard subscriptions through the Express gateway, and vice versa. Don’t waste time trying; it simply won’t work.

Enabling PayPal Standard on PMPro

As of version 3.4, Paid Memberships Pro (PMPro) has officially dropped support for PayPal Standard. However, if you still need to use it, there’s a workaround:

First, install PMPro version 3.3.3, the last version that supports PayPal Standard.

Configure your gateway settings with the correct PayPal credentials.

Once that’s done, you can safely upgrade PMPro to the latest version (currently v3.4.7). The PayPal Standard option will remain active and available in the payment gateway dropdown, even though it’s no longer officially supported.

---

The Next Challenge

Lisa’s site had been running for 17 years, with over 300 pages—most of which were protected and accessible only to members. While protecting posts using categories and tags is straightforward, pages don't support this by default, which meant each page would have to be protected manually—a time-consuming task.

To solve this, we developed a custom plugin that adds category and tag support to pages. This allowed Lisa to protect her pages just like posts—by simply assigning them to a protected category.