How to Safely Migrate to a Better Banking Infrastructure in 21 Days (Or Less)

Two frustrating truths about banking infrastructure are: it’s not easy to get right, and you don’t really want to change it – until it hurts.

If you’re offering financial features today – accounts, cards, payments or lending – and are unhappy with your initial choice of infrastructure, this guide is for you. It’s based on our experience speaking to dozens of leaders at tech companies and helping multiple clients migrate successfully to Unit. We’ll explain why companies choose to go through the pain of migration, what the exact steps involved are and what obstacles you should watch out for.

As founders, we know how complex migration can be and how many fronts it involves: product, engineering, customer service, commercial, legal and more. We also know that the devil is in the details. In this post, we’ll walk you through a real-world migration scenario. In order to confront the most difficult questions around migration, we’ve deliberately chosen to make this scenario feature rich – accounts, cards and payments – and aim for an end-game of complete migration, rather than a situation that involves dual support.

Why Companies Migrate

Your banking infrastructure is not “yet another” utility in your software stack. You’ve invested a lot of time and effort into building on it and over time it grows to manage more of your customers and their activities. You may dread the cost and organizational distraction that come with a potential migration. But eventually, and unfortunately all too often, problems with your existing banking infrastructure can have a severe effect on your business performance and your customer relationships. At that point, migration becomes top of mind.

Common reasons that tech companies change their banking infrastructure are:

Lack of important financial products: in our experience, many companies follow a financial feature roadmap. Sooner or later, your use case may require access to new types of accounts (joint accounts, escrow accounts, business accounts or HSA), new types of cards (prepaid or credit cards), financing options (cash advance, lending), checks or even basic interest payments. Your existing partner bank rarely offers a complete suite of products, as we explained in a previous guide (see finding a bank relationship: harder than you think).

Lack of important software features: your software needs as a company building financial features evolve quickly, and so should your infrastructure. There are great product ideas you could bring to life if only you could be in the authorization flow of card purchases and approve or deny transactions by looking at rich data. Or you found a great path to adoption that involves promoting users to VIP terms (maximum cash-back and interest), but your existing infrastructure doesn’t let you offer flexible and diverse terms. A real-time dashboard would help you improve adoption and retention. Your customer support team will likely need much better visibility into end-customer activity to delight your customers, and this access needs to be carefully permissioned. Your CTO may be able to move much, much faster by being able to simulate and test features. The list goes on and on.

Technical instability: in financial infrastructure, 99% is far from good enough. You may have chosen an infrastructure partner and expected rock-solid systems, but encountered inconsistent uptimes, unreliable systems, duplicate transactions and even rounding errors. The problems of your infrastructure partner then become your problems, put a strain on your entire team and erode the trust you’ve built with your end-customers who thought they could trust you with their money.

Customer service and operational issues: technical excellence is only part of the infrastructure game. When you store and move funds for your customers, mediocre service or self-service is not an option. Your customers will ask money-related questions and expect quick answers. Nothing is more important than being able to talk to high-quality compliance, customer support and customer success teams that resolve those questions quickly.

Bad economics: once your product meets the market and diverse features get into the hands of your customers, you have a full understanding of your cost centers and revenue drivers. Chances are that you’d want to radically improve the terms you offer to your customers (think maximum cash-back) or make more revenues by improving your per-transaction costs (think ACH, checks, fedwire). Most banks and infrastructure partners in the ecosystem lock you into 3-5 year relationships with anything but optimal terms.

Issues with the underlying bank: whether you’re built on a bank, a bank + middleware or a platform, there’s always going to be a bank underneath. In the last 10 years, multiple banks in the ecosystem suffered from issues that hurt their ability to serve tech companies. In some cases, banks in the ecosystem made a decision to exit the business of partnering with tech companies altogether. In other cases, they were directed to do so by their regulator. In all cases, you could pay the price by being restricted or forced to migrate to another infrastructure.

Earlier is Better

When should you migrate? If your existing banking infrastructure is starting to put a strain on your business performance and flexibility, the ideal answer is “as early as possible”. We’re about to break down the actual cost and work that go into migration. Companies that wait longer eventually face more expensive and demanding migration projects, and do so under much more pressure.

Many leaders in tech companies know first hand the relief that comes with a migration to superior infrastructure. Wealthfront and Robinhood both left their legacy clearing broker, citing “legacy systems and infrastructure from the 1960s [… ] semi-manual processes and disjointed systems”. When our previous company struggled with processing growing trading volumes on our initial communication architecture , we invested four months in switching 100% of the communication between our backend systems to ZeroMQ. We hardly shipped new features during that time, but this decision ultimately allowed us to grow to $100b+ in trading volume at 0 milliseconds latency.

Migrating early to a long-term solution ultimately lets you shift your focus to your core business and move faster as a company. A short, well-planned migration project is a good investment. Let’s break it all down.

Understanding the Migration Process

To explain everything, let’s use an example. Say you are the CEO or CTO at Small Business Hero, a startup that serves 4,000 businesses, mostly growing eCommerce shops. You’ve identified the next generation of features that will delight your customers and expect to grow to 20,000 customers within a year. You’ve decided to look for alternatives to Legacy Solution, your current infrastructure partner, for multiple reasons, including technical instability and lack of important software features.

Throughout this post, we will use Unit as an example for the new infrastructure partner you’ve chosen, but you can replace it with any other infrastructure that you want to migrate to. First, let’s take a high level look at the goal of a successful migration:

Let’s explain what it means:

1. The key activity is transferring your 4,000 existing customers (Business 1 to Business 4,000) from Legacy Solution to Unit.
2. It’s especially important to make the transition as frictionless as possible for all migrated customers. More on that in the Execution section below.
3. In particular, it’s important to carefully monitor the exception rate among migrated customers. For example, when trying to migrate Business 1,418, Unit’s screening process may flag that particular business and require additional business documents. In our experience, the number of exceptions should be close to 0 and the goal is always 0-1% (<40 customers, in your case). More on that in the Execution section below.
4. From the moment you start migration, new customers (from Business 4,001 onwards) should be onboarded directly on Unit, rather than on Legacy Solution.
5. You will maintain your relationship with Legacy Solution until all accounts are migrated, but your ultimate goal is to migrate all funds and data – and run purely on Unit.

Keep it Short

Did we mention that the migration project should be carefully planned and be as quick as possible? By definition, your product has to support two different infrastructures before you finish migrating the 4,000 customers from Legacy Solution. This stage of dual support is a nontrivial tax on your product, engineering and customer service teams.

From a product and engineering perspective, your servers have to interact with the Unit API or with the Legacy Solution API, depending on where a given customer “lives”. Here’s how it looks:

This is also true from a customer service perspective: if a customer has a question, your team has to interact with two different companies and sets of systems, depending on where a given customer “lives”.

Keeping the core migration process (Business 1 to Business 4,000) as short as possible is therefore the key to a successful migration. In our experience, the best case scenario is migrating in a single day. The more common average case scenario is migrating in 2-3 weeks. Anything beyond that would put an unnecessary tax on your team. It could (and should) be avoided by planning and executing the migration well.

Key Assumptions

Before we continue to the execution stage, we should highlight assumptions that you will need to verify for your case.

Commercially, make sure you understand the cost of paying two different infrastructure partners during the dual support stage. You will also have to consider the cost of re-issuing cards on your new infrastructure. Unit makes things easier by working closely with your team to shorten the dual support stage, lowering fees during the dual support period and offering card issuance at cost for all cards, physical and virtual.

Legally, migrating is about moving data and funds to your new infrastructure. From a data point of view, make sure that you have access to customer data in order to onboard your customers on the new infrastructure with minimal friction. From a funds point of view, make sure that you can transfer all customer balances on your migration timeline. There aren’t usually technical obstacles in this process, but some partner banks limit the speed of migration due to internal risk management policies.

Execution

Product and Engineering: Building a Low-Friction User Experience

The most important part of your execution is designing and launching a low-friction (ideally, zero friction) migration experience for the 4,000 customers that need to be migrated.

In most cases, the steps for migrating a single customer takes 10 seconds or less, but could take a little longer in the case of exceptions, which we will cover shortly. Here are the steps:

1. Notify the customer: communicate with your customer within your product or over email/SMS to notify them of the change.
2. Get their approval: when notifying your customer, you will also want to show them the new terms and conditions and collect their consent to set up their next account, re-issue their card(s), transfer their funds and close their old account.
3. Onboard them on Unit: in the case of small businesses, you will want to simply create a business application and pass on the information you already have about the customer.
4. Collect missing information (optional): Unit’s application is designed to initially require essential information only, which keeps friction low. In exceptional cases, additional documents will be required. Your product should allow customers to submit those documents, and ideally remind them to do it if they forget. Your customer service team will provide the final human touch if any further communication is needed (see Customer Service: Managing Exceptions below).
5. Transfer their funds: Unit typically approves applications in less than 10 seconds. Then, you may instantly create a new deposit account at Unit and send the funds into it. One way to do it is originating an ACH debit via Unit to pull the funds from their Legacy Solution account. Another option is originating an ACH credit via Legacy Solution to push funds into their routing number and account number on Unit. In special cases, you may ask Unit to set up org accounts (such as batch accounts or clearing accounts) to assist with the migration process.
6. Issue their new cards: call the Unit API to create the same number of business debit cards, both physical and virtual.
7. Notify them of the result: once you’re done, share the important information with the customer: their new virtual debit card numbers, when they should expect their physical card to arrive, their new routing numbers and account numbers.

At this point, the customer should be marked as successfully migrated, and your product should continue to serve them using their new Unit account. If you have a legal obligation or a preference to share history with your customer (for example, in the case of past statements), make sure you have that information and serve it to them as needed.

Customer Service: Managing Exceptions

Ideally, most of your customers will go through a completely frictionless migration process. It is our experience though, that a small number of customers will require additional documents, a manual review or both. Unit conducts the required manual reviews, but your customer service team will need to handle customer interactions around those exceptions.

We recommend holding daily meetings in front of real-time reports to make sure exceptions are resolved quickly. The Unit Dashboard provides all the information you’ll need to monitor every single application and determine if any action is required:

In the case of exceptions, your customer service team should contact relevant customers, keep them posted on the expected migration time and remind them to submit any additional documents. It’s also very likely that customers will contact your support to ask questions, and your customer service team will play an important role in answering those questions and explaining the migration process.

If your customer base is large, you will want to keep the outstanding number of exceptions in line with the size of your customer service team. There are multiple ways to achieve this, and one of them is managing the migration process in cohorts. For example, if you have 45,000 customers at Small Business Hero, you may deliberately initiate 4,500 customer migrations per day for 10 consecutive business days.

End-game: Full Migration

After 21 days or less of execution, your entire customer base will be migrated to the new infrastructure and your team can happily declare the end of the dual support stage. This is what it looks like:

Summary

In this guide, we discussed the different reasons that companies grow out of their initial choice of banking infrastructure. We also discussed the benefits in migrating early, especially when your existing banking infrastructure has a negative effect on your business performance and flexibility.

Finally, we created a full execution plan for a successful migration process that involves engineering, product and customer service. The process should take no longer than 21 days.

We’ve done our best to lay out a detailed plan here, but migration is not always an exact science. Unit understands the costs, risks and moving parts in helping companies migrate, especially at scale. Migrating successfully requires planning, careful execution and human-to-human collaboration at every step of the way.

If you’re considering upgrading from an existing banking infrastructure and would like to understand how we can help, you can contact us to book a demo or sign up for sandbox.

‍