Case study: A Tier-2 FX broker in Africa migrated in 11 days

Summary

A Tier-2 forex broker operating in an FSCA-adjacent African jurisdiction migrated its full operational stack — CRM, IB management across four tiers, MT5 manager plugins, three PSP integrations, KYC, and mobile app — from a legacy vendor to BrokerTech in 11 calendar days. The migration moved five-figure monthly active traders and a multi-year transaction history with zero trading downtime and a sub-dollar financial reconciliation variance. Sixty days post-launch the broker had cut onboarding time by roughly 60%, moved IB payouts from weekly manual batches to daily automated runs, and reduced support ticket response time from over 24 hours to under 2 hours.

Starting state

Before the migration the broker was running a mid-market CRM from a legacy vendor (unnamed here at client request) under a 12-month auto-renewing contract. The stack included:

• A CRM and back-office covering client records, KYC workflow, deposits and withdrawals
• A bundled IB module handling a four-tier IB hierarchy with mid-three-digit active IBs
• Three PSP integrations covering card, local bank transfer, and a regional e-wallet
• A live MT5 server with manager plugins maintained by a third-party specialist
• A white-label mobile app provided by a separate vendor
• Monthly cost in the prior stack was in the mid five-figures when averaged across license, add-ons and integration fees. Annualized, total spend was approaching six figures with a renewal uplift clause pending.

The ops team was six people. Support handled inbound tickets via a generic ticketing tool bolted onto the CRM. Reporting was a combination of CRM native reports and an Excel-based weekly reconciliation performed manually on Mondays.

Why they migrated

Three drivers, stated in order of priority by the ops director:

1. Cost. The renewal clause on the existing contract included a single-digit-percent uplift plus new per-PSP integration fees for two planned additions. Projected three-year TCO in the prior stack was materially above comparable Tier-2 peers.

2. IB module limits. The bundled IB module did not support per-IB custom override rates beyond tier defaults, did not support grandfather clauses for long-tenured IBs, and processed payouts as a weekly batch that required manual sign-off. As the IB program grew, the manual overhead was becoming a blocker on further acquisition.

3. Slow vendor support. Average response time on non-critical tickets to the existing vendor was in the one-to-three-day range. Critical incidents were handled faster but required escalation through a named account manager. The ops director described the support model as "good enough when nothing is wrong and not good enough when something is."

The migration

The full migration ran 11 calendar days from kickoff to end of parallel run. The following is the day-by-day narrative.

Days 1–2: Assessment

Kickoff on a Monday morning. Two BrokerTech engineers and the client's ops director and head of tech on a shared call. Access was provisioned to a read-replica of the source database within the first four hours. By end of day 2 the team had produced:

• A current-state audit document covering CRM, MT5, three PSPs, KYC vendor, mobile app vendor, email provider
• A draft data map covering 14 entity classes
• An integration list with 23 outbound and inbound integration points, of which 18 were classified must-migrate
• A risk register with 11 entries, top three being PSP re-certification timing, MT5 manager plugin replacement sequence, and regulatory notification window

Phase 1 was signed off end of day 2.

Days 3–6: Data migration

ETL jobs were drafted on day 3 against the finalized data map. First full extraction ran overnight on day 3 into day 4. Volumes: tens of thousands of client records, low six-figure historical transactions, hundreds of IB hierarchy nodes across four tiers, a multi-year audit log.

Day 4 surfaced two exceptions: a subset of client records from the earliest years of operation had mixed encoding in name fields, and one grandfather-clause IB had a commission rate that did not match any rule in the active rule set. Both were resolved by end of day 5 — encoding via a per-row detection pass, the IB edge case via an explicit override record.

Day 6 ran the final reconciliation. Source vs target variance was below one dollar aggregate across all accounts. Phase 2 signed off end of day 6.

Days 7–9: Integration and testing

Phase 3 ran three parallel tracks.

PSP re-certification. All three PSPs were contacted in Phase 1. The card provider required no re-certification, only a notification. The local bank transfer provider ran a two-day certification cycle completed on day 8. The regional e-wallet required new webhook credentials only. Live test transactions were executed on day 8 for each provider covering deposit success, deposit failure, withdrawal approval, withdrawal reject, and webhook replay. All PSP reference IDs were logged.

MT5 server cutover. The MT5 cutover plan was rehearsed on a staging MT5 instance on day 7. Manager plugin replacement sequence was validated. Group config drift was detected and reconciled — seven groups had manual commission overrides that were not in the documented config. The reconciled target config was approved by the client's head of tech.

UAT. The client's ops team ran a 34-scenario UAT script on days 8 and 9. Three issues were raised: a mobile app push notification was being sent in the wrong language for a subset of users, a withdrawal-rejection email template had outdated legal footer text, and the admin audit log filter was missing one field. All three were fixed by end of day 9.

Phase 3 signed off end of day 9.

Days 10–11: Parallel run, training, cutover

Cutover window was scheduled for a Sunday low-volume window. The 4-hour cutover began at 02:00 local time on day 10. MT5 manager plugins were swapped at 02:30. DNS and session stores switched at 03:00. PSP webhooks re-pointed at 03:30. The client portal was available again by 03:45. Admin panel was fully available by 04:30. Trading on MT5 was never interrupted.

Parallel run began at 06:00 day 10. Hourly parity checks covered client balance sums, open position counts, pending deposit counts, and last-login timestamps. All checks passed every hour for 24 hours.

Staff training ran in two sessions on day 10 afternoon (ops team, 2 hours) and day 11 morning (support and compliance, 2 hours). Recorded walkthroughs were delivered to the client's shared drive.

End of day 11: parallel run reviewed and closed. Hypercare began. The 60-day support clock started.

Results, 60 days post-launch

The following are the measured outcomes 60 days after cutover. Quantitative figures are expressed as ranges to protect client confidentiality.

• Support ticket response time reduced from greater than 24 hours on average to under 2 hours on average, driven by the built-in CRM ticketing module replacing the bolted-on legacy tool.
• IB payout processing moved from a weekly manual batch requiring sign-off to daily automated runs with exception-only review. Ops headcount allocated to IB payouts dropped from one full person per week to under half a day per week.
• Client onboarding time — from initial registration to fully approved and funded — was cut by approximately 60%, driven by the integrated KYC flow and faster deposit confirmation on the primary PSP.
• Monday reconciliation was retired. The manual Excel-based weekly reconciliation was replaced by continuous automated reconciliation visible in the admin panel.
• Annual cost moved from approaching six figures in the prior stack to a flat $72,000 with no add-ons. The year-one saving was in the mid-five-figures range. The three-year projected saving versus staying on the prior contract with its uplift clause is in the low-six-figures range.
• Uptime in the 60-day window met the 99.9% SLA with no unplanned outages affecting trading.

What we'd do differently

Two honest retrospectives from the BrokerTech side and one from the client side.

1. Start the PSP re-certification conversation earlier. We contacted the bank transfer PSP on day 1 of Phase 1. The PSP's internal process needed a longer lead time than they initially indicated. It did not delay go-live in this case, but a longer notice period would have removed end-of-Phase-3 schedule pressure. For future migrations we now reach out to PSPs during the sales phase, not the assessment phase, with client permission.

2. Build the MT5 group config diff earlier. We caught the group config drift on day 7 during cutover rehearsal. Catching it on day 1 or day 2 during assessment would have been better — not because the fix was hard but because surprises late in the schedule are expensive even when they are cheap to resolve. We now run the MT5 manager API diff as a Phase 1 deliverable.

3. (Client retrospective) Brief the support team earlier. The client's ops director noted that the support team had the shortest exposure to the new CRM before cutover and would have benefited from a half-day hands-on session during Phase 3 rather than only at go-live. For future migrations we now schedule a support-team preview session midway through Phase 3.

Client quote

"We went into this expecting a two-to-three-month project with the usual surprises. What we got was a documented plan on day two, a clean reconciliation on day six, and a cutover that was boring in the best sense of the word. The first Monday after go-live was the first Monday in years where nobody touched an Excel reconciliation. The second was the first Monday where our IB payouts were already done by 9am." — Operations Director, unnamed Tier-2 FX broker

Start your migration assessment

A Phase 1 assessment for your stack is free and takes 1–2 working days. You receive a written current-state audit, data map, integration list, and risk register whether or not you choose to proceed.