Initial Thoughts on Episerver Delivery Core

casper.rasmussen/ May 15, 2020/ Uncategorized/ 2 comments

As many of you fellow Episerver aficionados out there already know, Episerver will soon go to market with a new and improved approach of enabling content management and content delivery. It is, at this time, referred to as “Delivery Core”, and it fundamentally changes the delivery-approach, compared to what the Episerver stack today relies on. Over the coming months, I expect to cover information on Episerver Delivery Core like so:

  • Introduction to Episerver Delivery Core; What It Is and Isn’t – Published
  • Initial Thoughts on Episerver Delivery Core – This Post
  • Looking In To The Crystal Ball; My Thoughts On The Future of Episerver – Coming
  • Gauge Your Readiness; Prepare to Implement Episerver Delivery Core – Coming
  • Migrate Your Existing Experience to Episerver Delivery Core – Coming

While I am sure some of you read the first post in this content series, which introduced Episerver Delivery Core, the intent with this post is to help you better understand what to expect from this initiative, greatly informed by knowledge I’ve obtained through partner and EMVP channels at Episerver.

While these are my honest reactions, you need to think of them as constructive thoughts helping you identify what aspects of the initiative to more thoroughly monitor and assess as you see Episerver Delivery Core appearing on your radar. At this time, nothing is concluded or given and these thoughts may even signal things for Episerver to continue to apply a steady focus towards!

My Immediate Reaction

Everything has been categorized to help you digest, regardless of you being here to satisfy your curiosity, help the planning of your digital roadmap or simply because you are validating Episerver as the platform to support your next wave of digital capability.

‘What to really look forward too’ captures high-level things that I am personally really excited about, helping Episerver differentiate or even make our digital solutions stand-out more. On the other hand, ‘What to have in mind’ and ‘What to monitor and validate more carefully’ are cherry-picked thoughts that requires your attention, at varying level of severity.

What to really look forward too

  1. You will like the headless approach. As you are introducing Episerver Delivery Core, it will enable a content-model first design approach, helping you establish parallel work-streams of experience design, content creation and platform development. Opposed to other CMS’ enabling a content-model first design approach, like Contentful, Episerver with Delivery Core removes the complexity in the technical connection between content, experience (visual, interactive, functional) and the domain/logical layers of your application.
  2. Your editors will love the continued on-page editing experience, which most other decoupled or headless CMS’ severely lacks (without added efforts or dedicated preview environments). Because of the way Episerver continues to give you an SDK for the implementation of the experience layer (via .NET 5 and Razor), we expect the on-page editing to activate out of the box.
  3. Dependent on how you’re running/operating your Episerver platform today, the Episerver Content Cloud offering is designed to abstract away the infrastructure complexities and logistics this type change requires. If you think about it, Episerver Delivery Core will introduce a dedicated web-app (logical infrastructure component), with the responsibility of delivering an interactive end-user facing web experience. It relies on a fast and secure connection to an underlying Episerver Content Delivery API (headless component) to satisfy the content and logical needs (personalization, a/b tests etc.) your new experience requires.
  4. We expect this approach to ease the upgrade of your Episerver CMS/platform further. If you consider below reasons, the introduction of Episerver Delivery Core makes the line of dependency dotted between your end-user facing experience and your underlying platform
    1. The content delivery APIs (headless component) relies on semantic versioning to control the impact of platform change, hence negative effects, introduced by platform change, will be more predictable compared to today. At the end of the day, Content Delivery API will be the glue between your experience and your platform implementation going forward.
    2. Content delivery and management are logically separated, meaning you can deploy minor-upgrade packages to the two independently.
    3. Episerver Delivery Core will most likely rely/dependent on a light and very strict version of the platforms underlying framework, which means the majority (if not all) of the change associated with an upgrade targets the management side of your application. It means your experience stays untouched for the most part.

What to have in mind

  1. Your existing end-user facing web experience must be migrated to adopt the new Delivery Core approach, which includes planning of changes such as:
    1. Migration of your Razor views, to adopt the change to helpers introduced by .NET 5 (Core).
    2. Introduction of .NET 5 (Core) compatible dependencies, to replace existing .NET Framework optimized packages.
    3. Lessen your dependency between Episerver and your new Content Delivery component, through the more light-weight packages.
    4. Dependent on how tightly coupled your existing Episerver solution is, Delivery Core requires a clear separation between the layers of experience (visual, interactive, functional via MVC and client side code), content (content models via page types and block types) and domain/logic. It may require you to re-factor certain aspects of your solution!
  2. ECommerce transactional elements, like a simple add to cart, is not supported by Content Delivery API, meaning the headless nature of ecommerce, required to adopt Delivery Core in an Episerver Commerce heavy project, may require customization and/or adaptation on your end at first.
  3. If you are running Episerver on a self-hosted cloud, you would need an additional web-app for the dedicated delivery application, hence you should expect change to your logical setup.

What to monitor and validate more carefully

  • With a headless approach, an increase in the amount of networking traffic required to serve up your experience should be expected. Instead of a database connection (and cache) being used to retrieve content, we will now see an added layer of HTTP traffic to power Delivery Core as well. It is of course something Episerver will ensure is being managed properly (performance, content cloud subscription etc.), but if you are self-hosting, it may increase your average data usage, hence bring up your operational costs. It ultimately depends on how you run your solution today!

At the end of all this, it is important for me to state how exciting this additional delivery option is. It is not something you’re forced to adopt – so instead of you looking at it through the lens of concern or need for technical change, you should see it as an opportunity for graduate adoption of new technology, when you and your Episerver solution is ready for it.

Stay tuned for the next chapter of Episerver Delivery Core content.



  1. Will this entail a re-platforming, or migration from what you can tell?

    1. Thanks for asking! It will not require neither a re-platforming or a solution migration. Dependent on how your existing Episerver solution is implemented (i.e. level of coupling between presentation and business logic), it will require varying degrees of re-factoring, to ensure the two concerns are split 100% apart. With the new approach, you need to consider any MVC-implementation having to be separate from your business/platform logic.

      We are not expecting any data migration being needed either, except for the standard data transformations associated to any Episerver upgrade.

Leave a Reply to casper.rasmussen Cancel reply

Your email address will not be published. Required fields are marked *

Please type the characters of this captcha image in the input box

Please type the characters of this captcha image in the input box
You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>