Preserving Subscriptions and Payments During Migration

If you have active subscriptions, payment plans, or recurring billing, migrating CRMs or payment processors requires careful planning to avoid billing disruptions. This guide explains what transfers, what doesn’t, and how to preserve billing continuity.

What Transfers vs What Doesn’t

Understanding what persists through a migration and what doesn’t is crucial for planning.

✅ What AccessAlly Migration DOES Preserve

• Member accounts: WordPress users and login credentials
• Course progress: Lesson completion, quiz scores, certificates
• Tags and access levels: Membership tier assignments
• Page permissions: What content each member can access
• Custom field data: Information stored in WordPress custom fields

❌ What Migration Does NOT Preserve

• Active billing relationships: Ongoing subscriptions in your payment processor
• Saved payment methods: Credit card details stored in old system
• Payment plans in progress: Which payment of a 6-month plan a member has completed
• Billing history: Transaction records and payment logs
• Failed payment retry schedules: Dunning sequences from old CRM
• Subscription end dates: When renewals are due

Scenario 1: Using CRM Order Forms (Keap, Ontraport)

If you currently use Keap or Ontraport order forms with active subscriptions, switching CRMs is complex because billing is tied to your CRM.

What Happens to Active Subscriptions

If you switch to a different CRM (ActiveCampaign, ConvertKit, etc.):

• ❌ Your new CRM doesn’t have native payment processing
• ❌ Active subscriptions remain in Keap/Ontraport
• ⚠️ You must decide: keep billing there, or migrate billing separately

Option 1: Keep Billing in Original CRM (Recommended for Active Subscribers)

How it works:

1. Active subscribers stay on Keap/Ontraport billing
2. New members purchase through AccessAlly order forms + Stripe (or WooCommerce, ThriveCart, etc.)
3. Use webhooks to sync subscription status from Keap/Ontraport to your new CRM
4. Gradual transition: as old subscriptions cancel/renew, members move to new system

Pros:

• ✅ No billing disruption for active subscribers
• ✅ No risk of losing subscribers during migration
• ✅ Members don’t need to re-enter payment information

Cons:

• ❌ Maintain two systems during transition (can take months/years)
• ❌ More complex webhook setup
• ❌ Continued costs for old CRM (though you can downgrade to minimum plan)

Option 2: Migrate Billing to New System

How it works:

1. Set up AccessAlly order forms with Stripe (or choose WooCommerce, ThriveCart, etc.)
2. Notify members their billing will change
3. Provide incentive for members to re-subscribe (discount, bonus content, etc.)
4. Members re-enter payment information on new order forms
5. Cancel old subscriptions as members migrate

Pros:

• ✅ Clean break from old CRM
• ✅ Everyone on same billing system
• ✅ Simpler long-term management

Cons:

• ❌ High risk of subscriber churn (expect 10-30% won’t migrate)
• ❌ Negative member experience (re-entering payment info is frustrating)
• ❌ Requires active member communication campaign
• ❌ Lost billing history

Option 3: Stripe Billing Portal (If Using Stripe Backend)

If your Keap/Ontraport uses Stripe as the payment processor behind the scenes:

1. Export subscription IDs from Keap/Ontraport
2. Those subscriptions exist in your Stripe account
3. Use Stripe Billing Portal to let customers manage their subscriptions
4. Connect new system (AccessAlly order forms, WooCommerce, etc.) to same Stripe account
5. Webhook from Stripe to new CRM syncs subscription status

Note: This requires technical expertise to set up webhook handling. Consider hiring a developer.

Scenario 2: Using AccessAlly Order Forms or WooCommerce

If you already use AccessAlly order forms with Stripe, or WooCommerce, or another third-party payment processor:

Switching CRMs (e.g., ActiveCampaign → ConvertKit)

What happens to subscriptions:

• ✅ Nothing! Billing is separate from your CRM
• ✅ Subscriptions continue in Stripe/WooCommerce/etc.
• ✅ You only need to update webhook destinations

Steps:

1. Migrate contacts from old CRM to new CRM
2. Recreate tags in new CRM (must match exactly)
3. Update webhook URLs in Stripe/WooCommerce to point to new CRM
4. Update AccessAlly CRM integration settings
5. Test purchase flow with new CRM connection

Advantage: Separating payment processing from email marketing makes CRM migrations much simpler.

Switching Payment Processors (e.g., WooCommerce → ThriveCart)

What happens to subscriptions:

• ❌ Active subscriptions remain in old processor
• ⚠️ Must migrate subscriptions or run parallel systems

Steps:

1. Set up new payment processor (ThriveCart, SamCart, etc.)
2. Connect new processor to AccessAlly via webhooks
3. Test purchases grant correct access
4. Decide on migration strategy (parallel systems vs member migration)

See Parallel Systems Strategy below for details.

Contact ID Mismatches: Critical Pre-Migration Step

Contact ID mismatches are a common cause of broken subscriptions after migration. This happens when:

• A member changes their email address
• The email in your CRM doesn’t match the email in WordPress
• The email in your CRM doesn’t match the email in your payment processor

Why This Causes Problems

When a subscription payment processes:

1. Payment processor sends webhook with customer email
2. AccessAlly looks up WordPress user by email
3. If emails don’t match, access isn’t granted/removed properly
4. Member either loses access they paid for, or keeps access after cancelling

How to Audit for Mismatches BEFORE Migration

Step 1: Export data from all systems

• Export contacts from CRM (including email)
• Export WordPress users (email)
• Export active subscriptions from payment processor (customer email)

Step 2: Compare emails across systems

• Use spreadsheet to match records by email
• Flag any where CRM email ≠ WordPress email
• Flag any where payment processor email ≠ WordPress email

Step 3: Resolve mismatches

Option A: Update WordPress email to match billing email

• Safer option – preserves billing relationship
• Member uses billing email to log in after migration
• Send password reset email to new email address

Option B: Update billing email to match WordPress email

• Requires updating subscription in payment processor
• May require customer verification (credit card security)
• Risky – could accidentally cancel subscription

Option C: Manual mapping

• Keep separate record of which WordPress user maps to which CRM contact
• Manually update tags when subscription events occur
• Not scalable, error-prone

💡 Pro Tip: Always use the billing email as the “source of truth.” Update WordPress and CRM to match what’s in the payment processor.

Payment Plans and Finite Installments

If you offer payment plans (e.g., “Pay $100/month for 6 months”), migration is particularly complex.

What Doesn’t Transfer

The payment processor tracks:

• Which payment # the customer is on (e.g., payment 3 of 6)
• When the next payment is due
• When the plan completes

After migration:

• ❌ This progress doesn’t transfer to new system
• ❌ New system doesn’t know customer is on payment 3 of 6
• ⚠️ Risk: Customer could be charged again for completed payments

Auditing Payment Plans for Refunds

If customers received refunds for any payment in a plan, you need to recalculate what they actually owe:

Example scenario:

• Customer purchased 6-payment plan ($100/month = $600 total)
• Completed payments 1, 2, 3 ($300 paid)
• Payment 4 failed and was refunded
• Completed payments 5, 6 ($200 more paid)
• Total paid: $500 (not $600)
• Customer still owes $100 but plan shows “complete”

Audit process:

1. Export all payment plan transactions from payment processor
2. Filter for refunded/failed payments
3. For each refunded payment, calculate actual amount paid vs. plan total
4. Create list of customers with incomplete payment plans
5. Contact these customers to collect remaining balance before migration

Migrating Active Payment Plans

Option 1: Let plans complete in old system (Recommended)

• Keep payment plans running in original processor until completion
• Only migrate customers after their plan finishes
• Simplest approach, no billing disruption

Option 2: Calculate remaining balance and migrate

• Calculate what customer still owes (e.g., 3 of 6 payments remaining = $300)
• Create new payment plan in new system for remaining amount
• Cancel old payment plan
• Customer continues on new plan
• ⚠️ Risk: Errors in calculation could overcharge or undercharge

Option 3: Offer discounted one-time payment

• Calculate remaining balance
• Offer customer option to pay remainder as one-time payment with discount
• Example: “$300 remaining, but pay $250 now to complete your plan”
• Converts payment plan to one-time purchase
• Simplifies migration, improves cash flow

Parallel Systems Strategy

Running old and new billing systems in parallel during transition is often the safest approach.

How Parallel Systems Work

1. Keep old system active – Existing subscribers stay on old billing
2. Launch new system – New members purchase through new system
3. Webhook both systems – Both old and new send events to AccessAlly/CRM
4. Gradual transition – Over months/years, everyone migrates to new system

Example Setup

Old system: Keap order forms → Keap → Webhook → ActiveCampaign → AccessAlly
New system: AccessAlly order forms → Stripe → Webhook → ActiveCampaign → AccessAlly

Both systems:

• Add/remove same tags in ActiveCampaign
• AccessAlly grants access based on tags (doesn’t care which system added them)
• Members don’t notice difference in access

Communication Strategy

For existing subscribers:

• “Your billing stays exactly the same – no action needed”
• “When your subscription renews, you’ll have the option to update to our new system”
• “Access to your content is not affected”

For new purchasers:

• They only see new system
• Unaware old system exists
• Standard purchase flow

Transition Timeline

Month 1-3: Set up new system, test thoroughly
Month 4: Launch new system for new purchases, keep old active
Month 4-12: As old subscriptions come up for renewal, offer migration incentive
Month 12+: Gradually wind down old system as subscribers migrate

💡 Pro Tip: Budget 12-24 months for complete transition if you have many active subscribers. Rushing causes churn.

Failed Payment Handling During Migration

Failed payments must be handled properly during migration to avoid giving away free access.

If Old CRM Handled Failed Payments (Keap, Ontraport)

Before migration:

• CRM automatically retries failed payments
• CRM sends dunning emails
• CRM removes tags when subscription cancelled

After migrating to CRM without native billing:

• ❌ New CRM doesn’t handle failed payments
• ⚠️ You must build this functionality

Solution: Stripe Webhooks + Automation

1. Stripe sends webhook when payment fails: invoice.payment_failed
2. Webhook triggers automation in your CRM
3. CRM sends “payment failed” email to customer
4. After X days, if still not paid, remove access tags
5. Stripe handles retry logic (configured in Stripe dashboard)

Required webhooks from Stripe:

• customer.subscription.created – Add tags
• customer.subscription.deleted – Remove tags
• invoice.payment_failed – Notify customer
• invoice.payment_succeeded – Confirm payment

Grace Period Considerations

Should you keep access during failed payment retry period?

Option A: Immediate access removal

• Remove tags as soon as payment fails
• Member loses access immediately
• Strong incentive to update payment method
• ⚠️ Poor experience if payment failed due to bank error, not intent

Option B: Grace period

• Keep access for 7-14 days during retry attempts
• Only remove tags if payment still failed after retries
• Better member experience
• ⚠️ Risk of giving away access if automation fails

💡 Recommended: Use 7-day grace period matching Stripe’s default retry schedule.

Testing Your Migration

Before migrating billing for real members:

1. Create test subscriptions in old and new systems
2. Verify access granted correctly in both systems
3. Test failed payment – Use Stripe test card that fails, verify tags removed
4. Test cancellation – Cancel subscription, verify access removed
5. Test upgrade/downgrade – Change subscription level, verify tags update
6. Test refund – Process refund, verify access removed
7. Document timing – How long between webhook and access change?

Run tests on staging site first, never on live site.

Questions?

For questions about payment processors or billing systems, connect with those providers directly (Stripe, WooCommerce, ThriveCart, etc.).

For questions about CRM features, connect with your CRM’s support team.

For general AccessAlly questions unrelated to migrations, contact our support team.

Consider hiring a developer if you have complex subscription structures or are uncomfortable with webhook configuration. This is a complex area where expert help is worthwhile.