Upgrading from Magnolia 6.2 to 6.4

This guide is under active development and will be finalized for the Magnolia 6.4 GA release. Steps and details may change.

This guide walks you through upgrading Magnolia DX Core from 6.2 to 6.4 in a single, unified process. Follow each section in order. Use the checkpoints at the end of every section before proceeding. Critical steps are indicated with a icon.

This guide is for developers, integrators, and DevOps engineers with in-depth Magnolia experience who manage project code, configuration, and runtime environments.

Prerequisites

This section lists what you must review and prepare before starting the upgrade.

Before you upgrade:

Check what your current version of Magnolia is and if all your custom modules, extensions, and incubators are compatible with 6.4 (only Tier 1 incubators are compatible at this time).
Review the release notes for versions between your current and target versions.
Review the certified stack.

Environment and backups

This section covers preparing the runtime environment and creating and verifying full backups.

Upgrade to the latest patch of your current Magnolia version (for example, if on 6.2.x, go to the latest 6.2.x before starting the 6.2→6.4 upgrade).
Clean and optimize your Magnolia instance: remove unused modules/data, reindex JCR.
Back up your system.
Test the backup and the ability to restore or roll back.
Verify that your Java environment is 17 (or newer, as certified by Magnolia 6.4).
Review the certified stack again for server, servlet container (Tomcat 10/11), and database support.

Checkpoint

Upgraded to the latest 6.2.x first and cleaned unused data/reindexed?
All unused modules removed?
Full backup taken and test restore verified (JCR, DB, files)?
Java 17+ verified on target runtime?
Certified stack requirements (OS, servlet container, DB) confirmed?

Dependency and platform updates

This section guides you through updating Magnolia, Jakarta, servlet container, and related build dependencies.

If you have custom code, add the rewrite-maven-plugin to your pom.xml file to automate the migration from javax to jakarta packages. This step effectively alters your code.

Click to see how to declare the rewrite-maven-plugin

Add the following to your pom.xml under <build><plugins>:

  <plugin>
        <groupId>org.openrewrite.maven</groupId>
        <artifactId>rewrite-maven-plugin</artifactId>
        <version>6.22.1</version>
        <configuration>
          <activeRecipes>
            <recipe>org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta</recipe>
          </activeRecipes>
        </configuration>
        <dependencies>
          <dependency>
            <groupId>org.openrewrite.recipe</groupId>
            <artifactId>rewrite-migrate-java</artifactId>
            <version>3.20.0</version>
          </dependency>
        </dependencies>
  </plugin>

Run the following Maven command to migrate your code from javax to jakarta packages before updating your Magnolia version:
```
mvn org.openrewrite.maven:rewrite-maven-plugin:run -Drewrite.activeRecipes=org.openrewrite.java.migrate.jakarta.JavaxMigrationToJakarta
```
Run this migration while your project is still on 6.2.x and compiling successfully. This ensures the rewrite tool can analyze and update your code cleanly before you update to 6.4 dependencies.

Update the parent pom.xml in your webapp. Set <magnoliaBundleVersion> to 6.4.0-rc3.
If you use extension modules, either update their versions individually or use the latest extensions BOM compatible with 6.4.
Replace javax.* dependencies with their Jakarta EE 10 equivalents in all modules.

How to update Maven dependencies from javax group IDs to their Jakarta equivalents
To update you must:
- Use the latest supported Tomcat release.
  
  For other servlet containers, see the Certified stack.
- Update Maven dependencies from javax group IDs to their Jakarta equivalents.
  
  Example dependency changes
  
  javax.inject:javax.inject:1 >> jakarta.inject:jakarta.inject-api:2.0 javax.json:javax.json-api >> jakarta.json:jakarta.json-api:2.0
  
  Do not convert the Jackrabbit JCR APIs.
  
  Keep javax.jcr imports intact, for example:
  
  import javax.jcr.Node; import javax.jcr.NodeIterator; import javax.jcr.RepositoryException;
  
  To avoid duplicate classes on the classpath, replace all javax dependencies with their Jakarta EE 10 equivalents.
  
  Versions of these dependencies are provided in Magnolia’s third-party library BOM via the jakarta.jakartaee-bom import. For more details, see Certified stack: Maven coordinates.
  
  If your project depends on vaadin-server or vaadin-compatibility-server, update the artifactId by appending -mpr-jakarta to ensure compatibility with Jakarta EE.
  
  For example:
  
  Change vaadin-server to vaadin-server-mpr-jakarta.
  
  Change vaadin-compatibility-server to vaadin-compatibility-server-mpr-jakarta.
  
  Verify that no non-Jakarta Vaadin dependencies are included by running:
  
  mvn dependency:tree -Dincludes=com.vaadin:vaadin-server,com.vaadin:vaadin-compatibility-server -Dverbose=true
  
  For additional details on integrating Vaadin MPR with Maven for Vaadin 8, see Vaadin: How to Integrate Vaadin MPR with Maven for Vaadin 8.
Compare your magnolia.properties file to the current defaults for 6.4 and merge in any required new properties. See the Magnolia CE and DX Core base files.
If using custom Docker images, update to use base images certified for Magnolia 6.4.

Checkpoint

BOMs and all dependencies updated for 6.4 and Jakarta EE 10.
No javax.* dependencies remain? Vaadin MPR-Jakarta applied where needed?
Servlet container/base images/Java JDK match the certified stack?
magnolia.properties diffed against 6.4 defaults and aligned?

Code and configuration updates

This section details project-level code and pre-startup configuration changes required for 6.4, including MicroProfile configuration, security, search, forms, sites, REST endpoints, database settings, and scripts/automation updates.

Update all publishing receiver and external configuration sources as required. Since 6.3, Magnolia uses MicroProfile Config, adding state-of-the-art flexibility for external instance configuration. Magnolia expects MicroProfile-managed publishing receiver configs for instance clustering.

How to configure publishing receivers
1. Magnolia’s MicroProfile implementation can ingest configurations from either a traditional Java properties file or a YAML file. Only one is required; choose the format you find clearer or more maintainable:
  
  microprofile-config.properties: Traditional Java properties file format with simple key=value syntax.
  
  microprofile-config.yaml: YAML format with a hierarchical structure, often more readable for complex configurations.
  
  microprofile-config.properties
  
  microprofile-config.yaml
  
  magnolia.publishing.receivers[0].name=magnoliaPublic-0 magnolia.publishing.receivers[0].url=http://dev-magnolia-helm-public-0-svc:8080 magnolia.publishing.receivers[1].name=magnoliaPublic-1 magnolia.publishing.receivers[1].url=http://dev-magnolia-helm-public-1-svc:8080
  
  magnolia: publishing: receivers: - name: magnoliaPublic-0 url: http://dev-magnolia-helm-public-0-svc:8080 - name: magnoliaPublic-1 url: http://dev-magnolia-helm-public-1-svc:8080
2. Place the file in a folder that is configured as an external configuration source. In Magnolia, this is commonly the mounted-config directory (or any folder you specify). To point Magnolia to that directory, pass magnolia.config.locations as a system property (for example, using Tomcat VM options in setenv.sh).
  
  Tomcat VM option for magnolia.config.locations
  
  -Dmagnolia.config.locations=/opt/magnolia/mounted-config
The default receiver for local development (magnoliaPublic8080) has been removed.
Receiver example for local development
magnolia.publishing.receivers[0].name=magnoliaPublic magnolia.publishing.receivers[0].url=http://{host}:{port}/magnoliaPublic (1) magnolia.publishing.receivers[0].enabled=true
1 Put the path magnoliaPublic in the URL for local development.
If you use AI Accelerator or Cloudinary External DAM, obtain your new 6.4 license and set it in your instances before launching Magnolia for the first time.
If you configured IP security, update your filter configuration to use MicroProfile config. Magnolia 6.4 no longer bootstraps ipSecurity by default. Either remove the filter manually or migrate the configuration to MicroProfile; otherwise, logs will contain repeated warnings. See IP security.
If you have custom Java-based REST endpoints, update them to use the REST 3.0+ packages, such as:
- info.magnolia.rest.delivery.DeliveryContext (deprecated: info.magnolia.rest.delivery.jcr.v2.DeliveryContext).
- info.magnolia.rest.delivery.OutputStreamWrapper (deprecated: info.magnolia.rest.delivery.jcr.OutputStreamWrapper).
Global Search replaces Find Bar and is managed in the periscope-core module.
If you want to use the JavaScript UI module custom fields, enable the New UI Forms integration and remove legacy listeners.
1. Add the integration dependency to your webapp pom.xml (the version is managed by the Magnolia BOM):
  <dependency> <groupId>info.magnolia.ui</groupId> <artifactId>magnolia-ui-framework-javascript-warp-integration</artifactId> </dependency>
2. A form that includes a javascriptField probably has the implementationClass: info.magnolia.ui.javascript.form.FormViewWithChangeListener, which causes the form to fall back to Vaadin. If you want to upgrade the form to the New UI, follow these steps:
  1. Comment out all the JS fields.
  2. Comment out the implementationClass.
  3. Check whether the form renders in the New UI. If not, adjust the form definition until it does.
  4. Uncomment the JS fields.
  5. Delete the implementationClass.
  The above steps avoid the state where some other problem forces a fallback to Vaadin, but the implementationClass is missing, which causes the JS fields changeListener to not work.
If you rely on MySQL, update the repository config to use Connector/J. For MySQL Connector/J 8.x (and later), use jackrabbit-bundle-mysql8-search.xml, available at /WEB-INF/config/repo-conf/.

Checkpoint

6.4 license installed and recognized?
Publishing receivers configured via MicroProfile and active?
IP security handled (MicroProfile config if used; no stray JCR /server/filters/ipSecurity)?
Global Search in place (Find Bar removed); any custom search config moved to periscope-core? They automatically fall back to Vaadin forms where feature parity doesn’t exist with the New UI Forms.
MySQL repo config uses /WEB-INF/config/repo-conf/jackrabbit-bundle-mysql8-search.xml?
Scripts/automations updated for new registry paths (no legacy definition paths for filters/columns/views).

Module updates

This section explains module-specific migrations and removals needed to align with 6.4-compatible modules.

Remove old compatibility modules (categorization, diff, workflow compatibility, etc.).
If you use CKEditor 4 customizations, we recommend you migrate to CKEditor 5. New UI forms require CKEditor 5, which is the default in Magnolia 6.4.

If you must keep CKEditor 4, set ckEditorVersion: CKEDITOR_4. See rich text field properties for details.

How to migrate to CKEditor 5
- Recreate any custom plugins or toolbars with CKEditor 5 equivalents.
- For custom builds or plugins (e.g., General HTML Support), see CKEditor 5 customization.
- If you decorate link behavior, note that rel/target support was added in the CKEditor 5 MgnlLink plugin as of 6.3.9.
Preview all migrated content from CKEditor 4 to ensure it displays and publishes correctly. See the CKEditor 5 migration guides (ckeditor.com/docs/) and the compatibility tables for configuration and plugin differences.
If you use SSO 3.1 or earlier, you must migrate configurations per the model introduced in 4.0.0. This includes compatibility adjustments, mandatory configuration changes, removal of certain classes, optional enhancements like JCR-based fallback login, and considerations for users of the SSO Login Extension module. For specific actions and modifications needed to ensure a smooth upgrade, see Upgrading to SSO 4.0.0. Once these steps are followed, you can upgrade to Magnolia 6.4-compatible version SSO 5.0.
If you use Hybrid Assets incubator, the functionality offered by the incubator module is replaced by DAM 5.0 and later. If you used the incubator module, you can optionally use the migration scripts to move your assets to the new implementation.
If you use DAM Focal incubator (dam-focal): In 6.2 and 6.3, DAM Focal was provided as an incubator module. In 6.4, it is promoted to a DX Core extension with a new module name image-focal. The Magnolia 6.4-compatible version of this extension is 2.0. To upgrade, uninstall the dam-focal incubator module and update dependency management to use the image-focal extension version 2.0.x. Existing focal point data is preserved when switching modules.
If you use Live Copy, Dynamic Forms, or other incubator modules that configured a custom I18nAuthoringSupport in JCR, you must provide it via your module descriptor from 6.3 on. Deprecated methods have been removed and default implementations consolidated. Configure your class as a regular component mapping instead of an observed JCR component.

Example: Configure custom I18nAuthoringSupport in the module descriptor
<component> <type>info.magnolia.ui.api.i18n.I18NAuthoringSupport</type> <implementation>com.custom.i18n.CustomI18nAuthoringSupport</implementation> <scope>singleton</scope> </component>
If you use Content Editor module, migrate all v1 definitions to v2 and update multilanguage stories as needed.
If you use CTSX DeepL Translator incubator, move the translation provider configuration from /modules/content-translation-support-ext-deepl/config/Deepl to /modules/content-translation-support-ext-deepl/config/translationProviders/Deepl.

Checkpoint

Compatibility modules removed (categorization/diff/workflow compat, etc.)?
SSO 3.1→4.0 (config migrated) and then to 6.4-compatible SSO 5.0?
Hybrid Assets content migrated to DAM 6+?
DAM Focal→image-focal 2.0; focal data preserved?
Custom I18nAuthoringSupport moved from JCR to module descriptor?
Content Editor v1 definitions migrated to v2?
CKEditor: either ckEditorVersion: CKEDITOR_4 where needed or CKEditor 5 migration completed?

Verification and runtime updates

This section covers starting Magnolia on a staging instance and completing runtime configuration updates. Use logs and the Definitions app to validate changes (roles, sites, REST, scripts) and confirm the system is ready for go-live.

Start Magnolia 6.4 in a non-production (staging) environment.
Review and update group and role assignments: Magnolia roles and groups changed in 6.3 and later. Magnolia 6.3 introduced a unified role naming convention <module>-<privilege> (for example, pages-publisher, admincentral-editor). Review and update your user groups and roles to align with the new scheme.

Click to see role and group changes
- The publishers group now includes additional roles with read/write permissions on pages and assets. Update your configuration if this exceeds your intended access level.
- New developer group introduced.
- New roles added, including:
  
  admincentral-developer
  
  admincentral-editor (can block access to URLs)
  
  asset-editor
  
  category-editor
  
  dam-app-core-editor
  
  dam-app-jcr-editor
  
  definitions-app-developer
  
  diff-viewer
  
  graphql-developer
  
  imaging-editor
  
  marketingTag-editor
  
  page-editor
  
  pages-app-editor
  
  resources-editor
  
  story-editor
  
  tour-editor
  
  tourCategory-editor
- Roles renamed:
  
  editor → workflow-editor
  
  publisher → workflow-publisher
- Roles removed:
  
  contact-base
  
  rss-aggregator-base
Update all site/multisite configurations. Since Magnolia 6.3, multisite definitions work like any other definition type: they’re collected in a conventional registry, support YAML definitions natively, and are displayed in the Definitions app. YAML is now required for new features, and decorations of legacy JCR multisite configurations are no longer supported.

How to update site and multisite configurations
- Move site configuration to <module-name>/sites/ in your light module. See the following example path and configuration.
  
  /travel-demo/sites/travel.yaml
  
  templates: class: info.magnolia.module.site.templates.ReferencingPrototypeTemplateSettings prototypeId: travel-demo:pages/prototype availability: templates: home: id: travel-demo:pages/home standard: id: travel-demo:pages/standard searchResultPage: id: travel-demo:pages/searchResultPage pur: id: travel-demo:pages/pur enableAllWithRenderType: freemarker: freemarker spa: spa theme: name: travel-demo-theme i18n: class: info.magnolia.cms.i18n.IetfI18nContentSupport enabled: true fallbackLocale: en locales: en: enabled: true languageTag: en de: enabled: true languageTag: de cors: travel: uris: rest: patternString: '/.rest/*' allowedOrigins: all: '*' allowedMethods: get: GET allowedHeaders: accept: Accept content-type: Content-Type origin: Origin x-pingother: X-PINGOTHER x-requested-with: X-Requested-With
  
  This example configuration is also available in the Magnolia Bitbucket.org repository.
- Provide a fallback site configuration in <module-name>/sites/fallback.yaml. If none is provided, Magnolia infers one automatically using the English or German locale. Fallback sites must be nodes, not folders.
Sites in multisite/config/sites are still loaded for backward compatibility but can’t be decorated.

Site app removed

The Site App module and app were removed in Magnolia 6.3.0. Verify site definitions and their source locations in the Definitions app.
Review configuration decorations. All YAML decorations must have config in the filename. Make sure that your decorating configuration files have config in the filename, for example, /rest-services/decorations/cache/config.contentCaching.yaml.
Update App Launcher layout.
- Remove deprecated properties, such as group color, and old group IDs used in automation.
- Align launcher groups, categories, and app references with the 6.3+ launcher model.
- Confirm that generated layout nodes or files match current IDs.

Review app workbench and search configuration. In-app search and filters are now enabled by default in browser subapps. If your custom apps rely on column-level filterComponent definitions or have custom data providers, update them to use the new workbench-level filters structure and update your custom data provider implementation to support the unified search behavior.

Click to see details about app workbench and search configuration changes

The search field is enabled by default in all apps. If your custom browser subapp doesn’t support search, disable the search field by setting the searchEnabled property to false.
If you don’t have workbench filters configured, the system:
- Converts combobox fields used as filters in column headers into dropdown filters.
- Converts all text fields into the default search field. For example, in the Pages app the Name (previously Page) and Title column fields become searchable using the default search field.
If you have workbench filters defined and an existing filterComponent definition in a column definition, the column filter remains as it is. No conversion is executed. Column filter and workbench filter definitions can be defined and used at the same time for the time being even though the filterComponent is deprecated.
Only one view type can be displayed in a browser subapp.

The search field and filters are applied to the first view type configured in your app. The view type switcher disappears. If you want to change the view displayed, change the order of the view types defined in your .yaml config (or remove the view types you don’t want).

The Name column has changed: the titleColumn column type is replaced by componentColumn (info.magnolia.ui.contentapp.configuration.column.ComponentColumnDefinition) that supports two rows in the column. Therefore content type-based apps are automatically created with the componentColumn type.

No default or fallback icon is provided anymore for nodes.

The icon configuration has changed.

Examples of configuration updates for displaying icons in columns:

events.yaml
marketing-tags.yaml

Example of a custom Events app events.yaml

       contentViews:
        tree:
          columns:
            name:
# 6.4+:
              nodeTypeToComponents:
                mgnl:folder:
                  icon: icon-folder
                  showPath: true
                event:
                  icon: icon-datepicker
                  showPath: true
#  6.2.x and 6.3.0:
              #nodeTypeToIcon:
                #event: icon-datepicker

Example of the Marketing Tags app marketing-tags/apps/marketing-tags.yaml

# 6.4+:
          columns:
            name:
              nodeTypeToComponents:
                mgnl:marketing-tag:
                  icon: icon-tag
                  showPath: true

# 6.2.x and 6.3.0:
           #columns:
             #name:
              #nodeTypeToIcon:
                 #mgnl:marketing-tag: icon-tag
         #list:
           #columns:
             #name:
               #nodeTypeToIcon:
                 #mgnl:marketing-tag: icon-tag

If you have customized browser subapps, you must adapt your configuration by updating your custom data provider for search to function.

Below is an example (migration of the Resource Files app) of how to adapt your configuration.

In the info.magnolia.resources.app.data.ResourceFilteringDataProvider class, the filtering logic is unwrapped.

See a GitHub diff: https://github.com/magnolia-cms/doc-migration-example-631/commit/11ceb8ac31c6f2121ca7ea0ba1e462fa1a27aad9

In the resources/resources-app/apps/resources.yaml definition, shown in the tabs, the filterComponent properties under contentViews are removed and replaced by filters under workbench.

6.4 Resource Files app definition

...
    workbench:
      filters: (1)
        - name: overridden
          icon: icon-logs-settings
          $type: dropdown
          visible: true
          datasource:
            $type: optionListDatasource
            options:
              true:
                value: true
              false:
                value: false
        - name: origin
          icon: icon-language-app
          $type: dropdown
          filterOperator: STARTS_WITH
          textInputAllowed: true
          emptySelectionAllowed: true
          visible: true
          datasource:
            class: info.magnolia.resources.app.data.ResourceOriginDataSourceDefinition
        - name: status
          icon: icon-spinner-full
          $type: dropdown
          filterOperator: STARTS_WITH
          textInputAllowed: true
          emptySelectionAllowed: true
          visible: true
          datasource:
            $type: optionListDatasource
            options:
              - name: 0
                label: Not activated
                value: 0
              - name: 1
                label: Modified
                value: 1
              - name: 2
                label: Activated
                value: 2
      contentViews:
        - name: views
          $type: treeView
          rowStyleGenerator: info.magnolia.resources.app.row.ResourceStatusRowStyleGenerator
          multiSelect: false
          columns:
            name:
              class: info.magnolia.resources.app.column.ResourceNameColumnDefinition
            overridden:
              class: info.magnolia.resources.app.column.IsOverridingColumnDefinition
              editor:
                field:
                  $type: checkBoxField
            origin:
              class: info.magnolia.resources.app.column.ResourceOriginColumnDefinition
            type:
              class: info.magnolia.resources.app.column.ResourceTypeColumnDefinition
            status:
              class: info.magnolia.resources.app.column.ResourceStatusColumnDefinition
...

1	`filters` under `workbench`.

6.2 Resource Files app definition

...
    workbench:
      contentViews:
        - name: views
          $type: treeView
          rowStyleGenerator: info.magnolia.resources.app.row.ResourceStatusRowStyleGenerator
          multiSelect: false
          columns:
            name:
              class: info.magnolia.resources.app.column.ResourceNameColumnDefinition
              filterComponent: (1)
                $type: textField
            overridden:
              class: info.magnolia.resources.app.column.IsOverridingColumnDefinition
              editor:
                field:
                  $type: checkBoxField
              filterComponent: (1)
                $type: checkBoxField
            origin:
              class: info.magnolia.resources.app.column.ResourceOriginColumnDefinition
              filterComponent: (1)
                $type: comboBoxField
                emptySelectionAllowed: true
                textInputAllowed: true
                filteringMode: STARTSWITH
                datasource:
                  class: info.magnolia.resources.app.data.ResourceOriginDataSourceDefinition
            type:
              class: info.magnolia.resources.app.column.ResourceTypeColumnDefinition
              filterComponent: (1)
                $type: textField
            status:
              class: info.magnolia.resources.app.column.ResourceStatusColumnDefinition
              filterComponent: (1)
                $type: comboBoxField
                emptySelectionAllowed: true
                datasource:
                  $type: optionListDatasource
                  options:
                    - name: 0
                      label: Not activated
                      value: 0
                    - name: 1
                      label: Modified
                      value: 1
                    - name: 2
                      label: Activated
                      value: 2
...

1	`filterComponent` properties under `contentViews`.

Don’t forget to add the i18n properties for your filters. For example:

...
# filters
resources.browser.filters.overridden.label = Overrides
resources.browser.filters.overridden.options.true = True
resources.browser.filters.overridden.options.false = False
resources.browser.filters.origin.label = Origin
resources.browser.filters.status.label = Status
...

For custom deletion actions in apps: Magnolia 6.4 standardizes deletion dialogs and confirmation steps. For most users, no configuration changes are needed and the existing actions and dialogs are automatically updated. If you have extended default actions, you may have to revalidate behavior. This automatic replacement doesn’t apply to the following apps: Campaign Publisher, Configuration, Cookies, External DAM, JCR, Security, and Tags.

Click to see details of cases requiring configuration updates
- DeleteNodesConfirmationAction
  
  If you have extended DeleteNodesConfirmationAction and overridden the execute method without calling super.execute();, the new 6.4 confirmation dialogs will not appear automatically. Update or remove your customization.
  
  If you have overridden getConfirmationMessage, your custom message no longer applies. The 6.4 dialogs don’t support customization.
  
  The following properties in DeleteNodesConfirmationActionDefinition no longer apply: confirmationHeader, confirmationMessage, successActionName, cancelActionName, proceedLabel, cancelLabel, defaultCancel.
- Marking items for deletion with dependency warnings enabled
  
  If you are using DependencyAwareConfirmationActionDefinition (which extends DeleteNodesConfirmationActionDefinition), the same limitations as above apply. Inherited properties no longer affect the action.
- Enabling permanent deletion
  
  If you are using ConfirmationAlertActionDefinition with successActionName set to publishDeletion or activateDeleted, the following properties no longer apply: confirmationHeader, confirmationMessage, cancelActionName, proceedLabel, cancelLabel, defaultCancel.
- Requesting permanent deletion
  
  If you are using OpenDialogActionDefinition with dialogId set to workflow-pages:publishDeletion, the following properties no longer apply: populate, alwaysOnTop, and any properties inherited from its parent class.
- Update references to the following action names: confirmDeletion → confirmMarkDeletion; delete → markDeleted. Any decorations that overwrite or enhance the confirmDeletion action in the Pages or Assets app must use the new confirmMarkDeletion action. Remove any injected confirmation headers or messages. Standardized deletion dialogs in 6.4 do not accept these properties.
Update your delivery endpoint definitions. Ensure each endpoint uses the correct $type (jcrDeliveryEndpoint_v2 or jcrPagesDeliveryEndpoint_v2) and note the new defaults for the following properties: depthInReferencedNode = 1 and maxLimit = 100.
Magnolia 6.4 brings a New UI (based on React) to the forms in content apps, automatically. Most form features are supported in the New UI. If a feature isn’t supported, the form falls back to the Vaadin UI. Because of this, typically all forms work. You don’t need to make any changes to your forms.

To be certain, test your content app forms to ensure they are working correctly. If not, you can force a form to fall back to Vaadin by adding $type: vaadinForm to the form configuration.

If a form is rendered in the Vaadin UI, you can choose whether and when to invest time in adjusting the form definition to display it in the New UI.

For more details, see Migrating to New UI Forms.
Use the Definitions app, Problems tab, and logs to audit for unsupported, deprecated, or un-migrated configs/modules.
Run a full regression and smoke test according to your test plan (core features, content management, user logins/roles, publishing, custom integrations, REST endpoints, asset upload/download, etc.).

Upgrade complete

You are now running Magnolia 6.4. Keep your dependencies up to date, and monitor release notes for future required migrations or critical security advisories.

Feedback

DX Core

Upgrading from Magnolia 6.2 to 6.4

Prerequisites

Environment and backups

Checkpoint

Dependency and platform updates

Checkpoint

Code and configuration updates

Checkpoint

Module updates

Checkpoint

Verification and runtime updates

Final checkpoint

Upgrade complete

Location

Main doc sections