Every organization transitioning to a new system must convert its content from the old system to the new, regardless of the way decisions are made regarding prioritizing the converted content and how said content is selected. Assuming we've indeed decided to convert a certain community, some actions are best to be taken before and during the conversion process.
Converting a community is an excellent chance to recharacterize its content tree and structure and refresh its content. Do not settle for simply transferring the current structure as is. This decision might lead to missing out on many advantages the new system offers that might suit the community and its users. Even if your review leads to retaining the current settings, this is a long-term investment that is certainly worthwhile.
First, we must define which themes from the current community will be included in the new community and accordingly define its content tree (which subjects will it include and the hierarchy between them) and write a requirements’ analysis document.
After defining which subjects the new community requires, deal with the content itself. This task requires another filtering process, deciding which content passes through and which does not. If possible, delete the redundant content at this stage, preventing a possible scenario in which it is transferred to the new community due to lack of attention or time. Old content usually remains undealt with in the future; the theoretical day on which you will find the time to delete old content never comes.
At this point, it is recommended to review the possible conversion methods, automatic conversion's advantage of speed versus manual conversion's quality. Conversion methods can be combined according to the existing content (not all content can or should be automatically converted; not every manual conversion provides added value). In any case, this stage must be performed as the content's integrity must be reviewed.
I highly recommend creating a content mapping document besides the document that contains detailed content regarding the pages and windows on the current community and note where each page/window will appear in the new community and in what form as well as its appropriate conversion method. If possible, refer to the amount of content in each window. This document usually serves the entire project crew and helps us better assess the time the conversion process requires and enables a close watch on progress ensuring we don't forget any content.
Setting up a community can take place after the requirements’ analysis document is completed along the conversion document. Content should be entered only after the community setup is complete.
Entering content should be performed workers who do not have another job; employing these workers is cost effective. However, to ensure the process is carried out as planned, someone must be allocated to supervise the process, directing and monitoring content enterers' performance. We thus recommended both a conversion document and deleting old content at an early stage.
Content editors will do just that; they will not alter website structure, add missing windows or ponder upon the content's validity. Whatever content stored on the old website can be transferred as is to its required location on the new website; if an infrastructure does not exist, content feeders are to proceed (yet notify the monitor). Remember the better the infrastructure and preparation, the simpler and quicker the content entering. Once the content is entered to the new community, each update must be doubled and will as such take double the time.
In conclusion, community conversion includes steps similar to those taken when setting up a new community yet involve a different focus. When setting up a new community we must focus on characterization; when converting a community we must focus on content.
Comments