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.
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 premissioned. 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.
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.
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:
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.
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.
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:
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.
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.
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:
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.