Most operators who stay on an ageing platform are not attached to it. They stay because the switch feels riskier than the slow decline: customers who cannot sign in, transfers stuck between two systems, a regulator asking why records do not agree. Those fears are reasonable, and the answer to them is staging. You do not move everyone on one date. You migrate the data, prove the new platform in a trial, launch with a small, focused group of customers, and only then bring everyone else across.
This playbook is for the COO, CTO and head of compliance of an established money transfer operator. It covers each stage, what to check before moving to the next, how to talk to customers, regulators and banks, and how to keep a way back. Its companion piece, the data migration checklist for money transfer operators, covers the records themselves.
Plan the move as four stages, each with its own exit test
A staged migration has four parts. Each one ends with a test that must be passed before the next begins.
| Stage | What happens | Who carries live traffic | Exit test |
|---|---|---|---|
| 1. Data migration | Customers, recipients, compliance records, history and settings move to the new platform | Old platform | Counts, totals and samples agree |
| 2. Trial run | Staff run real tasks and test transfers end to end on every corridor | Old platform | Every corridor, payment route and payout method works, including failures and refunds |
| Optional: parallel run | The operator runs both systems and compares figures | Operator's choice | Mismatches explained and closed |
| 3. Focused launch | A new, small group of customers starts on the new platform | New platform for the group; old for everyone else | The group transacts without unexplained issues |
| 4. Mass migration | Remaining customers move, often in waves | New platform | Old platform carries no new transfers |
Whatever the stage, one rule holds: every transfer has exactly one system of record at any moment, and everyone on the team can say which one it is.
Rule of thumb: if two people on the team give different answers to "which system is the record for this transfer?", the plan for the current stage is not finished.
Migrate the data and prove it arrived
Everything later depends on the data being complete and correct. Customers, KYC documents and decisions, saved recipients with valid payout details, transaction history, ledger opening balances, screening decisions, AML rules, rates, fees and staff roles all need a home on the new platform.
Do not accept "migrated" as a status. Accept counts that match per record type, totals that match per currency, and a sample checked by hand by someone who knows the business. Recipients deserve particular care: a saved recipient that fails the new platform's payout validation is a customer who cannot send again in two taps. The companion checklist sets out each data domain, the validation check and the owner.
Run a trial that covers the awkward cases, not just the happy path
A trial run proves that the new platform does the operator's jobs with the operator's data. A trial that only sends a few successful transfers proves very little. Build a script that covers what actually goes wrong:
- A transfer on every corridor, payment route and payout method.
- A deposit that does not match what the customer declared, and one that arrives twice.
- A payout the partner rejects, and one returned after it was paid.
- A refund, with the accounting entries checked.
- A possible sanctions match ruled on by compliance; a transfer held by a risk rule and released by a reviewer.
- A customer reaching an AML threshold and being asked for documents.
- A migrated customer signing in, seeing their history and sending again to a saved recipient.
- Month-end figures produced and agreed by finance.
Each staff member should perform their own tasks during the trial, with the access they will actually have. Record what was tested, by whom, and the result. That record is your evidence later.
Decide whether to run your own parallel run
Some operators want more assurance than a trial gives, and choose to run both systems side by side for a period, comparing outcomes. It is a choice, not a requirement. It costs double work, and its value depends on the discipline of the comparison. If you do it, the useful part is a regular match check per corridor:
| Figure | What must agree | If it does not match |
|---|---|---|
| Transfer count by status | Initiated, paid in, sent to partner, paid out, cancelled, refunded | List the differing references; trace each one |
| Amounts and rates | Principal collected per currency, rate applied, amount delivered | Compare rate history, margins and amount bands |
| Fees | Fee per transfer and total fee income | Compare fee rules by payment method and amount |
| Deposits | Payments matched to transfers; unmatched and held items | Review declared versus received amounts |
| Ledger balances | Customer funds held, partner prefunding, fee income, FX gains and losses | Read the entries behind the balance |
| Screening and risk | Sanctions hits, decisions, transfers held for review | Compare list versions and rule settings |
Every mismatch gets a named cause and owner the same day, even if the cause is "the old platform rounds differently and we accept it". Track the number of open mismatches: a falling count is evidence of readiness; a flat one means something structural has not been found.
Launch with a new, focused group of customers first
The focused launch is where the new platform first carries real customers' money. Keep the group small and well defined, so any problem touches few people and is easy to see. Good choices include new customers signing up on one corridor, or new sign-ups from one channel. New customers have no habits formed on the old app, no saved recipients to lose and no history to look for, which makes them the lowest-risk first group.
During the focused launch, watch the things that drive customers away: sign-up and ID check completion, first-transfer success, payout failures, and support contacts. Give the group a fast route to a person who can fix things. When the group transacts without unexplained issues for a period the operator sets, the platform has earned the mass migration.
Watch for: transfers in flight when a customer moves. Never move a half-finished transfer between systems. Let it complete, fail or be refunded on the platform where it began, and track that tail to zero.
Bring everyone else across in waves
The mass migration moves existing customers. Moving them in waves, for example corridor by corridor, simplest first, turns one large risk into several small ones. Put the corridor with the busiest compliance queue or the most complex partner last, when the team knows the new platform well.
Before each wave, confirm the go/no-go criteria:
- Data for the wave reconciled: customer, recipient and history counts agree.
- Every payment route and payout partner in the wave tested with live transfers, including a failure and a refund.
- Screening and risk rules producing the expected holds, with any deliberate differences signed off by compliance.
- Ledger balances agreed by finance.
- Staff serving the wave trained and signed off.
- Customer messages sent and support scripts ready.
- Rollback rehearsed.
If any item is not met, the answer is no-go, with a date for the next decision. A delayed wave costs a few weeks; a failed one costs customers.
Tell existing customers what will change, and only what will change
Customers leave during migrations for small reasons: they cannot sign in, the app looks unfamiliar, or a saved recipient has vanished. Each is predictable.
- Signing in again. Assume customers will sign in fresh and set up their PIN or biometric sign-in on the new app. Tell them before it happens and what they will need, typically their registered email or mobile number.
- App update or new app. If the new app replaces the old listing, say so and explain how to recognise the genuine one. Scammers watch for migrations; say you will never ask for passwords or payment details by phone.
- Saved recipients. These must arrive intact and valid. A customer who has to re-enter a parent's bank details may simply use another provider.
- History and receipts. Customers sometimes need old receipts for tax or immigration purposes. Tell them where past transfers will be.
Time messages to each wave, in the customer's own language. A message weeks early is forgotten; one after the change is a complaint.
Notify regulators, banks and partners on their timetable
Requirements differ by jurisdiction, so treat this as a list of conversations, not legal advice. Many regulators expect advance notice of a material change to systems or outsourcing. Your head of compliance should check the rules for each licence and record the decision either way.
- Regulators: outsourcing and hosting arrangements, where data is held, how records stay complete and retrievable, and how regulatory reports continue without a gap.
- Safeguarding and settlement banks: changes to the accounts customers pay into, payment references, or reconciliation timing.
- Payout partners: new credentials, test windows, the date each wave moves and who to call.
- Auditors: the evidence you keep from data reconciliation, the trial and any parallel run, and how opening balances were agreed.
Keep a dated log of each notification and response. It answers the question an examiner is most likely to ask.
Train staff on their jobs, and keep a rehearsed way back
Training should start during the trial, not the week before the focused launch. Build it around real tasks: approving a held transfer, ruling on a possible match, recording a hold agreed with a payout partner, answering a customer who cannot see a recipient. Set up roles first, so people learn with the access they will have, and keep a signed record of who was trained on what.
Rollback is what makes the forward decision safe. Decide how long you will keep the old platform available after the last wave, with its connections and staff access intact. Define the triggers in advance (payout failures beyond a threshold, a ledger mismatch nobody can explain within a business day, a screening failure), decide who can call it, and agree that transfers started on the new platform finish there; only new transfers go back.
Takeaway: a rollback plan that has never been rehearsed is a hope. Rehearse it once during the trial, time it and write down what went wrong.
Scenario: a three-corridor operator moving in stages
The numbers below are illustrative, chosen to show the reasoning rather than describe any real operator.
An operator sends on three corridors: Corridor A (bank deposit, one partner), Corridor B (bank deposit and cash pickup, two partners) and Corridor C (mobile wallet, with the heaviest enhanced due diligence load). It has around 40,000 registered customers.
Data migration
Counts agree for customers, recipients and history. A sample check finds that Corridor B's cash pickup recipients store names in one field, while the partner expects first and last names separately. The names are split; of a hand-checked sample of 200, 11 need a customer to confirm.
Trial run
The script covers every route. Finance finds fee totals differing by small amounts on 14 test transfers: the old platform rounded fees per transfer, the new one per amount band. Finance decides which is correct and the fee rule is aligned. The operator chooses not to run a full parallel run, but compares month-end figures for one month on both systems.
Focused launch
New sign-ups on Corridor A start on the new platform. Over the first weeks, a few hundred customers transact. One partner's returned-payout messages fail to apply on two days; the cause is a field format, fixed and retried.
Everyone
Existing Corridor A customers move first, then B, then C. Compliance finds one risk rule on C configured more strictly than before, keeps it deliberately and signs it off. Sign-in queries peak in the first days of each wave and fall away, because customers were told the day before.
Doing it with RemitSo
RemitSo is a white label remittance platform with optional source code ownership, and migration from an ageing platform is one of the two main reasons established operators come to it. Migration follows the stages above: RemitSo migrates your data; you run a trial, and your own parallel run if you want one; then you launch with a new, focused group of customers before migrating the rest.
- Data migrated by RemitSo, so your team checks and signs off the data rather than building the extraction.
- Staged launch: a focused group first, then everyone, so early issues touch few customers.
- Double-entry accounting: every payment, payout, refund, fee and FX movement is recorded automatically, and any balance opens to the transactions behind it, which is what reconciliation needs.
- Deposits matched to the cent, with anything unclear held, so mismatches are visible rather than absorbed.
- A fee rule is required before a corridor can go live, and rates keep a full history, so pricing differences can be traced to a setting.
- Payout channels define the recipient details they need, with validation, so migrated recipients that would fail are caught before a customer sends.
- Roles from 89 permissions and staff training with signed records (the training programme is an optional add-on), so people train with the access they will have and you can show who was trained.
- Your brand on every app, with saved recipients, sign-in by one-time code then PIN, Face ID or fingerprint, and emails in the customer's own language.
Your team still owns the decisions: the trial script, whether to run a parallel run, the go/no-go for each wave, customer and regulator communications, and resolving each mismatch. See RemitSo for enterprise and the admin features your team will use.
Frequently asked questions
Do we have to run both systems in parallel?
No. A thorough trial run is the core test. A parallel run is an option some operators choose for extra assurance; it costs double work and is only as useful as the discipline of the comparison.
Why launch with new customers first?
New customers have no saved recipients, history or habits on the old app, so there is less that can go wrong for them. A small, well-defined group also makes any issue easy to spot and fix before existing customers move.
What happens to transfers in flight when customers move?
They finish on the platform where they started: completed, failed or refunded there. Only new transfers start on the new platform. Track the remaining tail until it reaches zero.
Do we need to tell our regulator?
Often, yes, but it depends on the jurisdiction and your licence. Many regulators expect notice of material changes to systems or outsourcing. Check each licence and keep a dated record of the decision and any notification.
Will existing customers need to set up their accounts again?
Their history and saved recipients should arrive with the data migration. Plan for them to sign in fresh and set up PIN or biometric sign-in on the new app, and tell them in advance.