Migration
Moving from Recharge to Shopify's native subscriptions
This is the migration most people start and abandon. Not because it is technically hard, but because nobody tells them which parts of Recharge they are about to lose until they are halfway across.
Checked 30 September 2026
The thing everyone worries about, first
Subscribers do not re enter their card. Shopify Payments vaults the payment method, and a migration recreates the subscription contract against that same vaulted card. Plan, price, interval and next charge date all carry across and map one to one. Nobody has to re subscribe and nobody gets an email asking them to.
This is worth saying plainly because it is the fear that stops the project. The risk in this migration is not losing customers at the moment of the switch. It is discovering afterwards that something you relied on does not exist on the other side.
What native Shopify subscriptions genuinely does not do
Native subscription contracts are the billing engine. They are not the product Recharge sells you. Recharge is the engine plus a large amount of merchant facing software around it, and that surrounding software is what you are actually replacing.
- No customer portal. There is a basic account page. There is nothing resembling Recharge's portal where customers pause, skip, swap products or change delivery day.
- No delivery calendar. No cut off times, no blackout dates, no lead times. Native thinks in intervals, not in delivery dates.
- No dunning. Failed payment retries are yours to design and run.
- No bundle or box building.
- Reporting is order level. Subscription specific metrics like churn and retention are not there.
If you use Recharge for weekly deliveries with cut offs and a portal where people skip a week, native alone is a downgrade and you should not do this migration without building the rest.
Where each piece ends up
| What you use Recharge for | On native contracts |
|---|---|
| Charging saved cards on a schedule | Native, and it is the solid part |
| Plan, price and interval | Native, maps one to one |
| Customer pauses and skips | Has to be built |
| Delivery day and cut offs | Has to be built |
| Failed payment retries | Has to be built |
| Swapping products in a box | Has to be built |
| Churn and retention reporting | Has to be built |
The pattern is that billing is solved and everything a customer or an operator touches is not.
When to do this and when not to
Worth it when Recharge's percentage has become a real monthly number, when you keep hitting things the settings page will not let you change, or when your delivery logic has outgrown what intervals can express.
Not worth it if you are under roughly ten thousand a month in subscription revenue. The percentage is not yet costing you enough to fund the work, and Recharge does a great deal for that money.
Not worth it either if your subscriptions are genuinely simple. Same product, fixed interval, no delivery windows. Native plus a light portal is achievable, but so is staying where you are.
Find out what your version of this costs
Send me your store, your subscriber count and what you pay Recharge now. You get back what a build would cost against what you are spending, and I will tell you if it does not pay back.