So you want big changes on your site. Should you stick with your current system to accomplish this, perhaps doing a simple redesign, or is it time to migrate to another system? This is such an important decision, but easy to just fall into one of two camps: "our tool stinks and a new one would solve our problems" or "we couldn't possibly move." So how do you go about making the decision? Two steps can help you decide:
- Inventory what you already have (and not just a content inventory).
- Rationally review the situation for each item in your inventory, and then decide if the advantages/costs of staying outweigh the pros/resources of migrating or not.
What is a site?
What – exactly – is a site? If we're talking about whether to move or not, what are we talking about moving anyway? First, the obvious two parts of any site:
- Content, which is either managed or unmanaged.
- Tools, which could include anything from a highly automated CMS implementation, to someone using a text editor and ftp client.
You will also have some/all of these:
- Configuration
-
- Templates that drive how pages are consistently generated (chances are, these are not implemented in a way that's a simple copy-and-paste). For example, on the Hobbs On Tech blog, all the blog entries are generated from the same template of the CMS, but moving the templates to another system would not be 15 minutes of work.
- Special functionality, including how search is configured or how page URLs are handled.
- Platform / implementation architecture. You may or may not have a platform that helps, behind the scenes, in ensuring quality of your site.
- Relationships
-
- Metadata. Metadata is becoming more and more important to driving how pages work, and an important element of any decision of how to modify a site.
- Structured content. You may have something like a "book" content that has chapters, or some other content that has components that are highly related. Regardless of the technology, the relationship between the components (for example chapters and books) would have to be maintained in a migration, or might be very difficult to maintain in your existing system.
- Links. Links within your current site and with partners need to be carefully considered, so that you don't break links or inadvertently end up with duplicate content in a redesign or migration.
- Integration with other existing systems, both to and from. This can include generic interfaces such as RSS and XML, as well as highly customized interfaces internally or with partners.
- Account management
- Reporting
-
- Self-inspection, including how many content items are in the repository and ability to easily find and edit content.
- Analytics, including passing key metadata to analytics packages / services.
- People and Processes (not the "account" above, but real live people used to supporting and trained on your system)
-
- Publishing interfaces, including workflow.
- Existing training and support programs.
Obviously the different components could be sliced and diced differently, and complex sites will probably have other concerns. That said, the basic message is to consider all aspects of your existing (and desired) site when deciding whether to migrate to a new system or not.
The Inventory
To do an effective inventory, you will first need to define your compelling vision of what you want your site to be. After you have that, for each of the components of your site (using the above list as a start), rate each according to the following:
- For the completely as-is case, with no changes, how well is the current site supporting the Compelling Vision? Perhaps you leave the effort baselined as 0 for this case. Obviously, one of the items you may be after is reducing the ongoing cost of running the site, which perhaps you can capture in the People and Processes section (or you may decide to create a separate sheet to decide analyze the ongoing costs).
- Another possibility may be to tweak the current system toward satisfying the Compelling Vision. In this case, rate both how close each component will be to meeting the vision, and also how much effort it will take to get there.
- Repeat the ratings of how close the system would be to where you want, along with how difficult it will be to get there.
Even if you just spend an hour on this exercise, hopefully you will have a clearer picture of your situation. Here's an example spreadsheet (with 5 being the best/difficult, and 0 being the worst/easiest that's been started for a hypothetical site:
The Decision
This will almost certainly be iterative. For example, you may look at your original analysis and decide that maybe there is an easier way to improve the metadata in your current system toward your strategic goals. Or after going through the exercise once, you may realize that there would be content repercussions that you didn't anticipate until you thought through the analytics requirements. At any rate, to help you make a decision you can see how difficult each possible approach would be, and weight that against how strong you anticipate the end solution to be. In addition, you will have some documentation of how you came to your decision. You can also use this sheet as a reality check when you conduct a pilot of your approach. For example, if you see that modifying the templates in your current system during pilot is far harder than you anticipated, you can revise your estimates and perhaps re-evaluate your initial decision.
