Magnolia 6.2 to 6.3 upgrade unblocked in a day: the blocker was the Content Editor module

B-FY is a Spanish cybersecurity company running its site on Magnolia. Its technical team had decided to upgrade from 6.2 to 6.3 and had been trying for three weeks without getting there.

An upgrade that fails without saying why is the hard case: the error surfaces far from its cause, and the backward compatibility that should help is exactly what hides it.

Magnolia 6.2 is the transition from the 5UI interface to 6UI, with the jump from Vaadin 7 to Vaadin 8.

• Deep changes between interfaces: moving from 5UI to 6UI changed class namespacing, parameters and YAML definitions.
• The safety net masks the problem: 6.2 keeps backward compatibility, so what is wrong keeps working until it does not.
• Three weeks without a root cause: the internal team had ruled out the obvious without reaching the origin of the blocker.

The cost was not the hours but staying pinned to an old version, which is how the debt that later forces a full project accumulates.

The work was diagnosis rather than development: the client's blocks were already in 6UI syntax, so the error was not where everyone was looking.

With the content ruled out, the environment was left. The cause sat in a module that Magnolia's own bundle installs.

Where the blocker actually was

• Magnolia webapps and bundles install Content Editor on the 1.3.x branch, which requires 5UI definitions.
• B-FY blocks were already defined in 6UI, so the module and the content were asking for incompatible things.
• The symptom showed up in the blocks and the cause was in the version of the module reading them.

The fix

• Content Editor module and all its dependencies upgraded to the 2.1.x branch, through a patch in the WebApp POM.
• Stories App moved to the 2.x branch, on the same dependency.
• Remaining incompatibilities of the same kind resolved one by one as they surfaced.

Verification and jump

• Checked on the spot: the editor working and blocks rendering on a test page.
• The jump itself was almost instant, applying the patch and updating the webapp, with no service window.

Architecture and technology

• Magnolia CMS 6.2 to 6.3, with the 5UI to 6UI interface transition on Vaadin 8.
• Content Editor module 1.3.x to 2.1.x and Stories App to 2.x, via a patch in the WebApp POM.

Learn more about Magnolia support and maintenance.

Learn more about software development.

Three weeks of attempts against one day of work, and the entire difference was diagnosis rather than execution.

Starting point

• Three weeks of attempts by B-FY internal team without completing the upgrade.
• Instance pinned to 6.2, with the root cause unidentified.

Results

• One day of work to identify the root cause and resolve it.
• Zero downtime: the jump was almost instant, with no service window and no interruption for end users.
• Result verified on the spot, with the editor working and blocks rendering.
• They run on 6.3 today, stably.

Strategic impact

• The instance stopped accumulating version debt and is in shape to keep upgrading.
• With the cause documented, the internal team can recognize the same pattern on the next jumps.