What a platform migration actually costs you in downtime

The reason established brokers stay on platforms they have outgrown is not loyalty. It is that no vendor will give them a straight answer about what switching costs, so the risk stays unquantified, and unquantified risk always loses to the status quo.

So here is the accounting.

Downtime is not the main risk

Most operators ask about downtime first. It is the wrong question, but it has a simple answer: a competently run migration moves client batches during a weekend market close, and each batch is offline for under two hours. Clients who have not yet been migrated are unaffected because their old platform is still running.

The real risk is reconciliation. If a balance, an open position or an accrued commission does not match after the move, you have a client dispute, and client disputes in this industry escalate to your regulator faster than anything else.

That is what the process below is designed around.

Stage by stage

Discovery

Every instrument, account group, leverage tier, commission structure and connected system is documented. This stage is boring and it is where migrations are won. The failures we have been called in to fix were nearly always missing something nobody thought to mention — a custom plugin, a legacy account group, an Introducing Broker tree with a manual adjustment in it.

Expect one to two weeks. If a vendor proposes skipping it, that is your answer about the vendor.

Mapping and sign-off

Your configuration is rebuilt on the target platform and reviewed line by line by your operations lead. Nothing moves until someone on your side signs the mapping, because your operations lead knows things about your setup that no document captured.

Parallel environment

The new platform runs alongside the old one with live data. Your dealing desk and support team use it daily before any client touches it. This surfaces the workflow problems — a report that is laid out differently, a field someone relied on — while they are still cheap to fix.

Two to three weeks, running concurrently with your normal operations.

Pilot group

A small group moves first: internal accounts, then friendly clients who know they are in a pilot. They trade live for an agreed period, usually two weeks. You are looking for execution behaviour, statement accuracy and anything the parallel run did not reveal.

Staged client migration

Clients move in batches you define, typically by group or region. Each batch:

1. Moves during a weekend market close
2. Has balances and open positions reconciled against the source statement before the batch is signed off
3. Can be rolled back independently if reconciliation fails

Batch size is a business decision, not a technical one. Larger batches finish sooner; smaller batches limit the blast radius if something is wrong.

Decommission

The old platform is retired only after every group has moved and reconciled. Keep it readable for a period afterwards — when a client queries a trade from four months ago, you want the original record, not a migrated approximation.

The honest total

For an established broker with a few thousand active accounts:

Stage	Duration	Client impact
Discovery	1–2 weeks	None
Mapping and sign-off	1 week	None
Parallel environment	2–3 weeks	None
Pilot group	2 weeks	Pilot clients only
Staged migration	2–4 weeks	Under 2 hours per batch, at market close
Decommission	1 week	None

Six to twelve weeks end to end. Client-visible downtime measured in hours, not days, and confined to weekend closes.

The costs nobody quotes

Two more line items belong in your plan:

Your team's time. Discovery, mapping sign-off and reconciliation all need your operations people, and they still have day jobs. This is the resource that actually constrains most migrations.

Support load during the switch. Clients who have just moved will contact you about the new interface. Brief your support team and prepare the answers before the first batch, not after.

What to ask a vendor

Ask them to walk you through their last migration — what went wrong and how they found it. Every real migration has a moment where something did not reconcile.

A vendor who says their migrations always go perfectly has either done very few, or is not going to tell you when yours does not.