If you run a subscription-based ecommerce business, few operational decisions feel scarier than switching payment processors. Your recurring revenue depends on stored card data working flawlessly, month after month, without your customers ever thinking about it. So when a merchant asks, “Why can’t we just copy and paste our customers’ card info from our old processor into the new one?” — it’s a completely reasonable question. It also reveals just how much confusion exists around what actually happens behind the scenes of a payment migration.

The short answer is that you can’t copy and paste card data because of security architecture — and, frankly, because it’s good business for processors to make switching hard. This guide walks through exactly what’s happening under the hood, the four real migration paths available to you, and how the major platforms actually handle this process in practice. Whether you’re a solo founder who has never touched a PCI compliance document or a finance lead evaluating a six-figure processor switch, this is meant to take you from the fundamentals through to the fine print.

Why You Can’t Just Move the Card Numbers Yourself

Every payment processor stores customer card data inside an encrypted vault and assigns each stored card a token — a random string that represents the card without exposing the actual number. When your checkout page charges a returning customer, your system isn’t sending a card number at all; it’s sending that token back to the processor, which matches it to the real card data sitting safely in their vault.

The problem is that these tokens are proprietary. A token generated by Stripe means nothing to PayPal or Adyen — it’s essentially a random string, unrecognizable outside the vault that created it. There’s no universal translation layer. This isn’t a technical oversight; it’s by design. The entire architecture of card tokenization exists to keep raw card numbers out of circulation and reduce the number of parties who touch sensitive data. It also, not so coincidentally, creates a natural form of vendor lock-in. The harder it is to move your token vault, the harder it is to leave.

So when you decide to switch — say, moving from Stripe to Adyen — you’re not moving data in the traditional sense. You’re going through a formal process called Token Migration, and its most critical piece is Token Mapping: your new processor takes your existing tokens, links each one to a newly generated token on their own system, and pulls over the metadata that makes subscriptions work — billing cycles, rebill dates, currency, and so on. It requires coordination between both providers, but it’s the closest thing to a seamless transition without forcing customers to re-enter their card details.

A Different Animal: Merchant of Record Platforms

If your business runs on a Merchant of Record (MoR) model — platforms like FastSpring or Paddle — the calculus changes. An MoR isn’t just processing your payments; they’re legally the seller of your product. That means they own your entire billing and tax infrastructure, not just your card tokens.

Leaving an MoR is called offboarding, and it’s less like a data transfer and more like untangling your business from someone else’s legal and financial umbrella. It’s absolutely possible, but it involves far more moving parts than a standard token migration — new tax registrations, updated terms of service, and a full re-architecture of how transactions are legally structured. If you’re on an MoR model, budget significantly more time and legal review for a switch.

Before you initiate any migration, regardless of model: review your current processor’s contract terms, understand your data export rights, and get a clear answer from your new processor about exactly what migration support they provide. This single step prevents most of the headaches described below.

Path 1: Direct PCI-to-PCI Transfer

This is the industry-standard approach and the one most merchants will encounter first. A Direct PCI-to-PCI Transfer is a secure, server-to-server handoff of encrypted card data directly between your old processor’s vault and your new provider’s vault.

The golden rule governing this entire process is the compliance boundary: raw card numbers must never touch your servers, your systems, or — obviously — a spreadsheet. If at any point in a migration conversation someone suggests exporting a CSV of card numbers, that’s a compliance red flag. The whole point of PCI-to-PCI transfer is that it happens entirely between the two processors’ secure environments, invisible to you.

Here’s what that process looks like in practice:

1. You request a data export from your current processor, formally authorizing the release of your card vault.
2. Both providers verify each other’s PCI compliance, confirming they’re each certified to handle the transfer securely.
3. The encrypted card data transfers directly between the two vaults — never passing through your infrastructure.
4. Your new processor re-vaults the data, storing it in their own encrypted environment and issuing brand-new tokens.

Once complete, your new provider hands your tech team a token mapping file — essentially a lookup table connecting each customer’s old token to their new one. Your systems update your customer records to reference the new tokens, and subscriptions continue billing without interruption.

A word of caution: a raw PCI transfer isn’t always as clean as it sounds. While the card data itself moves securely, your team will often need to manually recreate rebill schedules, dunning rules, and subscription metadata inside the new system — none of that logic transfers automatically. It also isn’t fast. Expect the full process to take two to six weeks, and be prepared for some legacy processors to charge an export fee simply to release your own data.

Path 2: Network Token Portability

If a PCI-to-PCI transfer feels like moving a house, Network Token Portability is closer to owning your address outright. Instead of a token being issued by your payment gateway, a network token is issued directly by the card networks — Visa, Mastercard, and others. That token is tied to your business, not to whichever processor happens to be running your checkout at the moment.

The mechanism that makes this possible is the Token Requestor ID (TRID) — think of it as a master key that determines who actually controls your tokenized card data. There are two ways a TRID gets established, and the difference between them matters enormously if you ever plan to switch providers again.

Processor-Owned Tokens. Most major providers — Stripe and Braintree among them — automatically generate network tokens on your behalf as part of standard checkout flow. This is genuinely useful: network tokens tend to boost approval rates because card networks trust them more than legacy gateway tokens. The catch is ownership. Since the processor holds the TRID, it’s still their key, not yours. If you switch away from them later, you’re right back to a full data migration that depends entirely on your outgoing processor’s willingness to cooperate.

Merchant-Dedicated Tokens. In this setup, your business — not your processor — owns the TRID. That ownership is the entire value proposition: you can switch processors, or even route transactions across multiple providers simultaneously, without any data migration at all. Your tokens simply travel with you because they were never tied to a specific processor in the first place.

The trade-off is setup time. Because merchant-dedicated tokens are established directly with the card networks rather than through a processor’s existing infrastructure, getting set up typically takes a few weeks longer than accepting the default processor-owned option. For merchants who expect to change processors more than once, or who want leverage in future contract negotiations, that upfront time investment tends to pay for itself.

Path 3: Universal Vaults

For merchants who want maximum long-term control over their payment stack, a universal vault is the most architecturally independent option. Rather than storing card data inside any single processor’s vault, a universal vault — services like Spreedly, Very Good Security, or Basis Theory are the common names here — sits as a neutral, secure middleman between your business and whichever processors you use.

Here’s the mechanics: when a customer enters their card details at checkout, that data is captured and stored directly in your universal vault — not in any processor’s system. The vault generates a reusable token, and every time a payment needs to run, it passes the necessary card data to whichever processor you’ve configured for that transaction.

The advantage is flexibility that borders on total: because your card data lives in a neutral space rather than inside a specific processor’s walled garden, you can switch processors — or route different transactions to different providers simultaneously — without ever running a migration again. Your systems simply point to a different processor through the vault’s existing infrastructure. No re-tokenization, no PCI transfer request, no waiting weeks for an export.

That flexibility comes at a cost, both literally and operationally. Universal vaults add their own software fees on top of your processing costs, and they require real technical integration work upfront — this isn’t a plug-and-play setup. The offsetting benefit is that the vault absorbs most of your PCI compliance burden, since customer card details are captured by the vault before they ever touch your own servers.

This path tends to make the most financial and strategic sense for scaling businesses, or any merchant who anticipates working with multiple payment providers — for redundancy, geographic coverage, or cost optimization — rather than staying locked to one.

Path 4: Passive Migration (When You Can’t Get a Direct Transfer)

Sometimes a direct transfer simply isn’t on the table. A legacy processor may refuse to release your data outright, or attach an export fee steep enough to make the whole thing impractical. In those cases, merchants fall back on passive migration, also called on-the-fly re-tokenization.

Instead of moving your entire card vault in one motion, you keep your old processor active for existing subscribers while routing every new customer to your new provider. As existing customers naturally return to your site — updating their profile, or purchasing an add-on — their payment details get captured fresh and stored in the new system. Over time, your customer base gradually shifts from the old processor to the new one.

The upside is that it requires no cooperation from an uncooperative legacy processor. The downside is real, and it’s specifically about churn. Cards that expire or get replaced during the transition window will eventually force affected customers to manually re-enter their billing information — and any time you force an active subscriber to take action, some percentage will simply let the subscription lapse instead. Industry benchmarks put that passive cancellation rate at roughly 10% to 25% of affected subscribers. For a business with meaningful recurring revenue, that’s not a rounding error.

There’s also the operational tax of running two payment systems side by side for the duration of the transition: split reporting, duplicate support workflows, and extra administrative overhead that your finance and support teams will feel every day the migration is in progress.

One meaningful way to soften this risk is to layer in Account Updater services from Visa and Mastercard. These tools automatically refresh expired or reissued card numbers behind the scenes — without requiring the customer to do anything — helping you preserve recurring revenue even as the underlying migration drags on.

How the Major Platforms Actually Handle This

Policy and practice can diverge quite a bit from provider to provider. Here’s a realistic picture of what to expect from the platforms merchants most commonly deal with:

• Stripe offers a free, self-serve export request directly from your dashboard, along with complimentary engineering support to help you import token files if you’re migrating in from a competitor.
• Braintree and PayPal were early pioneers of data portability in this space, and standard PCI-to-PCI transfers tend to be relatively straightforward in both directions — importing and exporting.
• Adyen, as an enterprise-grade platform, fully supports bulk exports, but expect a highly structured process that requires working directly with an assigned account manager rather than a self-serve dashboard flow.

A few notable edge cases worth flagging specifically:

• Merchants of Record like Paddle will generally cooperate with card file export requests, though remember the earlier caveat — offboarding from an MoR involves more than just the card data.
• Authorize.Net supports PCI exports, but the process runs through manual paper forms, strict compliance verification, and often a export fee of $500 or more.
• Helcim offers a guided, concierge-style migration experience, which can be a meaningful advantage for merchants without a dedicated technical team.
• Shopify Payments handles migrations case-by-case. Because Shopify controls the underlying Shop Pay network, they retain discretion to restrict raw token exports — something to factor in heavily if you’re building on Shopify Payments with a future migration in mind.

Planning Your Move

Switching payment processors doesn’t have to put your recurring revenue at risk — but it does require choosing the right path for your business’s size, technical resources, and timeline. A direct PCI-to-PCI transfer works well for most merchants making a one-time, deliberate switch. Network token portability, particularly merchant-dedicated tokens, is worth the extra setup time if you value long-term independence from any single processor. Universal vaults make the most sense for businesses that expect to route payments across multiple providers on an ongoing basis. And passive migration, while riskier for churn, remains a viable fallback when a legacy processor simply won’t cooperate.

Whichever path fits your business, the same advice applies before you make any move: review your current processor’s export policies in detail, confirm what your contract actually allows, and get specific commitments from your new processor about the migration support they’ll provide. A little diligence upfront is what separates a smooth, invisible transition for your customers from a churn event that shows up in your revenue numbers for months afterward.

Token Migration Checklist

If you’re preparing for a standard PCI-to-PCI token migration, here’s what to have in place — broken down by what you need internally, what to request from your outgoing processor, and what to coordinate with your incoming processor.

Internal Prep (Before Contacting Anyone)

• Current subscriber count and total token/card count in your existing vault
• List of active subscription plans, billing cycles, and currencies in use
• Copy of your current processor contract — check for exit clauses, data ownership language, and export fees
• Confirmation of whether you’re on a standard processor or a Merchant of Record model (changes the whole process)
• Internal technical contact (dev/engineering) who can handle API integration and token mapping on your end
• Backup export of non-sensitive customer metadata you already legally hold (emails, subscription status, plan history) — this isn’t card data, but you’ll need it to reconcile records after migration

From Your Outgoing (Current) Processor

• Formal data export request submitted and confirmed in writing
• Proof of their PCI-DSS compliance level (they’ll need to share this with your new processor)
• Confirmation of what metadata will be included in the export (rebill dates, plan IDs, currency, card expiration, etc. — not just raw tokens)
• Timeline commitment for how long the export will take
• Any applicable export fee disclosed upfront
• Named contact person or migration support team on their side
• Confirmation of your official offboarding date so both systems don’t bill the same customer twice

From Your Incoming (New) Processor

• Proof of their PCI-DSS compliance level (to satisfy the outgoing processor’s verification step)
• Confirmation they support direct PCI-to-PCI transfer (not all do — some require passive migration instead)
• Named migration/onboarding contact or engineering support team
• Expected format and delivery method of the token mapping file
• Timeline for re-vaulting and issuing new tokens
• Confirmation of what subscription metadata they can auto-import vs. what you’ll need to manually rebuild (rebill schedules, dunning rules, trial periods)
• Sandbox/test environment access to validate the token mapping before going live

During the Transfer

• Written confirmation both processors have verified each other’s PCI compliance
• Confirmation the transfer occurred server-to-server (never through your own systems)
• Delivery and secure storage of the token mapping file
• QA pass: test a small batch of mapped tokens with $0 or low-value authorization checks before full cutover

Post-Migration

• Update your systems/database to reference new tokens exclusively
• Rebuild rebill schedules, trial logic, and dunning rules in the new processor if they didn’t transfer automatically
• Reconcile customer count and token count against pre-migration numbers
• Monitor first billing cycle closely for failed charges or mismatches
• Confirm old processor account is fully closed/offboarded (especially important for MoR models) to avoid duplicate charges or lingering fees