Prioritizing Content Migration Activities - Key Considerations

Our previous post described two key considerations when making the hard decisions around content migration:

• Content Migration & The Demands of the New Information Architecture
• Content Migration & The Popularity of the Content Today

FYI - Our whitepaper, Planning for Success: Best Practices in CMS Governance, discusses migration and other non-technical considerations critical to CMS deployment success in more detail.

Consideration Three: Importance of Content to the Organization’s Objectives

Your organization almost certainly has specific objectives for your web properties.  Common objectives for public sites include selling products, generating leads, meeting regulatory requirements and deepening client relationships.  Intranets are frequently designed to improve access to key corporate information, facilitate collaboration and accelerate decision-making.

Your current site probably has key content that drives objectives — whitepaper download pages, marketing calls to action, etc.  This content may not be the most popular content on the site, but it is absolutely essential.  Prioritize migration of this content, and make it the centerpiece of the new information architecture (although that’s another discussion).

Consideration Four: Mandatory Content

Some content must be migrated or replaced even though it is neither popular, nor instrumental in achieving your organization’s goals.  A classic example is the privacy policy page.  Recently, during a CMS migration process, one of our clients found that their privacy page accounted for less than 0.02% of all page views. Clearly, it didn’t make sense to retain the page based on its popularity among visitors.  But given it’s importance for compliance reasons, of course it was retained.

Content Migration Considerations Five and Six

Our next (post holiday) blog will consider two additional considerations:

• Is the content stored in a structured format (a database or xml schema)?
• Is the content a self-contained microsite?

As noted in a previous blog post on content migration, getting content from your existing site or intranet into a new content management solution can be challenging. In the process, most organizations find that they need to decide to retain, eliminate or replace content.

Consideration One: The Information Architecture

The key question here: does the content in question need to be changed, given the information architecture of the new site?  If the site is being redesigned or restructured, there may be no way to include all the content from the existing site in the new site.  Existing content may need to be restructured in smaller modules, combined to form new blocks of content or presented conditionally as part of a personalization project.  And so on.  The information architecture of the redesigned site will drive many decisions on whether content lives on and is migrated intact, or is eliminated or rewritten.  Automated migration tools will not help you with the process of restructuring content.

FYI - Our whitepaper, Planning for Success: Best Practices in CMS Governance, discusses migration and other non-technical considerations critical to CMS deployment success in more detail.

Consideration Two: Content Popularity

You probably have a reliable source of information on user demand for existing content, such as Google Analytics or some other trusted system.  Usually, you can run a report ranking content from most viewed to least viewed.  In almost all cases, you will find that a small percentage of content drives the vast majority of page views.  For example, during a recent project, an NLC client found that 1.5% of the organization’s web pages (the top 500 pages) accounted for 80.5% of all page views.  The 501st most popular page accounts for only 0.03 percent of all page views.

You can’t simply focus on these top pages —the other 34,500 pages on the client’s site are connected to the top pages, and  may not make sense without these linked pages.  That said, it is critical to include current popularity as a consideration in determining whether (or when) to migrate existing content.

Considerations Three and Four

Our next post will discuss two additional considerations in determining which content makes the cut:

• The importance of content to your organization’s objectives
• Whether content is considered “mandatory” for regulatory or other compliance reasons

Content migration can be the ugly, dark side of deploying a content management solution, whether you are deploying Microsoft SharePoint 2007 inside the firewall, or a solution like Sitecore to manage your public sites.  

FYI - Our whitepaper, Planning for Success: Best Practices in CMS Governance, discusses migration and other non-technical considerations critical to CMS deployment success in more detail.

When content migration is not fully taken into account during the planning process, it can end up being:

• Painful
• Expensive
• A never-ending death march
• All of the above 

A contingent from NLC attended the Gilbane CMS conference in Boston last week. The theme was Where Content Management Meets Social Media and indeed, social media was the reverse elephant in the room – on everyone’s mind, and stirring passionate discussion at every turn.

Keynotes and sessions covered everything from the state of the industry to open standards to the rise of open source. The state of the economy was a strong overall influence, and Fatwire’s controversial keynote added some colour. The conference Twitter stream was also active.

Time again for a roundup of news from the world of Sitecore.

Note: If you’re looking to get started in Sitecore and want a more complete guide to navigating this CMS product, our recently released Best Practices for Sitecore whitepaper can help guide you through a successful implementation.

Now, onto the news. . .

In honour of the new blog design, I thought I would share some blog design tips! I have to admit that the topic was inspired by one of my colleagues when he commented on the design: “Ah, the header is too dark and it’s taking up too much space”. Folks, it’s like music to my ears! (why?) How many times have we designers heard similar comments from clients or colleagues? How do we overcome this challenge?

This is the second post in a series discussing security considerations and approaches for websites driven by the Sitecore CMS. The topic of discussion today is content authors and the security implications of allowing many people to update your website.

Two years ago, we launched this blog as a bit of an experiment.  Several hundred posts later, the blog has come to play a central role within our company - with our peers, our partners and our clients.

The work and referrals that have arisen out of this blog have kept us busy… so busy that the blog itself was, perhaps, a little neglected (at least from a design perspective.)

Today, we’re pleased to showcase a brand new design

Over the course of the redesign, I have had a chance to get intimately re-acquainted with the articles produced by my fellow colleagues.  And I have say, they have written some extremely interesting stuff.  To celebrate the re-launch, I thought I might highlight a few perennial favorites.

This is the first post in a series discussing security considerations and approaches for websites driven by the Sitecore CMS. The topic of discussion today is set-up and infrastructure.

Top ten Sitecore security dos and don’ts

1. Content authors should not be using the same installation as the actual website. The CMS should sit behind the firewall and publish content to the web server nodes.
2. The database and the CMS should reside on different servers. This physical separation reduces impact if there is a breach.
3. On the SQL Database, create a specific access account for Sitecore, and provide users with only the required privileges (db_datareader, db_datawriter, execute permissions on stored procedures, etc).
4. The Sitecore Data Folder should reside in an area that is not directly accessible via the web. This prevents unwanted access to files and forces all visitors to retrieve the files through the security rules enforced by the CMS.
5. If you’re using Sitecore 6 on IIS 6, note that there is bug in IIS and a default configuration value that may allow access to your web.config file. To prevent this, be sure your web.config contains the following code in the FilterUrlExtensions section:
   </p> <span desc=”Blocked extensions that do not stream files (comma separated)” class=”mceItemParam”></span>*</param>

A major concern for any website is its vulnerability to external attacks. While these security concerns are not unique to CMS-driven sites, they are especially important to consider in organizations that are using a content management system. The presence of a CMS introduces special considerations for security – for example, having many users inside the organization who are able to update the site. This series of blog posts is meant to guide the reader through a variety of security considerations related to CMS-driven websites, some of which will be specific to Sitecore. The good news is that all of these concerns can be addressed and overcome through careful planning.

Sitecore Security - Key Considerations:

• Sitecore Setup and Infrastructure
  Was Sitecore installed correctly, with the recommended configuration? Did you take the necessary precautions to protect IIS and the Windows server?
• Danger from within: Consideration of content authors, validation and governance
  Now that many people can update site content, what processes do you need to put in place to ensure that content authors do not accidently create a security vulnerability?
• Findability of private information
  When a CMS runs multiple sites or a public and private version of a site, does the implementation correctly protect access to content, particularly from the very thorough and efficient search engine crawlers?
• External Hackers
  Injection, Cross Site Script and Other Forms of Attack. While not specific to Sitecore or any CMS, there are certain techniques and approaches provided by the Sitecore backend that allow CMS developers to create even more secure and robust sites.
• Sleeping (peacefully) at night
  You have done your best during implementation, now what? Some final thoughts on tools to help you prevent problems so you can stop worrying about being hacked.

Starting in the next post, I will delve into each of these topics. If you would like to see other areas covered in this discussion you can always reach me at glen {at} nonlinear.ca.