Migrating from DD4T to DXA
Migrating from DD4T to DXA can involve republishing all your content to the DXA R2 data model and also recreating existing DD4T web applications on the DXA framework. This is not a minimal effort, and to help with the process, DXA supports a staged migration approach through its various migration support features.
Each section in this topic describes a high-level stage in an overall migration from a pure DD4T implementation to a DXA 2.2 implementation using the latest release of Tridion Sites and the Public Content API. There are multiple ways in which a migration might proceed. These examples are an effort to clarify the most typical scenarios and possibilities.
Stage 0: Legacy DD4T implementation
The starting point of the example migration path is a pure DD4T setup, which the following diagram illustrates:
For illustration purposes, this example is based on an implementation of SDL Web 8. It includes DD4T-based Template Building Blocks (TBBs), use of the DD4T data model (as represented by the DD4T JSON), and a DD4T web application.
Stage 1: Installing DXA and but maintaining some legacy DD4T elements
The first stage in our example migration path is to move from a pure DD4T setup to a hybrid setup where we begin using DXA but also continue to use legacy DD4T elements.
The following diagram illustrates a hybrid implementation resulting from the first step in the migration:
The following are the characteristics of this particular scenario:
- The scenario is based on an implementation of SDL Web 8.
- The version of DXA is 2.0 or later, which features the DXA R2 data model.
- The standalone Model Service acts as intermediary between the Content Service and the web application, which can be developed in either the DXA or DD4T framework.
- DXA and DD4T web applications use appropriate Providers to interact with the standalone Model Service:
- DXA web applications use the DXA Default Model Service Provider to make requests from the Model Service instead of making direct requests from the Content Service.
- Legacy DD4T web applications use the DD4T Provider for DXA Model Service so that they behave in the same way as DXA applications, using the Model Service instead of making direct requests.
- DXA R2 TBBs publish to the DXA R2 data model while legacy DD4T TBBs continue to publish to the DD4T data model.
- The standalone Model Service provides support for both the R2 data model and the legacy DD4T data model. The Data Model Converter handles both data models and sends the appropriate format to the respective web application.
The standalone Model Service first determines whether the published data model matches the requested format. If there is a conflict between the published data model and the requested data model, then the converter converts the JSON to match the requested format.
The following table summarizes the different scenarios.
| Requested | Published | Actions of the Data Model Converter | Actions of the DXA Model Extension (or standalone Model Service) |
|---|---|---|---|
| R2 | R2 | None—no conversion is necessary. | Returns the R2 data model to the R2 Content Provider. |
| R2 | DD4T | Converts the DD4T data model to the R2 data model. | Returns the R2 data model to the R2 Content Provider. |
| DD4T | DD4T | None—no conversion is necessary. | Returns the DD4T data model to the DD4T Content Provider. |
| DD4T | R2 | Converts the R2 data model to the DD4T data model. | Returns the DD4T data model to the DD4T Content Provider. |
Stage 2: Upgrading to Tridion Sites 9 or later but maintaining legacy DD4T elements
The second stage in our example migration path is to move from a pure DD4T setup to a hybrid setup where we begin using DXA but also continue to use legacy DD4T elements.
The following diagram illustrates a hybrid implementation resulting from this next step in the migration:
These are some of the characteristics of this particular scenario:
- The scenario is based on an implementation of Tridion Sites 9.
- The version of DXA is 2.1 or later. These feature a DXA Model Extension to the Content Service, which uses the GraphQL-based Public Content API for fulfilling content requests from DXA web applications. The older standalone Model Service continues to support legacy DD4T web applications.
- DXA and DD4T web applications use appropriate Providers to interact with either the DXA Model Extension or the standalone Model Service:
- DXA web applications use the DXA Provider for GraphQL to make requests from the Model Extension, which is part of the Content Service.
- Legacy DD4T web applications continue to use the DD4T Provider for DXA Model Service , using the standalone Model Service to make requests from the Content Service.
- As in Stage 2, the DXA R2 TBBs publish to the DXA R2 data model while legacy DD4T TBBs continue to publish to the DD4T data model.
- Whether using the DXA Model Extension or the standalone Model Service, the Data Model Converter handles both the R2 and DD4T data models and sends the appropriate format to the requesting web application. The behavior of the Data Model Converter is the same as described in Stage 2.
Stage 3: Final conversion of all TBBs and web applications to DXA
The third and final stage in our example migration path is to convert all legacy DD4T TBBs and web applications toDXA.
The following diagram illustrates a pure DXA implementation resulting from this final step in the migration:
The following are the characteristics of this stage in the migration:
- As in the previous stage, the scenario is based on an implementation of Tridion Sites 9 and DXA 2.1 or later.
- Legacy DD4T TBBs are converted to DXA R2 TBBs, and the Content Manager publishes only DXA R2 format content.
- Legacy DD4T web applications are rebuilt as DXA web applications.
- With no remaining DD4T web applications or TBBs, there is no longer a need for the standalone Model Service or the Data Model Converter.
- The DXA Model Extension to the Content Service uses the Public Content API to fulfill content requests from DXA web applications.