Capture the current environment or launch baseline
For an existing operation, build a read-only inventory before changing anything: server identity, groups, symbol names, contract specifications, interfaces, operational reports and connected services. Record the owner of each export. Keep a dated copy of the agreed baseline in an access-controlled project location.
For a new brokerage, define the intended catalogue and client workflow instead. Mark every unconfirmed item as a dependency, including platform rights, branding options, hosting and third-party availability. An empty requirement must not silently become the provider's default configuration.
Validate the account and symbol matrix
- Test at least one representative account from each intended group.
- Compare account currency, permitted actions and instrument availability with the agreed brief.
- Review symbol spelling and suffixes alongside contract size, volume rules, trading sessions and other commercially relevant specifications.
- Check chart and history access for the instruments used in acceptance testing.
- Exercise important Expert Advisor and reporting dependencies in a controlled test environment where rights and access permit.
Keep expected and observed settings in separate columns. A successful login does not establish that the account belongs to the right operating configuration.
Rehearse integrations and the change window
Confirm the CRM account-creation path, operator permissions, bridge connections and reporting handoffs. Include a negative test for an unavailable integration or rejected request. Decide who investigates a partial result and how the team prevents an unreviewed retry from producing duplicate account or financial operations.
For migration, rehearse the sequence with a representative subset and define the production freeze, reconciliation and rollback decision. Existing client credentials, account identifiers and history continuity require explicit confirmation from the parties controlling them. Do not promise a seamless transfer without that confirmation.
Close the checklist with named acceptance owners
| Gate | Required evidence |
|---|---|
| Configuration | Signed account/group and instrument comparison |
| Connectivity | Recorded test journey through each launch-critical integration |
| Continuity | Backup and restoration responsibility, rehearsal result and rollback owner |
| Operations | Access inventory, escalation contacts and a handover session |
Illustrative example: a test account connects correctly but its CRM report uses an old suffix. The open item belongs to symbol mapping and reporting, so the launch gate remains unresolved until both records agree. Review the MT4 White Label implementation scope with the evidence attached, rather than closing it from a visual terminal check alone.
Resolve continuity questions explicitly
Can existing accounts and history always be transferred?
Do not assume this. Obtain confirmation of available access, supported export or migration methods and the responsibilities of the parties controlling the environment. Record any account, credential or history limitations before selecting the cutover method and communicating a migration plan.
What should remain open after a successful login test?
Any unverified requirement: instrument rules, CRM mapping, reporting, operator access, backup coverage or support ownership. Mark the successful login as one passed case. It should not automatically close the remaining acceptance gates or replace a reconciliation check for an existing operation.