Migrating from Portal Engine to MVC as an Agency

Ridgeway has built up a significant amount of experience in Kentico EMS Portal Engine. The Portal Engine has been great at helping us to deliver high-quality solutions for our clients that enable a rich customer journey while making the day-to-day maintenance of the solution a simple task. That being said, we decided to migrate to MVC.

When making this decision, we found ourselves asking three main questions:

• What is the overall case for moving from Portal Engine to MVC?
• How does this affect the way that we approach new clients and projects?
• What is the impact on our team?

In this article, I’ll try to articulate the high-level answers to those questions.

Making the Case for MVC Going Forward

Kentico announced that Portal Engine is going to be phased out from the next major version of Kentico. If you’re new to the world of Kentico EMS, then this probably doesn’t have much impact, but for existing partners and developers the move away from Portal Engine marks a significant change. Two key things present a challenge.

The first challenge is that we need to make sure that we bring the clients with us. This means explaining the benefits of MVC and reassuring them that it’s going to deliver. For the most part, this challenge only really affects our existing clients, but it’s good to know that you can address this if they should ask.

The second challenge is that we have to make sure that the development team has the information and time that they need to skill up in ASP.NET MVC. If you’re fortunate or have a broad skill set in your development team, then you may already have some of those skills in-house. If not, then there are some great places to look for supporting resources. As I mentioned in a previous blog, the Kentico 12 MVC for Developers training course provides a great starting point for working with Kentico EMS in MVC. This course is constantly evolving with additional modules in the pipeline covering topics such as identity, marketing, and e-commerce.

Selling MVC to the Client

One of the interesting questions is how you sell MVC to your customers. The purist in me is of the opinion that - for the most part - you shouldn’t need to. There are always cases where our customers have been very focused on the technology being used from either a due diligence perspective or because there is an intent to bring the project in-house on completion. Taking those customers out of the equation, what customers are looking for is a solution that reflects well on them and their business.

Effective Product Demos

Being able to effectively demonstrate the platform makes a huge first impression with the client and helps to build the foundations of a strong relationship. Of importance here is being able to demonstrate the features that we perceive the client may need, paying attention to their original brief, and providing insight and consultation on features that may benefit their goals.

Doing this with the Portal Engine was simple and allowed both content and structure to be demonstrated live. Quite often clients were wary of CMS platforms because they’ve been stuck with very ridged CMS platforms that either made content difficult or - in the worst cases -  required developer input. Showing a drag-and-drop interface such as Portal Engine would blow people away. Some of this drag and drop isn’t there in MVC (yet!), but we can still wow customers with templates, form builders, and page builders - it perhaps just needs a little more thought before the demo starts. Making sure that the demonstration is smooth is really important. What’s equally important is to not dwell on what isn’t out of the box in MVC as this can knock the confidence of those in the room (both your own team and the client).

Paying attention to the drag-and-drop features like Page Builder and Form Builder enables us to really show the client how the platform can fulfill their needs, while also focusing on the benefits of ensuring that we use structured content to help support the UX and design language for the project.

Changes in Development

As I mentioned above, moving to MVC affects more than just the impact on your customers; it also has a huge impact on your production team. This impact runs all the way through your business and your projects.

Rethinking the Structure of Content

How you think about content is important. At Ridgeway, we had developed a method of working with Portal Engine that was very editor-orientated, favoring content curation in the page designer over structured content. This approach allowed for marketers and content editors to create pages freely, tailoring each page to the required design aesthetic. In the MVC world, this isn’t really going to work, so our attention turns towards more structured content.

A quick example of this would be promoting products in a news article. In Portal Engine, we might create a widget that allows the editor to select the product that they wish to show on the page. They can move this piece of content anywhere they like within the editor widget zone. With MVC, we’re more focused and would use a page relationship to link to the products that we want.

Rebuilding with a Clean Slate

Having experience is a great thing, sometimes however there is a certain amount of working in a particular way because that is what you’re used to or because you’ve built up a good amount of technical resource based upon your preferred approaches. As with most agencies, over the years and the various versions of Kentico, Ridgeway have developed a rich base of reusable code that we can apply to projects to help us develop in a consistent manner. This code base has understandably been quite focused on Portal Engine and ASP.NET WebForms.

Part of our initial concerns about moving to MVC was that some of the collateral would not be useful to us anymore and that a great deal of effort in the first few projects would be taken up by recreating or porting this code across to a new solution. What is important as an agency is to not focus on this as a negative part of the process. Indeed for us, it was a great experience to not only rethink our approach to the structure of content but also to refactor and - in some cases purge - our existing code base, essentially starting with a blank canvas and building something specifically for the MVC implementation.

Freedom

It’s been said time and time again throughout the move to MVC; moving away from ASP.NET WebForms gives our creative teams so much more freedom. It gave us the confidence that the hard work put in by our front-end developers and user experience team would not be impacted by the kind of markup issues that we’ve typically seen from WebForms. With Portal Engine, we quite often found that additional HTML elements were injected into the markup based on how we needed to render the content. Over the years, you learn to adapt to this, but it’s nice not to need to think about that.

Performance

MVC is simply faster than the Portal Engine. The time to build the application in Visual Studio is quicker, the time it takes that first request after an IIS reset is faster, and the general performance of the live site is faster. It’s quite simply a triple win from a performance perspective. Overall, we’ve noticed a marked reduction in the number of time developers spend waiting for the main application to build. By following the guidance from Kentico and splitting the project into two solutions - one for the administration interface and one for the public facing website - we only build what we need to build when we need to build it.Then there is the time that the application takes to load. Having worked with Portal Engine for a number of years, it’s actually satisfying to realize that we’re getting impatient when a page load takes a couple of seconds following an application restart.

Team Building

Building and retaining a development team is difficult at the best of times. Developers are in high demand and typically make their career choices based on where they think they can progress the most. As much as Portal Engine worked well at what it did, recruiting new talent into the business and retaining experienced team members grew increasingly difficult with WebForms being a core part of our development stack.

With MVC, we can widen the appeal to prospective team members in the knowledge that the stack that we are offering is relevant and supports those desires to progress. Furthermore, bringing these new people into the team helps to build the skills of the existing team and bring some renewed enthusiasm into the mix.

As we know, developers like to learn. We can also take advantage of the documentation and training materials on offer. From a Kentico perspective, the developer documentation for Kentico 12 MVC is superb, and I often recommend it. For MVC there is an abundance of training available from sites such as Microsoft Virtual Academy, Pluralsight, and Udemy to name just a few. The key is not to assume that they will just acquire this knowledge overnight; it’s going to take some time to get the skills embedded in the team.

Developers that are learning typically are more invested in what they’re doing. They’re more likely to stick around and work with you and produce better results overall.

Conclusion

Like a lot of agencies, we delayed the move to MVC. Partly because of some of the features that were not supported and partly due to the perceived challenges in making the move. The experience so far has been a positive one. The team has enjoyed the challenges posed and taken it as an opportunity to step out of comfort zones and create some new foundations on which we can build our offering.

Overall, the questions we faced when making the change was not as challenging as we’d initially thought. The chance to refocus our development practices and take a fresh look at our design patterns and general project approach has been refreshing, and the learning and progress for the wider development team have put a new spring in people’s step.

For our customers, this has led to projects where our focus shifts from purely building what we know to work with them more collaboratively and relishing the chance to rethink how we might address individual features. The performance of the live sites has helped to achieve KPIs, and the Page Builders adds some valuable flexibility to the marketer’s toolkit.

To find out more about migrating to MVC, check out the Transition Guide.