Migration scenarios
Situation 1: from DD4T 2 to DXA R2 Framework-style
Applies to: customers that are currently on DD4T 2 and have a significant number of customizations in the web application (e.g. factories, resolvers, DI, logging, caching)
Migration path:
Step | Description | Rationale | How | When |
---|---|---|---|---|
1 | Start using the model service inside their current application | Performance improvement because of pre-resolved links and improved caching / performance | 1a: Import DXA into the CMS, change templates to R2, republish, install model service, switch to the model service provider (recommended if publishing is not a big issue and if there are no significant template customizations) 1b: Import DXA into the CMS, publish system pages, install model service, switch to the model service provider (recommended if customer does not want to republish all their pages or have significant template customizations) | After DXA 2.0 release |
2 | Start using DXA framework instead of DD4T | Move to single codebase, ability to use modules?? | Replace factories / resolvers / cacheagents / etc by corresponding DXA artifacts | After DXA 2.1 release |
Situation 2: from DD4T 2 to DXA R2 Application-style
Applies to: customers that are currently on DD4T 2 and have few customizations in the web application (e.g. factories, resolvers, DI, logging, caching) - custom views, models, and controllers are allowed
Migration path:
Step | Description | Rationale | How | When |
---|---|---|---|---|
1 | Migrate to DXA 2 directly | Few customizations means low impact to migrate, and you gain the benefit of modules, plus probably performance increase. | Refactor view classes to use DXA annotations. Views do not need to change. Other customizations (controllers etc) must be refactored on a case-by-case basis. | After DXA 2.0 release |