When Should an Established Money Transfer Operator Migrate Its Platform?

Established money transfer operators rarely replace a platform because it has stopped working. They replace it because every change has become a project, every new corridor a negotiation with a vendor or a developer, and every audit a week of spreadsheets. The platform still runs. The business runs around it.

This guide is for founders, CTOs, compliance heads and finance leads at operators who already have a licence, customers, corridors and years of transaction history. It covers how to tell whether the platform has become the constraint, how to pick a window that avoids your busiest weeks and your licence calendar, what waiting really costs, and how a staged migration works: your data moved, a trial run on your side, then a focused first group of customers before everyone else follows. Where we describe RemitSo, we say what it handles and what your team still does.

Most operators feel the problem long before they can name it. These are the triggers that turn a vague frustration into a decision. One on its own is a reason to watch. Three or more together usually means the platform is setting the pace of the business.

• The platform is no longer supported, or is supported by one person. A vendor that has stopped releasing, or an in-house system that only one engineer understands, is a continuity risk your regulator may ask about.
• A new corridor is a project, not a setting. If adding a payout country means a change request, a quote and a release date, growth is waiting on someone else's queue.
• Compliance lives outside the platform. Screening results in one tool, risk decisions in a spreadsheet and regulator reports assembled by hand mean nobody can show the whole picture at once.
• The books are rebuilt every month. Finance exports transactions, matches deposits by eye and posts journals afterwards.
• Maintenance means switching everything off. If a release or an incident stops all transfers, you are choosing between change and service every time.
• Problems are found by customers. A stuck payout is reported by the sender before anyone on the team sees it.
• The cost of change keeps rising. Each workaround makes the next change harder, so the quote for every request grows.

For a longer diagnostic, see signs your platform is holding you back. If your stack is a core system plus several bolt-on tools, patchwork versus one platform looks at where the joins fail.

A useful test: list the last five changes the business asked for, from a new corridor to a fee change. Note how long each took and who it depended on. If most took weeks and depended on someone outside your team, the platform is the constraint.

The case for waiting is usually that migration is disruptive and the current system works. Both are true. The question is whether waiting is cheaper, and it often is not, because the costs of staying grow while the cost of moving does not shrink.

Waiting has four costs that rarely appear in one place:

1. Change requests and workarounds. Vendor or developer fees for every change, plus the staff time spent on manual steps that exist only because the platform cannot do something.
2. Growth you did not take. A corridor that launched six months late, or not at all, is margin you did not earn.
3. Compliance exposure. Manual screening follow-up and hand-built reports are where gaps appear. The cost is not the spreadsheet; it is the finding at your next inspection.
4. A bigger migration later. Every year adds transactions, customers and custom fields to move. Every patch adds behaviour someone must map. The migration does not get easier by waiting; it gets larger.

Put rough monthly figures against the first three, using your own numbers. You need to know whether staying is a rounding error or a line your board would question.

The best time to migrate is when you have a decision and a quiet stretch ahead, not when the old system finally breaks. A planned migration has phases with different risk levels, so the aim is to place the riskiest phases, the launch with your first group of customers and the mass migration of everyone else, away from the weeks you cannot afford to get wrong.

• Avoid your peak seasons. Most corridors have predictable surges: major religious and cultural festivals, year-end, school-fee and harvest periods in receiving countries. Your own volume history shows them. Do not launch the first group or run the mass migration inside one.
• Avoid licence renewals and inspections. In the weeks before a renewal or a scheduled audit, compliance needs stable records and full attention. Finish the mass migration well before, or plan the trial run to fall after.
• Read your vendor contract. Notice periods and renewal dates set a hard edge. Work backwards: you want the old system available until the last customers have moved and any parallel run you choose has finished, so do not let the contract end on the day of the mass migration.
• Tell partners early. Banks and payout partners may need notice of a new connection or new credentials.

There are three honest answers to "should we migrate?", and each is right for some operators. The table sets out when each fits and what it costs you.

"Migrate after a set event" is often the most sensible answer for an operator that has decided but is facing a busy quarter. The discipline is to name the event and the date. Data clean-up can start straight away, because it is useful whatever you decide.

The riskiest migrations move every customer and every corridor on a single night. A safer pattern moves the data first, proves the platform on your side, and then moves customers in stages. This is how a RemitSo migration works:

The length of each stage depends on your data, your corridors and how much assurance you want before the mass migration, so we do not quote a fixed timetable. The parallel run is optional and yours to design: some operators compare both systems for a while, others rely on the trial run and the focused launch. For how to keep customers through the move, see migrating without losing customers. Details for established operators are on the enterprise page.

A migration is only as clean as the data going into it. Most of the delay in any migration comes from questions nobody on the operator's side can answer quickly. Start these before you sign anything:

• Customer records. Find duplicates, closed accounts and customers with expired identity documents. Decide which you will migrate as active.
• Compliance records. Gather screening rulings, KYC decisions, risk ratings and reports filed. Regulators expect continuity, so agree early which records move and how you will keep the rest available.
• Corridors, fees and rates. Write down every live corridor with its fees, margins, limits and payout partners. Include the exceptions people only know from memory.
• Open money. List transfers in flight, unmatched deposits, pending refunds and wallet balances where your licence allows wallets. These need a plan on switch day.
• Finance. Agree the opening balances the new books will start from, and who signs them off.

The data migration checklist covers each of these in detail.

The operator, figures and dates below are illustrative, not drawn from any real business.

An operator in its eighth year runs nine corridors on a vendor platform. In early February the leadership team reviews the triggers. The vendor has slowed releases; two new corridors have waited since the previous summer; compliance builds the monthly regulator report by hand; and finance spends around four days a month matching deposits. Four triggers apply. They decide to migrate.

The calendar shows three fixed points. Their busiest stretch runs from mid-November to early January. Their licence renewal submission is due in late September. The vendor contract renews on 31 December, with 90 days' notice.

They work backwards. The mass migration must be finished by the end of August, clear of the renewal and well before the peak. Before that, they want a focused launch of at least six weeks with a new group: customers who signed up in the previous quarter on their two busiest corridors. Before that, a trial run in which they will also run their own parallel run on three corridors for a month. Their data migration starts in March, while the trial plan is written. Notice to the vendor goes in by early October, so the old platform stays available after the mass migration in case they need records from it.

They put rough monthly numbers on waiting: around 2,500 in change fees, four days of finance time, two days of compliance time, and margin from the two delayed corridors, which they estimate at 6,000 a month once each corridor matures. Waiting until after the peak would cost about nine months of that. They start in March and begin cleaning customer and recipient data in February, while contracts are agreed.

RemitSo is a white label remittance platform, with the option to buy the source code. For established operators, the move is staged so you never bet every customer on one night. See the enterprise and migration page.

• RemitSo migrates your data: your team checks what arrives instead of building the export-and-import itself.
• A trial run on your terms, with an optional parallel run you design: you decide how much assurance you need before customers move.
• A staged transfer: launch first with a new, focused group of customers, then move everyone else, so problems surface in a small group.
• 100+ corridors ready for configuration: on RemitSo a new corridor is a setting, not a project, so the corridors you postponed can follow.
• Compliance in the same platform: screening against 8 sanctions lists reloaded every night, 47 risk indicators combined into your own rules, and regulator reports built from transfer data with a check that nothing was left out.
• Books that post themselves: a double-entry engine records every payment, payout, refund, fee and FX movement, and deposits are matched to the cent.
• Maintenance without stopping everything: pause only what the work needs while money in flight carries on.
• A 99.99% uptime SLA on a dedicated AWS account in your region, billed by AWS to you.

Your team still cleans the source data, confirms corridors, fees and rates, runs the trial and any parallel run, signs off each corridor, chooses the first group of customers and decides when the rest move. Compare the admin tools on the features page and prices on the pricing page.