Before I start into the meat and potatoes of this post, I feel a little introduction is necessary. My name is Kevin Apgar and I am the most recent addition to the Diagram family. I came here because I had worked with Diagram in the past as an editor and site conversion team member at my previous employer. I have seen what it's like to be a client and that made me want to join the team. I now work as a Quality Control/Content Concierge with the Development Team and love it.
As part of my previous job, I was part of the team that, along with Diagram, handled our project of migrating from Ektron to Episerver. This project involved migrating over 1,200 pages and 5,000 PDF and image assets. As much as we planned and prepared for the migration from Ektron to Episerver, we did encounter a few stumbling blocks that I'll share with you today. I hope you can take away some valuable ideas to help you avoid the same roadblocks.
1. Stop thinking in terms of internal departments for content development
A big change in how we organized our content was to rework how it was structured by department. Going into the project, we knew this would be a big undertaking and it was a conscious decision to change this when building our new site. Our first step was to eliminate as many department name references as possible on our site. I believe this approach helped the end user with regard to better understanding how that site is organized.
Despite this plan, there was still one related issue we failed to avoid... we assigned content specialists to tackle the reworking of the site's content based on department. For example, specialist 1 was responsible for content from departments A, B, and C; specialist 2 for departments D, E and F; and so on. Why was this bad? Because if one specialist was using their own unique voice on all the content for a specific department, it made the content sound distinctive from other departments. Knowing how my fellow specialists wrote, I could easily read a page of content and know exactly who was responsible for it. The other issue we ran into is that by siloing content specialists by department, they did not become familiar with other sections of the site.
Solution? Mix things up! Don't have John Doe create all pages for the accounting department while Bill Smith does all your HR content. This will also help ensure that every editor has greater familiarity with the work that everyone else is doing on the project.
2. Develop an Asset Naming Strategy and Stick to It
One of the biggest problems I've encountered when building websites is having different editors develop their own personal way to name assets (the files linked from your web pages including PDF documents and image files). This may not seem like a big deal, except for when you're trying to browse a directory full of random files to find something that needs to be replaced. If there is a consistent naming strategy, the time necessary to find it can be greatly reduced. Incorporate best practices such as the use of hyphens to separate words, a character limit and consistent formatting when filenames have dates built into them (meeting agendas, etc.). Talk to your Diagram project manager for more tips and don't be afraid to loop them in on these discussions, especially in terms of optimizing the filenames for SEO best practices.
It is also important to make sure that anybody you train subsequent to the launch of your new site also adheres to this strategy. Once you've developed something that is easy to remember and implement, develop a policy based on it. With an official policy in place, it's easier to explain why doing this is important.
3. Use Best Practices for Links
Do you have a link to another page on your site open in the same tab/window or a new one? What about links to assets like PDFs? What about links to external sites? Should you include a warning in a modal window that your visitor is about to leave your site for another one? What are the best practices not just for web design in general but for websites in the industry in which you work? A state government office may have different rules than healthcare. An educational institution may want to follow a set of standards while a big-box retailer has different ideas to follow.
When we started our project, we thought we understood this and had our methods firmly in place. About a month or so into content conversion, we discovered that we were all doing things differently and that some of us had even changed our own methodology partway through (I was guilty of this). While all of us had internal links opening in the same browser tab/window, the same could not be said for links to internal documents or external pages and sites. Once you're a few months into a project with a deadline looming and work left to be done, it's hard to find the time to go back to the pages you thought were done and tweak all your links.
Make sure the answers to these questions are fully researched and that all decisions are made ahead of time and committed to a policy statement. If you're part of a professional organization specific to your industry, ask them. Talk to your legal department if you have one. Also, make sure your Diagram project manager is involved in these discussions and decisions. They know their stuff.
4. SEO is King
If you don't know what Search Engine Optimization is, please take a moment to check out the variety of posts we have on the topic. Go ahead. I'll wait.
Within Episerver, it is very easy to optimize your pages for search engines. But the onus is on you to make sure you take advantage of this functionality. Personally, I optimized each page I re-developed on that site. Every. Last. One. So did my other content specialists. However, as we started recruiting more editors throughout the organization, I saw some pages get left out in terms of SEO. We clearly hadn't imparted just how important SEO is for the success of our site. To them, it was likely just another acronym in an industry drowning in alphabet soup.
Even a rudimentary understanding of SEO is vital to any redesign project. Find a short article, a wiki page, or even run an SEO check so you know what issues to address as your migrate your content. With everyone on board with the importance of SEO and following best practices, your site will fare better in search results, both internal and external.
5. Communicate! Communicate! Communicate!
It can never be overstated the importance of communication during a site redesign or migration from Ektron to Episerver (or any CMS for that matter). Sure, there are a ton of meetings within projects and you have a launch date hanging over your head, so the last thing you want to do is schedule yet another meeting. But it's easy to have simple 15-minute check-ins on a daily or every-other-day basis or to set up an intra-office chat solution such as Slack, Flack or Stride. Wouldn't you rather take more time now to prevent a mistake than making one and discover it far too late in the game if you even discover it at all? The last thing you want is to have your mistake discovered by a visitor to your site.
With these tips, I hope you are able to navigate around any potential roadblocks to your own Ektron to Episerver migration. If you've gone through a similar project or had other issues that you've solved related to site redesigns or migrations, please share your experience in the comments either right here on our blog or on social media. I'd love to hear from you!
