Options for migrating to Episerver Digital Experience Cloud Service

Episerver Digital Experience Cloud service (DXC-S) can host multiple customer sites in a single Episerver instance running on a single codebase. This is run on the cloud as a managed service delivered by Episerver and costed on a consumption based model. This is a good approach for organisations that want to share the consumption and managed service offered by DXC-S across brands/sites/countries/anything they wish. However it's not always possible to migrate multiple sites to Episerver Digital Experience Cloud Service (DXC-S) in one go and customers often may need or want to take a phased approach. It may not also be possible to run all sites off a single codebase. So this post describes some approaches when migrating to DXC-S. 

Option 1 - Big Bang

This means all sites move over to DXC-S in one go. This is the cleanest solution but can also be the most difficult if migrating multiple sites. It means on switch over all sites run on DXC-S and all old sites are decommissioned. It is however the most difficult approach when migrating multiple sites. 

Pros

• Cleanest solution, can switch all sites over with DNS changes
• Old solution(s) are decommissioned cleanly
• Good for "big reveal" launches with wholesale changes accross site(s)

Cons

• Hardest to achieve, requires lots of organisational communication 
• Carries the highest risk as any issues are reflected accros all sites

Option 2  - Sub-domain approach

This approach involves changing the sub-domain of the old (or new) sites to an alternate sub-domain such as ww2 for the period of the migration. Old sites could be migrated over to ww2.site.com and once the site is ready for migration they are moved onto the new www.site.com version of the site running on DXC-S. 

The approach can also be reversed where the new sites run on ww2.site.com and the old site(s) run on www.site.com while the migration occurs. The example below shows the old site(s) running on ww2.site.com and the new site(s) running on www.site.com:

Pros

• Less risky as each site can be migrated in turn 
• Easier to coordinate across an organisation
• Migration occurs through redirection from old to new sites so the time of migration can be controlled exactly

Cons

• SEO teams/agencies may assess this as having a negative impact on rankings 
• Could involve changing the old/legacy site to migrate onto the alternate sub-domain which may be difficult
• Can sometimes be tricky to get the redirects set up correctly
• Two sets of infrastructure need to exist whilst the migration occurs 

Option 3 - Reverse proxy

This is similar to Option 2. where two sets of sites (and associated infrastructure) live on in parallel for a period of time while migration occurs. However in this case the DXC-S instance acts as a reverse proxy which means the old sites can be hidden behind the original site domain. For example www.site.com can proxy requests to old.site.com. End users are never aware of this forwarding and as far as they are concerned they are still accessing the site on www.site.com. An example of this is shown below:

It should be noted that DXC-S supports reverse proxy as described here: https://world.episerver.com/blogs/david-buo/dates/2017/11/support-for-applicationhost-transforms-in-dxc-service/.

Pros

• Maintains the original domains
• The only approach that allows individual sections of sites to be cleanly migrated over e.g. www.site.com/news
• Original infrastructure is protected by the security features of DXC-S such as WAF and DDoS protection 

Cons

• Two sets of infrastructure live on while migration occurs
• Involves changes to the old/legacy site to ensure content is displayed correctly which may be difficult (e.g. relative paths etc)
• Two sets of infrastructure need to exist whilst the migration occurs 

Option 4 - Addtional DXC-S package

When sites are maintained by different teams or functional requirements differ for Episerver sites it may not always be possible to share a codebase. In this case Episerver can provide an "additional package". This additional package is an additional set of Episerver Digital Experience Cloud Service environments (including integration, pre-prod and production and also separate Find indexes). It is separate from the master package so can be used for a totally separate purpose if necessary. The example below shows one additional package where account.site.com is developed by a separate team is used for a different purpose from www.site.com:

The cost of an additional package is a small increment on the original cost of DXC-S and shares the overall consumption.

Pros

• Allows teams/departments to work independently
• Separate environments mean release cadence can be different and independent of each other

Cons

• Separate codebases can add complexity if sharing features
• Comes with a small additional cost

Recommendations

The best approach for any particular situation depends on several factors. However a brief summary of potential recommendations can be seen below but the actual choice depends on the project:

• Option 1 (big bang) - when there is a single site or a smaller number of sites that are interdependent and/or share similar functionality.
• Option 2 (sub-domain approach) - when a phased approach is needed and there is limited potential to change the legacy site implementation(s).
• Option 3 (reverse proxy) - when a consistent user experience is key and also there is a high degree of control on the legacy systems. Also suitable if a section by section migration is required.
• Option 4 (additional DXC-S package) - when there are different teams and functional solutions involved which need to be managed separately.

Comments