Content retention

We have a TS 6.5 SP3 content store and we are planning to archive the store / retain contents as part of content retention policy of our org. Our TS box is going to be a non permitted OS box and we are planning to move towards upgrading TS to a higher version.
Do we have to necessarily go for a upgrade of TS in order to retain content? or Is there a better way to address content retention. Can someone share your opinion?

Find more posts tagged with

Comments

Rick Poulin

Do we have to necessarily go for a upgrade of TS in order to retain content?

Your question doesn't make much sense.. content retention is not a reason to upgrade, so... are you asking about upgrading in place vs. building a new server and moving the content over?

If you can discard your version history, or you're fine accessing an old read-only server to view it, then you can build your server fresh and just migrate your content into a clean content store. And by 'migrate' I mean either write a script to copy relevant STAGINGs or WORKAREAs over and reapply EAs, or use OpenDeploy to accomplish the same.

If you want to retain your version history, you can still (theoretically) build fresh and use the iwmigrate tool to copy branches over, although you'll want to test this with whatever target version you're moving to. Or, depending on your source and target versions, you may be able to just copy the content store as-is to the new server (and then possibly trim editions and branches you no longer need, followed by an iwfsshrink).

In my experience, upgrading in place is typically much more cumbersome for little added benefit, especially if you're going to make a jump as large as 6.5 > 7.3.2. The only relevant scenario that comes to mind is if you're somehow limited in obtaining new hardware.

[part 2]
If your question was about whether you need to upgrade your legacy server hosting the legacy 6.5 content store for archival purposes, the answer is "no you don't". In fact, that might break your legacy content more than anything. Since you're not actively developing on a legacy server, and nothing else should change, you don't really need it to be supported by the vendor. Just let it sit as-is and freeze your content stores.

Snap 2016-06-03 at 11.42.03.png

ts_tech

Thanks for your reply. We ran a POC for this migrate from 6.5. SP3 to 6.7.2 SP2 then 7.3.2 and so forth based on IWOVs recommendation.

for part2: We have to retire our OS and TS to address a "not permitted" software / hardware violation of our org.
What are our options to retain and archive the store contents and to make it readable for future purpose?

Rick Poulin

Thanks for your reply. We ran a POC for this migrate from 6.5. SP3 to 6.7.2 SP2 then 7.3.2 and so forth based on IWOVs recommendation.

for part2: We have to retire our OS and TS to address a "not permitted" software / hardware violation of our org.
What are our options to retain and archive the store contents and to make it readable for future purpose?

Autonomy just confirmed the change in content store format in 6.7.2 and up, so your legacy content store won't be readable by more recent versions of the product. That means your options are this:

a) Build a TS6.5 server on new hardware/software that doesn't violate any of your organization's conventions, deploy your customizations on there and host your legacy store on this server. Your hardware will be limited by what was supported by that version, and you run the risk of breaking your legacy content if the differences in relevant hardware are non-trivial.

b) Write scripts to extract the information you want to keep from the content store and save them in some custom format of your choosing. This can be simply reproducing the /iwmnt folder structure as a flat file system somewhere, and maybe host the metadata in XML or a custom DB or something. Obviously the effort here can be pretty big, and usability will likely suffer. There's also no going back if a year from now you realize you forgot to extract key data.

c) Get your organization to make an exception. If you're concerned about security (viruses and whatnot on a legacy system), then take the server offline and just boot it when you need to look up something in the archive (or put it in a restricted network segment, or unplug it from the network, or...). This is the option with the lowest risk and lowest effort, so I'd push this as far as I can before considering the alternatives.

Surely this is not the first time your organization has to take a legacy COTS offline, so you should find out what the strategy has been in the past.

new_report_12.rptdesign