Moving from Ektron to Episerver: A Developer’s Guide

By far the biggest and most universal concern when making any platform change for your website is, “What happens to my content?”

For developers, this question comes in a couple of distinct forms. “How do I move the content models over?” and “Where to I start?” We’re here to help answer both.

The materials and ideas reference below were presented at Episerver Ascend in Las Vegas, NV on February 28, 2017. Therefore, what you’ll find are not only code samples for how the same content can be modeled in both Ektron and Episerver, but a complete guide to building out those models (and a bit more) in Episerver.

For this article, I’ll cover first a high-level overview for how to consider your move to Episerver before getting into the specifics of the materials.

Start in Episerver, not Ektron

You start in Episerver, preferably after some training so that you know some of the best practices that should be applied here. As with any system, there are multiple ways to achieve similar results, but each variant can have its own benefits and consequences. If you simply port over the Ektron models more or less as-is, then you’re bound to ignore many of those practices and therefore paint yourself into a metaphorical corner when it comes to managing your Episerver site long-term.

By understanding how Episerver content may be modeled and repurposed, you can build a site that is more robust, easier to manage, and more future-proof for organizational growth.

And it is with that in mind that we would encourage the developer or architect to begin by assessing what defines a piece of content and first modeling that out in Episerver, almost with blind disregard to how it’s modeled in Ektron.

If that sounds strange, that’s ok. What you should strive for is the best possible implementation of Episerver. As you later look at how to move the content, you can make sacrifices to make that process easier. Ease of migration, however, should not be the goal when it comes to setting up your Episerver site.

A Difference of Information Architecture

One of the top differences between Ektron and Episerver is that Ektron uses a Microsoft Windows-like folder structure to organize content while Episerver follows a more web-centric paradigm of a content hierarchy (content is a child of other content).

There are many things we could say about this difference, but one of the chiefest is that most Episerver implementations use this content tree as the data source for the site IA (main menu structure) while Ektron relies not on the Folder tree but on a separate internal Menu structure. This means that only in rare, fanatically organized cases will Ektron’s folder structure provide a sufficient mirror of the site IA that it can be mapped directly.

That simply means that we must look at the migration in two phases: one to move over content directly related to the Ektron Menu structure (or Taxonomy, if so used) and a latter which maps folders of content to specific nodes in that structure.

One approach to planning this migration is to create a document with the Menu or Taxonomy structure that drives your current IA, then add to that the Ektron Folder IDs that should be mapped as children of each. No migration is purely this simple, but we find that this is sufficient to handle about 80% of the migration if not more.

This also will allow you to figure out how content maps between the two systems on a small scale and with an application of architecture in the destination system. Most sites have between 20 and 200 direct links in their main navigation. That number of items is reasonably small and the data set usually varied enough that it becomes a really good test of the migration effort - it takes little time and covers a lot of ground per test.

From the Lab

The Lab I’m giving at Ascend covers moving several types of content all under the umbrella of a sample site I’ve built in both Ektron and Episerver - “SPOCKaaS,” or “Spock as a Service.”

It doesn’t go into specifics of Menus, Collections, or Taxonomy, as those are topics that could be covered separately in and of themselves (I know, I’ve done it). Rather, it focuses on the content itself and covers several areas: calendar, a simple Smart Form, a layered Smart Form, as well as a little into PageBuilder and Widgets, though those are quite different from what Episerver does under the hood (Epi’s is better).

The sample code includes Blog content, though the instructions don’t because, well, it’s not much of a challenge compared to the rest.

To give an example of the exercises covered, I’ll provide a brief summary of the first set.

The material covers a simple Smart Form in the form of a “Service” page meant to showcase one of the many services our fictitious organization (SPOCKaaS, or “Spock as a Service”) provides. E.g. Mind Melding. Containing only three fields, it’s about as simple as a Smart Form can get, yet includes an example of an image and a rich text field, making it an ideal starting point. Just enough to be a good proof-of-concept.

Because the Ektron site showcases these services on the home page as Calls to Action and then features them slightly differently on a “Services” landing page, this section also covers some PageBuilder equivalent.
In the Lab, we recreate these PageBuilder pages (which is way easier than doing them over in Ektron - believe me, I just created this site twice). What this shows is that CTAs or content features can be separate items, al a Smart Forms and Widgets, or you can simply drag the page you want to feature onto another page. From an Ektron perspective, it will seem almost too easy.

Extras

Naturally, I can’t keep myself from adding a little something extra (or two) to the materials. So, not included in the instructions, yet included in the Episerver code, are examples for how you can do a couple of more advanced things in Epi.

First, I’ve added a simple override to the built-in caching mechanism. My code actually uses the built-in cache as a parameter, so it’s functionally identical, but it shows how all of the cache methods - get, insert, and remove - can be overridden inside of Episerver and the functionality completely replaced with your own vision for data caching, whether that’s a small tweak to the default or relying on some other cache provider entirely.

I’ve also configured the Blogs portion of the site to not only show content created inside Episerver, but to also pull, list, and display blog content from the Ektron site using Partial Routing. I’ve created two Generic Handlers in Ektron that provide a list of content items from the blog (lightweight) and a single blog item by ID (full content). The partial router can generate local URLs for rendering each of these items and show them as though they were part of the Episerver site and not an outside resource. This is just one example for how partial routing can be used. We’ve also used it here at Brightfind to support dynamically shared content between two sites within the same Episerver instance (multisite).

Where to find the code

It will probably come as a surprise to no one that I’m making the materials for the lab available immediately, including full source for both Ektron and Episerver sites, the slide show with notes, and the lab instruction booklet.

Everything is on Github, so any revisions will be published.

The Ektron code base includes everything you need on top of a CMS400Min site to get running. That is, install the min site, then deploy this code on top of it. I did not include any Ektron DLLs, workarea, or anything else I thought could be spared from the repo and provided by the Ektron installer. The repo also includes a zipped backup of the Ektron database.

The Episerver code base uses a standard Visual Studio git ignore file to remove DLLs and other resources that can be restored via Nuget. Simply open the project, build, and run. It uses add-on packages to supply Bootstrap support and some other functionality, all of which come from Epi’s nuget feed, which you’ll have to have configured in your Visual Studio in order to successfully restore this project. This repo also contains the Lab Instructions PDF and the slideshow as a PDF (notes view).

By all means, let me know via Twitter (@egandalf) or by filing an issue via Github to the appropriate project if you have any questions.

Happy coding!