We don't have the exact date yet.
The switch will happen with the implementation of IFS Cycle 50r2.
As of September 2026 the plan is:

• GRIB2 test data converted from IFS Cy50r1 output is available in MARS from September 2026. It can be brosed from the following link: https://apps.ecmwf.int/mars-catalogue/?class=od&stream=oper&expver=2250
• IFS Cycle 50r2 e-suite will start in Q4 2026
• Full implementation in Q2 2027

Once IFS Cycle 50r2 becomes operational, the whole model output, through dissemination and MARS retrieval - will be GRIB2 only. GRIB1 production stops at that point. There is no permanent dual-format service.

The parallel period comes before the switch: while IFS Cycle 50r1 remains operational (mixed GRIB1/GRIB2), the IFS Cycle 50r2 e-suite will run alongside it producing full GRIB2, so users can test both simultaneously.

We are planning for at least six months of parallel running between the start of the IFS Cycle 50r2 test period (e-suite) and the full implementation. There is no plan to extend this period.

No. Whatever was archived in GRIB1 stays in GRIB1 permanently. If you retrieve forecast output for dates before the migration you will still get the historical GRIB1/GRIB2 mix.

Because of this, our own tools (ecCodes, Earthkit and the rest) will continue to support GRIB1 processing in the future.

Three ways to find out what breaks:

• Run your existing scripts against the GRIB2 test data once it is in MARS
• Check the documented parameter changes on the MTG2 Confluence pages (The mapping of parameters in GRIB1 and GRIB2).

For dissemination, we will automate the requirement changes in PREd, users will not need to rewrite their dissemination requirements themselves.

In principle any version from 2.42.0 onwards can interpret the GRIB metadata both before and after the migration. 2.42.0 is the minimum needed for the static sample dataset.

But the updates are still being released, the current recommendation is simply to use the latest release.

Yes. We don't intend to change anything in ecCodes regarding reading and writing GRIB1, we also need that capability for the legacy GRIB1 in MARS.

Encoding your own data to GRIB1, using the GRIB1 samples/templates, and linking your programs against the new ecCodes libraries all continue to work as before.
The difficulty is only when you try to take ECMWF's new GRIB2 data and write it back out as GRIB1 (see next question).

In theory, yes, but - this is not supported and is strongly discouraged.
The GRIB2 → GRIB1 mapping is not guaranteed to be unique and a loss of information is possible. For several parameters it will simply not be possible.

Yes, provided you use a recent ecCodes, but it doesn't guarantee you the correctly encoded MTG2 equivalent GRIB2 data and is not reccomended either. For many parameters the paramId or shortName changes as well, and grib_set cannot change that for you. Consult the parameter mapping pages.

As of September 2026, the static snapshot of one representative day's data encoded in full GRIB2 format is available through:

• MARS archive as the experiment 2250 (expver=2250): https://apps.ecmwf.int/mars-catalogue/?class=od&stream=oper&expver=2250
• Open data portal: https://data.ecmwf.int/mtg2_sample/
• On the ECMWF HPC:  /ec/vol/mtg2_sample Documented under Migration to GRIB2 - sample static dataset. Parameters for which the units will change are provided both with current ECMWF units and with the WMO-recommended units

Currently IFS Medium-range control (ex-HRES) and ensemble including type=ssd and levtype=ml are provided. IFS Medium-range postprocessed parameters, IFS sub-seasonal and IFS Atmospheric Composition (CAMS) sample data will follow later.

There is no such keyword or a switch in MARS language or dissemination.

The Parameter Database describes what ecCodes can encode and decode, not how the archived data is actually stored. Dissemination can only send what exists in the archive, in the form it was stored, there is no on-the-fly re-encoding. Today the operational IFS produces parameters in the mix of GRIB1 and GRIB2 and AIFS already produces them in GRIB2 format.

These are the most disruptive changes, because GRIB2 expresses the processing period through metadata rather than through a distinct parameter name. The period-suffixed parameters give way to a single parameter plus a time span:

$ grib_ls -w endStep=24 -m -P shortName,paramId  …_10fg6_….grib2
shortName   paramId   step   timespan
max_i10fg   237318      24      6h

So 10fg / 10fg3 / 10fg6 (paramIds 49 / 228028 / 123) become max_i10fg (paramId 237318) with timespan= 3h, 1h or 6h. The same pattern applies to mx2t / mx2t3 / mx2t6 and mn2t / mn2t3 / mn2t6.  

Note you need a recent ecCodes to see this decoding — older versions report the field as plain 10fg.

They are coming.

Parameters such as maxswhi, 10fgi, 10wsi, capesi, capei, sfi, 2ti, mx2ti, mn2ti, tpi are missing.
They all belong to the Extreme Forecast Index / Shift of Tails family and are planned for a future ecCodes release. We don't have a date yet.

The general principle: absence from the GRIB2 side of the parameter database means the encoding has not been defined yet, not that the product is being withdrawn.

Yes, for some parameters, and this is a separate change from the edition switch itself. We are moving from ECMWF-specific units to the WMO-recommended ones. Two most notable examples are precipitation parameters (including total precipitation, convective precipitation, large-scale precipitation, snowfall, runoff etc)

The static sample dataset provides both flavours side by side (files with and without a _wmo_units suffix) precisely so users can test. 

You can find the full mapping on the following page: Migration to GRIB2 - changes to encoding of parameters