Your converted Expert Advisor compiled without a single error, and that is the part nobody should find reassuring. The characteristic failure of an MT4 to MT5 migration does not produce anything wrong to find — it produces an absence, something that should have happened and didn’t. At barmenteros FX we have spent years cleaning up conversions that passed every check their owner knew how to run, and the pattern is always the same: the compiler, the Strategy Tester and the demo account are error detectors, and this failure class does not produce errors.
A clean compile plus a matching backtest is not weak evidence that a conversion worked. It is the specific pair of signals least able to detect the way conversions actually break.
It matters more now than it did a month ago. Since MetaTrader 5 build 6060 (released 23 July 2026), the MetaEditor your EA already lives in ships an AI assistant, free on the MQL5 Lite plan, and one of MetaQuotes’ own published example prompts for it reads: “Convert this MQL4 Expert Advisor to MQL5 using modern language features and the Standard Library.” The conversion is now one prompt away. The checking is not.
Why brokers are now publishing hard MT4 end-dates
The migration deadline stopped being hypothetical: at least one broker has published a dated shutdown schedule in advance.
OANDA’s Japanese entity, OANDA Japan Inc, announced a three-stage MT4 decommission on 27 March 2026:
| Date | What stops |
|---|---|
| 2026-03-27 | New MT4 sub-account creation suspended, demo and live |
| 2026-09-25 | New MT4 orders suspended, demo and live |
| 2026-11-27 | MT4 service terminated entirely — no login, no trades |
Two details matter more than the dates. The first is the stated reason, quoted in the trade press: “MT4 has been on the market for a long time, and MetaQuotes no longer provides system maintenance for it. Therefore, we have determined that it is difficult to continue meeting the latest security requirements.” That is a broker classifying MT4 as a security and compliance liability — a different argument from a developer saying the same thing.
The second is what the broker is *not* offering: the recommended destinations are MT5, fxTrade or TradingView, and no automated account, position or Expert Advisor migration is described for any of them. The conversion is the client’s problem.
Two caveats, because precision matters here. This is OANDA’s Japanese subsidiary, on its own servers, for its own client base — nothing in the announcement says the group’s other entities are dropping MT4. And the schedule reaches us through FX News Group, which quotes the notice without linking the primary document; we have not seen the broker’s own text.
What automated MT4 to MT5 conversion actually gets right
A no-code converter at $12 to $39 a month — or the AI assistant MetaQuotes now ships inside MetaEditor at no cost — is a reasonable tool for a real category of Expert Advisor, and pretending otherwise would be dishonest.
Token-level translation handles these well:
- Single-signal indicator EAs — one indicator in, one entry condition out, no state carried between ticks.
- Straightforward API renames — the large surface of MQL4 calls with direct MQL5 equivalents.
- One-position-at-a-time logic — open, manage, close, repeat, with no partial closes and no recovery layer.
If that describes your EA, paying a developer four figures to convert it is poor value. Our argument is not that these tools are bad at translation — they are good at it. Our argument is that translation is not the risky part, and that the method most people use to check the result cannot see the risky part at all.
The failure class that produces nothing to find
The mechanism behind every case below: MQL5 code can be valid, idiomatic and a faithful token-for-token rendering of the MQL4 original, and still mean something different, because the platform semantics underneath the identical-looking call changed. Nothing is malformed. The EA does exactly what it was told — and what it was told meant one thing on MT4 and another on MT5.
The same is true of a second prompt from the same MetaQuotes list, “Analyze this MQL5 code, identify potential issues, explain their causes, and provide a corrected version”: an analyzer can flag what looks wrong in the file. It cannot flag a break-even move that never fired, because nothing in the file says one was expected.
Three client cases, anonymized, each showing a different way an absence hides.
The break-even EA that reported normal operation
A break-even manager compiled clean, ran clean in the Strategy Tester, and produced a plausible equity curve. Nobody opened the logs to confirm the break-even moves were firing; nothing had errored, so there was no reason to look.
In live trading it held three open positions and moved none of them to break-even. The loop iterating `OrdersTotal()` found a count of zero and did nothing.
The cause is documented behaviour, not a bug. In MQL5, `OrdersTotal()` returns the number of pending orders. The documentation is explicit: “Do not confuse current pending orders with positions… An order is a request to conduct a transaction, while a position is a result of one or more deals.” Open positions are counted by `PositionsTotal()`. On MT4, the same function name covered both. So a faithfully recompiled MT4 loop, on an MT5 account holding three open positions and no pending orders, correctly iterates over nothing.
The trader’s risk sat fully exposed on every trade while the EA reported normal operation. Time to detection: indefinite. There was no event to notice — a missing break-even move is not an error, it is an absence, and you only catch an absence if you go looking for it.
The crossover EA whose backtest was mediocre, not broken
A moving-average crossover system was migrated by the book. It created the indicator handle correctly. It called `CopyBuffer()` correctly. It never set the destination array as a series.
The MQL5 documentation states the consequence directly: “No matter what is the property of the target array — as_series=true or as_series=false. Data will be copied so that the oldest element will be located at the start of the physical memory allocated for the array.” An MQL4 developer reads index 1 as “the previous bar” out of habit. After the copy, index 1 is near the oldest end of the requested range. The EA was comparing crossovers that had happened days earlier.
On the chart the entry arrows looked random. But the detail that makes this case worth more than the others is that the wrong-end read applied uniformly to every bar, so the equity curve came out mediocre, not obviously broken.
That difference decides what happens next. A broken backtest gets investigated; a mediocre one gets re-optimised. The trader spends a weekend tuning parameters against a curve produced by an EA reading the wrong end of a buffer, and every hour of that work fits the parameters more tightly to the bug.
The session filter that cleared its threshold on nothing
A session-filter EA used a tick counter for activation: once 20 ticks had arrived after the session open, it would start evaluating entries. On MT4 that had served as a workable proxy for “the market is actually trading.”
After migration it ran two weeks on demo, then was found opening positions in the exact low-liquidity window it had been built to avoid.
Nothing in the code was wrong. The proxy was wrong. It assumed one tick meant one price move, and MT5 does not define a tick that way: the `MqlTick` structure carries flags (`TICK_FLAG_BID`, `TICK_FLAG_ASK`, `TICK_FLAG_LAST`, `TICK_FLAG_VOLUME`, `TICK_FLAG_BUY`, `TICK_FLAG_SELL`) because a tick marks a change in any one of those fields. Bid and Ask are flagged separately, and on instruments that carry a last-deal price, a tick can arrive with no move in Bid or Ask at all. On this account the counter had cleared its threshold before real price movement began.
Two weeks on demo did not catch it, because a demo account tests whether the code runs. It does not test whether the assumptions still hold.
The same pattern, three shorter versions
| What was converted | What went missing | How it surfaced |
|---|---|---|
| Hedging EA managing its own inventory | MT5 execution closed positions the EA believed it still held; internal counter said 2, account held 0 | Three weeks of managing a ghost inventory, no error thrown |
| Lot sizer producing clean 0.10–0.30 lots | Intended 0.13 lots normalized against a different volume step | Configured 1% risk quietly became something else |
| Grid EA on a VPS | Overnight reboot triggered `OnInit()`; position scan found zero; counter reset and opened a fresh level on top of live positions | Roughly double the intended exposure by morning |
The first is the netting-versus-hedging problem every conversion guide already covers. We mention it only in passing: it is the failure people do look for, which is exactly why it is the least dangerous of the six. The full write-up is in our earlier piece on why recompiling is the easy part. The break-even, crossover, lot-sizer and grid cases come from a later one, four migration failures that pass the backtest.
A five-check MT4 to MT5 parity test you can run yourself
If the failures are absences, the only way to detect them is to define in advance what should be present. That is the entire logic of this checklist — not five good habits, but the direct consequence of the problem. Run these in order; each names what failure looks like, because “it ran without errors” is not a result.
- Audit the position model before anything else. Confirm whether the target account is netting or hedging, then confirm your EA’s close and modify logic addresses positions the way that account actually behaves. Failure looks like: logic that targets individual tickets on an account that merges them.
- Grep the converted source for every count and lookup that changed meaning. `OrdersTotal()`, order-selection calls, predefined price variables, point and digit handling. For each one, answer out loud what it returns on MT5. Failure looks like: a call you cannot explain, which compiled anyway.
- Run a same-period backtest against the MT4 original with a stated tolerance. Decide the acceptable divergence in trade count and entry timestamps before you look at the result. Failure looks like: a curve that is merely worse — resist the urge to re-optimise, and go find out why.
- Log every order call’s return code, and log the actions that should have fired. This is the check that catches absences specifically. If a break-even move should happen, log that it happened. Failure looks like: silence where a confirmation line should be.
- Force the second-position case deliberately. Three of the six cases in this article only surfaced once the EA held more than one position. Do not wait for the market to arrange that. Failure looks like: the first case behaving correctly and the second one not.
Check 4 is the one the break-even EA’s owner had not run, and the one that would have caught it on day one.
When a no-code converter is the right answer
The honest segmentation follows from the thesis, not from what we would prefer to sell.
A no-code tool — or the prompt in your MetaEditor — is genuinely the right call when your EA has no absences that can matter: a single-signal indicator system, no state carried across ticks, no position management, no recovery logic. Run checks 1 through 3, keep the change, and spend the money elsewhere.
It becomes the wrong call the moment the EA holds state between ticks or manages more than one position. Money-managing systems, grid and martingale logic, partial closes, break-even and trailing layers, anything that reconstructs its own state after a restart — every one of those is defined by things that must happen — which means every one of them can fail by omission.
If your EA is in the second group and you have no source code, the checklist above is not a shortcut around a professional conversion. It is a description of what one consists of — which is where our MT4 to MT5 migration work actually goes: parallel testing, source and target running side by side before cutover.
The tool writes the code; it does not notice what didn’t happen
AI converts MQL fluently, it will keep getting better at it, and as of July 2026 it does so from inside MetaEditor with nothing to install. That was never the limitation. The limitation is that translation operates on what is present in the source, and this entire failure class is defined by what is absent from the result.
MetaQuotes’ own settings concede the point. The same build that added the assistant added a permission for it: you can allow AI-initiated trading operations, prohibit them, or require manual confirmation. The vendor put a human gate in front of its own assistant.
Neither a compiler, a tester nor two weeks on a demo account can flag a move that never fired. Only you can — and only if you wrote down what should happen before you went looking.
That is the same pattern we described in AI-generated MQL that compiles and fails live: the code is fluent, the output is confident, and the consequence still belongs to whoever is holding the account.
Leave a Reply