From our research notebook

MT4 to MT5 Conversion Without Strategy Drift

Our conversion work taught us to preserve the decisions a strategy makes, while adapting its order handling, indicators and risk calculations to MT5.

Moving an EA from MT4 to MT5 can look like a programming task with a clear finish line: the new file compiles. Our conversion experience made us look further. We needed to know whether the new version still made the intended decisions.

We fixed a reference before changing the code

We keep the original version, settings, data assumptions and a record of its decisions together. We also distinguish intended behaviour from known defects. Reproducing an old rule and correcting it are different jobs; mixing them makes later comparisons difficult.

We mapped the platform differences

Order and position handling, netting or hedging mode, indicator handles and broker filling rules can all change the implementation. Price precision and volume calculations matter too. We examine those dependencies explicitly rather than assuming similar-looking code means similar behaviour.

We compare the path to the result

We compare signal times, requested sizes, protective levels, modifications and blocked actions. Similar ending balances can hide different trade histories. Restarts, partial fills and rejected requests also belong in the review, because a migration must remain understandable beyond an ordinary backtest.

Explore the technical detailOpen the full method, worked examples and implementation questions. We have kept this material here so you can follow the reasoning as far as you need.

Converting an Expert Advisor from MT4 to MT5 is not a line-by-line translation. The platforms differ in event handling, trade APIs, position models, indicator access, tester behaviour, and symbol data. Code can compile successfully while the strategy quietly behaves differently.

Our archive includes 18 projects marked across both MT4 and MT5 and 12 conversion or integration assignments overall. The recurring lesson is that migration needs a behavioural reference: what the old system actually did, not only what its source code appears to say.

Engineering note · ENG-06

A behaviour-first migration

Lock the reference before changing the implementation.

  1. 01
    ReferenceRecord signals, timing, position ownership, inputs, and accepted outputs on MT4.
  2. 02
    MapTranslate orders, positions, indicators, events, prices, and symbol properties explicitly.
  3. 03
    CompareRun matched periods and compare decisions before comparing final profit.
  4. 04
    ExplainDocument intentional differences and reject unexplained behavioural drift.

Freeze the reference

Before conversion, save the old version, inputs, platform build, symbol settings, date range, data assumptions, and a decision log or trade list. If the source contains ambiguous behaviour or known defects, decide whether the goal is strict reproduction or a controlled correction. That choice must not be hidden inside the migration.

Map platform differences

MT4 order handling and MT5 position handling are not identical, especially when netting and hedging account modes are considered. Indicator handles, buffer copying, asynchronous trade results, price precision, tick value, filling modes, and tester events also require explicit treatment.

Compare decisions

A final balance can look similar while individual signals have drifted. Parity testing should therefore compare bar times, signal states, requested prices, volume calculations, stop distances, modification paths, and reasons for blocked trades. Differences caused by data or platform rules should be identified rather than averaged away.

Operate on MT5

After historical comparison, test restarts, partial fills, rejected requests, symbol suffixes, account mode, missing history, and multiple positions. The converted system also needs current logs and documentation; otherwise future changes can reintroduce the same drift.

  • Preserve an immutable MT4 reference build.
  • Choose MT5 netting or hedging behaviour deliberately.
  • Recalculate risk from MT5 symbol properties.
  • Compare event-level decisions, not only equity curves.
  • Document every accepted difference.

Questions you may have

Can an MT4 EA be copied directly into MT5?

Usually not. Some language is familiar, but trading, indicators, events, positions, and testing need deliberate conversion.

Should MT4 and MT5 backtests be identical?

Not necessarily. Data and platform models can differ, but every material difference should have an understood cause.

POLARIS / R13

Approve behaviour, not just compiling code

Scroll the diagram horizontally or open it at full size.

Approve behaviour, not just compiling code
Educational design example — values and states are not live performance.

Align timestamps and expected outcomes; record differences explicitly.

Open full diagram ↗

Evidence in practice

Approve behaviour, not just compiling code

A migration contract compares observable events. The platform change may require adaptation, but every adaptation should be classified before the MT5 result is accepted as a continuation of the MT4 strategy.

Platform difference mapped to a visible test
Difference Possible visible effect Parity test Classification
Orders, deals and positions Exit history or state recovery differs Trace request → deal → position → exit Defect unless mapped
Hedging vs netting Opposite order opens a second ticket or reduces one position Replay BUY 1 lot then SELL 0.4 Approved account-mode rule
Indicator access Late or EMPTY buffer values Compare source time and buffer readiness Defect if silently substituted
Trade events One request produces several updates Reorder and duplicate event replay Implementation adaptation
Symbol properties Volume, stop or margin changes Recalculate on both specifications Data difference
Time and sessions A boundary trade appears or disappears Compare UTC and server timestamps Approved only if documented

On a hedging account, BUY 1.0 followed by SELL 0.4 can leave two positions, gross 1.4 and net +0.6. On a netting account it normally leaves one net BUY 0.6 position. The strategy must say whether it depends on two ticket identities or only net exposure.

The parity log should align event ID, source-bar time, requested volume, request code, deal volume, position state, stop and exit reason. Tolerances must match the source: price tolerance no smaller than executable tick size; money tolerance tied to rounding and currency conversion; time tolerance only where event delivery timing can vary. Classify mismatches as defect, approved platform change or non-comparable data.

What to verify

  • Freeze at least six representative scenarios before conversion.
  • Compare event traces before aggregate profit and explain every allowed tolerance.
  • Re-run all approved differences as regression tests after later changes.

Limits of this example

Identical equity curves can hide different trade identities and recovery behaviour; different curves can also come from non-comparable feeds rather than code drift.

Research quality record

Editorial ownership and primary references

Reviewed by POLARIS Research

Evidence scope

This article combines official platform behaviour with recurring, anonymized implementation patterns. Exact trading rules and client material are excluded.

Primary references

These references support platform behaviour or research concepts. They do not validate POLARIS performance and do not guarantee future results.

Related research and applications

Explore the next relevant layer

Move between focused research, system engineering and portfolio construction without losing the context of this page.

Expert Advisors and automated trading systems →Risk controls inside every Expert Advisor →

Related research