Imagine this scenario: a card program migrates to a new platform over a weekend. By Monday morning, customer support lines are overwhelmed. Legitimate purchases are being declined and recurring payments are failing. Customers who rely on the card for their most important transactions suddenly can’t use it.
Within days, the story is not about a successful upgrade. Instead, the program is in the news because of broken payments and frustrated customers, and the brand is scrambling to regain trust.
This is the risk every organization faces when moving a card program, payment platform, or issuing relationship from one provider to another. A migration may begin as a technology project, but its real impact is felt in the customer experience.
This reality has been on display in the recent rollout of Bilt 2.0. After transitioning its card program to a new stack involving Cardless and Column N.A., customers reported widespread transaction declines, rent payment issues, and confusion around new fees and policies. Users were in an uproar over the migration experience.
The lesson here is that the processor behind a card program is a major determining factor in whether a migration becomes a competitive advantage or a reputational crisis.
Common Failure Points in Payment Program Migrations
While every situation has its unique characteristics, there are failure points that tend to appear again and again, especially when a processor lacks the infrastructure and experience to support a complex transition.
Systemic Transaction Denials
One of the fastest ways for a migration to fail is for legitimate transactions to begin getting declined. Customers don’t care why their card stopped working - they only know that it worked yesterday and does not work today and that is an inconvenience they don’t want to have to deal with.
False declines often emerge when a new processor hasn’t fully aligned its authorization rules, fraud models, and account logic with the previous platform. Several technical issues that tend to appear repeatedly include:
- Authorization rules are configured differently than on the prior platform
- Fraud models are too aggressive and block legitimate spending
- Integrations between the processor, issuer, and network aren’t fully tested
- Balance and ledger logic don’t match how funds were tracked previously
- Merchant category handling changes unexpectedly
In the Bilt migration, for example, cardholders reported that ordinary purchases were suddenly being denied despite having available credit and previously successful transaction histories. These kinds of failures are rarely caused by a single bug and are more likely the result of weaknesses in testing, migration planning, or processor maturity.
Core Payment Flows Stop Working
Every payment program has one workflow that matters more than anything else. For Bilt, it was rent payments. For another program, it may be payroll, insurance disbursements, recurring bill pay, or anything else. Customers may be willing to tolerate a rough edge or two during a migration, but they are far less forgiving when the primary reason they use the product to begin with stops working.
When a processor has limited experience with complex migrations, the most critical workflow is often where the first cracks appear. Recurring payment rules may not migrate correctly, ACH instructions may not be transferred accurately, and scheduled payments might fail because account mapping or ledger logic changed between systems.
The result is disproportionately damaging as a customer who can’t use the one feature they rely on most is unlikely to care that the new platform has better reporting, a cleaner user interface, or faster API speeds. If the processor can’t preserve the core transaction customers depend on, the migration has failed.
Fee and Policy Changes Create Customer Backlash
Customers are usually highly sensitive to changes to fees, limits, and policies and will notice any changes immediately, especially if they weren't clearly communicated in advance.
The problems can take many forms:
- New foreign transaction fees
- Different spending limits
- Changes to rewards or payout timing
- Modified cardholder agreements
- New restrictions on certain transaction types
In the Bilt example, customers started noticing a .2% charge on foreign transactions even though the program had historically been marketed as not having any foreign transaction fees. The company later stated that the charge was unintended and promised refunds, but the damage had already been done. The controversy generated frustration because customers believed the value proposition of the card changed.
The fee itself was relatively small, but the larger problem was that the change contradicted customer expectations. That is often how migration backlash begins - a processor may technically complete the transition, yet still undermine trust because the program behaves differently than customers were promised.
Why Processor Selection is Often the Root Cause of Migration Failures
Many companies focus on front-end features when choosing a processor. They compare APIs, dashboards, speed to market, and pricing. These factors matter, of course, but they say very little about whether the processor can handle a high-stakes migration involving live cardholders, active balances, recurring payments and years of transaction history.
Established processor ecosystems have spent years refining the operational foundations that define a successful migration:
- Proven migration playbooks based on prior implementations
- Mature authorization engines with tested rules and controls
- Existing processes for disputes, settlement, reconciliation, and ledgering
- Dedicated testing environments and parallel-run capabilities
- Rollback procedures if something goes wrong after launch
- Experience handling scale, exceptions, and unusual edge cases
While the difference might not be visible during a sales demo, it becomes very visible at the moment of migration.
The Hidden Risk of Bypassing Established Processing Platforms
Some organizations choose to avoid established issuing platforms in favor of proprietary infrastructure or new combinations of vendors. That approach can appear attractive at first with (seemingly) more flexibility, faster initial development, or a lower upfront cost.
The tradeoff is that the organization becomes responsible for solving problems that established processors have already spent years learning how to manage.
Companies such as Galileo, Episode Six, and Lithic have built their reputations around supporting complex card programs and processor migrations They have experience with the realities that create risk during a transition, including:
- Partial data migrations
- Merchant category mismatches
- Recurring payment failures
- Cross-border transaction handling
- Authorization rule conflicts
- Reconciliation differences between systems
Without a strong foundation, migrations are more likely to suffer from:
- Incomplete testing
- Fragile transaction routing
- Poor handling of exceptions
- Longer outages and slower recovery
- Greater customer disruption after launch
7 Questions to Ask Before Choosing a Processor for a Migration
Before committing to a new processor to migrate an existing card program, it’s important to evaluate more than pricing and feature lists. The following questions offer a more reliable way to assess whether a processor can support a successful migration.
- How Much Migration Experience Do They Have?
Ask how many migrations the processor has completed and what types of programs they have moved.
A processor that has migrated prepaid programs, credit programs, payroll cards, insurance disbursement platforms, and other complex environments will be better prepared for unexpected issues than one attempting its first large-scale transition.
Request case studies, references, and examples or programs similar to your own.
- Is the Underlying Infrastructure Proven?
The processor should have:
- Established issuing and payment rails
- A mature authorization engine
- Real-time ledgering and reconciliation
- Existing integrations with banks and networks
- Demonstrated reliability at scale
Consider it a warning sign if the processor can’t clearly explain how these systems work.
- Can They Preserve Your Most Important Customer Workflow?
Identify the transaction or workflow that matters most to your customers and ask the processor exactly how they will protect it during migration. Whether it’s rent payments, payroll, disbursements, gig worker payouts, or any other use case, the processor should be able to describe exactly how the workflow will be tested, migrated, and monitored before launch.
- What Testing and Rollback Plans Exist?
An experienced processor won’t assume that everything will work perfectly with no hiccups. Rather, they will provide:
- Sandbox and staged environments for thorough testing
- Parallel testing before launch
- A detailed cutover plan
- Rollback contingencies if issues appear after go-live
Make sure to ask what happens if the migration encounters serious problems in the first 24-48 hours. If there is no clear answer, the risk may be higher than you think.
- How Do They Manage Fraud and Authorization Controls?
False declines are one of the most visible and frustrating outcomes of a poorly managed migration. To avoid this, it’s important to clarify:
- How fraud rules will be tuned during migration
- How fraud will be distinguished from legitimate transactions
- How transaction monitoring works in real time
- Whether authorization rules can be customized before and after launch
A mature processor treats fraud as an ongoing process rather than a one-time configuration exercise.
- Are All Fees and Policy Changes Transparent?
Any changes to fees, rewards, limits, or terms should be documented and communicated to customers before launch. Make sure you review the following:
- Foreign transaction treatment
- Spending limits
- Cardholder agreements
- Rewards structure
- Program fees and pricing
Customers are much more likely to accept change when they understand it in advance.
- What Happens After Go-Live?
The best processors remain heavily involved after the migration launches. Look for a processor that offers:
- Dedicated support teams
- Live transaction monitoring
- Rapid incident response
- Daily reporting during the first few weeks
- Ongoing optimization during the first 30-90 days
Many migration failures may not become apparent until after customers begin using the new system. The first month after launch is often as important as the migration itself.
What Does a Successful Migration Look Like?
A successful migration should be undramatic and fairly anti-climactic. Customers should continue using the program with little or no disruption. Their cards work as expected, recurring payments go through, and support requests remain low. Most users barely notice that the underlying processor has changed.
Getting that outcome depends on choosing a partner with the right infrastructure. Reliable processor partners typically share several characteristics:
- Established bank and network integrations
- Strong compliance and risk controls
- Configurable authorization rules and business logic
- Real-time ledgering and reconciliation
- White-label flexibility for customer experience and branding
- Experience supporting enterprise-scale programs
The strongest providers also simplify the migration itself. Rather than requiring organizations to coordinate multiple disconnected vendors, they bring together issuing, processing, ledgering, compliance, and operational support in a unified platform. This approach reduces operational complexity, shortens time to market, and lowers the likelihood of disruption.
Successful migrations also tend to follow a staged rollout model rather than a “big bang” approach. Small pilot groups, parallel runs, and phased cutovers create opportunities to identify problems before they affect the entire customer base.
The Platform Behind the Migration Determines the Outcome
Processor selection might sound like a boring, back-office decision, but it shapes the customer experience, the reliability of the program, and the reputation of the brand. The wrong processor can turn a migration into a cascade of declined transactions, failed payments, customer complaints, and public backlash.
The right processor creates a different result: a faster transition, a more stable platform, stronger customer confidence, and a foundation for future growth. The difference between a successful migration and a public failure comes down to the platform behind it.
Reach out to us at Berkeley to learn how proven payment infrastructure can support your next migration.
