This is the final part of the Declaring Content Bankruptcy blog post about why it might be better to leave old content behind during a content migration project. Part 1 can be found here. Last time we talked about some more of the issues that a content store might have. This last post will discuss whether we should always declare bankruptcy on a content store with these issues, what the benefits might be, another possible approach, and some other thoughts.
Should we always declare content bankruptcy if content is in this state?
Obviously most content sources have huge value, and there’s just no option to get rid of the old information. More often than not, there are ways that all of the issues in the previous posts can be managed and worked around. In fact, Architech has expertise in managing challenges such as these. But doing so can, in some cases, require a lot of time and money. It might also quite possibly require expertise and knowledge that your organization just does not have available. In that case, the direction might be clear: content bankruptcy needs to be declared.
What are the benefits to content bankruptcy?
The benefits are all around saving time and money to resolve the issues I’ve listed in previous posts. But the big benefit that cannot be underestimated is that the integrity of the new content store is not polluted with the same kind of issues suffered by the old. Hopefully, if you’ve done your product selection and implementation correctly for the new repository, content is being described and structured correctly in the new tool. Hopefully the new tools work well with the way the organization operates today. And perhaps most importantly (from a pure content management perspective), hopefully it automatically maintains certain critical meta information (like the author, the publishing date, size, type, and so on). Is it really worth reducing the overall quality of the content in the new management system by pulling in this old content?
As such, I’d encourage any business to seriously look at the real value that can be extracted from the old store, and look at it in these terms. Content bankruptcy isn’t always the right way to go, or even an option. In fact, there’s perhaps a middle ground.
What about just saving some of it?
Instead of abandoning all of the old content, or going to the extreme of pulling it all in, a happy medium might be just pulling out a small portion of the content store – what can be identified as useful today. This might be performed by SMEs or just the new team who knows more about the business today. Encourage your content validators who are making the decision about what to keep to imagine that the building holding all of these pieces of content is on fire – which ones would they grab to save for another day before running out of the door themselves? Being ruthless about just extracting the most valuable information is critical to saving time and money.
Be clear about all the costs and benefits before you start, however, and be sure it’s worth the investment.
What to do with the old stuff?
Just to be clear, a company should always keep an archive of the old system, just in case – most of us might keep a copy of our inbox in another folder – just in case. That archive should include as much of the meta information about the store as well, and possibly even a copy of the old software that was used to access it. Even when you’re bankrupt, you still keep the paperwork.
Have you been involved in declaring content bankruptcy before?
Do you have examples of declaring content bankruptcy, or when it would have saved a lot of time and money for your company and achieved the same end result? Are there reasons that content bankruptcy is a really bad idea, or cases where it should never be declared? As always, your comments are appreciated, and thanks for reading this series of posts.
