nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

TeamSite 7.1 content store migration

System

Has anyone had any experience with migrating a content store to TeamSite 7.1?

We are installing 7.1 on a new server and need to migrate the content store from the old v6.7.1 installation. I have found KB articles which outline how to do this for migrating from 6.5 to 6.7 but am wondering if the process is the same for going to 7.1. I'd greatly appreciate any tips or experience others may like to share

thanks in advance
Simon

Find more posts tagged with

Comments

nipper

In process right now. Nothing you need to do. The stores are consistent between 6.7.1 and 7.1 (check the release notes as there *may* be SP to be applied to 6.7.1 first but I do not think so)

For 6.7.2 I have just installed 7.1 on top and ran.

Adam Stoller

Has anyone had any experience with migrating a content store to TeamSite 7.1?

We are installing 7.1 on a new server and need to migrate the content store from the old v6.7.1 installation. I have found KB articles which outline how to do this for migrating from 6.5 to 6.7 but am wondering if the process is the same for going to 7.1. I'd greatly appreciate any tips or experience others may like to share

thanks in advance
Simon

I haven't tried doing this [yet] - but I would probably do the same things I've done for similar upgrades to fresh installations:

That's a somewhat shortened, general process - but it's worked for me in the past when upgrading 5.5.2 installations to 6.x and upgrading 6.x to 6.7.2.

nipper

I haven't tried doing this [yet] - but I would probably do the same things I've done for similar upgrades to fresh installations:
Install software on new box
Make sure to cut editions on all branches on old box
Stop TS on old box and copy entire backing store to some location on new box (then, optionally, restart TS on old box)
Configure copy of old store as temporary second store on new box (iw.cfg) activate the temporary second store, deactivate the default store
Run iwmigrate from the copy of the old store to the new default store
When done, run iwfsck on the new default store
Run iwfsshrink on the new default store
If you're going to have to do a follow-up incremental migration - stop TS on the new box and make a good copy of the backing store, as you'll need to restore that copy before doing an incremental migration
That's a somewhat shortened, general process - but it's worked for me in the past when upgrading 5.5.2 installations to 6.x and upgrading 6.x to 6.7.2.

If you do not want to lose any history, then bag the iwmigrate step and just mount the old store as a new store. (which is in my case)

Adam Stoller

If you do not want to lose any history, then bag the iwmigrate step and just mount the old store as a new store. (which is in my case)

iwmigrate doesn't lose history.
The reason for iwmigrate (as opposed to just using a copy of the old store as if it were the new store) is that between versions of the product IWOV has occasionally included improvements to the backing store - and unless you do the iwmigrate step you don't get the benefits of those improvements.

This is much more necessary from pre-6.x to 6.x versions but also applies (I think) to going between some of the various 6.x versions and thus is reasonable to consider doing if you're going to 7.x

If you're not concerned about potential differences between the old and new version's native backing store (well, new and old-automatically-converted-to-new) formats then using the copy as-if it were new is fine (and definitely quicker)

nipper

If you're not concerned about potential differences between the old and new version's native backing store (well, new and old-automatically-converted-to-new) formats then using the copy as-if it were new is fine (and definitely quicker)

Yea that is what I was thinking. BTW, any idea how to tell if/when the auotmatically-upgrade-convert-to-new has completed ? (doign 6.5 - 6.7.2 - 7.1)

Adam Stoller

Yea that is what I was thinking. BTW, any idea how to tell if/when the auotmatically-upgrade-convert-to-new has completed ? (doign 6.5 - 6.7.2 - 7.1)

I think it's pretty fast - but you might be able to see stuff happening in iwstat output?

Migrateduser

Thank you ghoti & nipper for your prompt responses. I'll keep note of the steps outlines in ghoti's reply and let you know how it goes

namithapai

iwmigrate doesn't lose history.
The reason for iwmigrate (as opposed to just using a copy of the old store as if it were the new store) is that between versions of the product IWOV has occasionally included improvements to the backing store - and unless you do the iwmigrate step you don't get the benefits of those improvements.

This is much more necessary from pre-6.x to 6.x versions but also applies (I think) to going between some of the various 6.x versions and thus is reasonable to consider doing if you're going to 7.x

If you're not concerned about potential differences between the old and new version's native backing store (well, new and old-automatically-converted-to-new) formats then using the copy as-if it were new is fine (and definitely quicker)

In your opinion, if I am moving from 5.5 to 7.1 and the old teamsite does not use anything but workflows and content store (i.e. No formpublisher) and users will be created new, does it make sense to do iwmigrate or just copy?

nipper

In your opinion, if I am moving from 5.5 to 7.1 and the old teamsite does not use anything but workflows and content store (i.e. No formpublisher) and users will be created new, does it make sense to do iwmigrate or just copy?

You cannot migrate from 5.5 to 7.1

5.5 was EOL years ago. You can create a new branch in 7.1 and copy the Staging area into it.

Anything else will be long and painful. If you really need to migrate content with history from 5.5, bring in a consultant to help. I have done it once (5.5.2 to 6.7), it was quite difficult and time consuming.

Adam Stoller

You cannot migrate from 5.5 to 7.1

5.5 was EOL years ago. You can create a new branch in 7.1 and copy the Staging area into it.

Anything else will be long and painful. If you really need to migrate content with history from 5.5, bring in a consultant to help. I have done it once (5.5.2 to 6.7), it was quite difficult and time consuming.

I'm not sure if we're agreeing or disagreeing, but I've done several 5.5.2 to 6.x upgrades and I've always copied the existing store onto the new server, mounted it as a temporary second store and then used iwmigrate to bring all the content and history and such into the new [6.x] default store.

Yes, it's time consuming.
Yes, you need to make sure you have lots of disk space.
Yes, you need to run iwfsshrink on the default store afterwards.

Whether or not this same approach will work from 5.5 to 7.x is questionable, but I have a feeling it will.

nipper

You cannot got from 6.5 to 7.1, you need to go from 6.7.1 to 7.1 backingstore. So to go from 5.5, you *probably* need to go to 6.5, then 6.7.1, then 7.1

Yes it is possible, very time consuming and not for the faint of heart. I ended up writing a custom script to copy versions instead of the upgrades that were required.

namithapai

Actually the biggest leap iwmigrate can do seems to be from 5.5 to 6.7.1.
I have already setup a dev server with 6.7.1 SP1. Done a copy from daily tape backup(which is a full backup and not partial) and set it up as default store(no iwmigrate) I have created new forms with formspublisher and new WFMs also. Everything seems to be going great except that the new hardware has 16 cores and we have a prod license for 4 cores only. So the plan is to get a new box with 4 cores only. So my thought process is that if we are going to setup a new box anyway, maybe I should go to 7.1.

Reasons are:
1. I used copy /no migrate and things looks good so far.
2. 5.5 setup does not use Formspublisher so I have no concern with extended attributes.
3. All the workflows WFT have come over ok and are working well with WFM
4. Users have not been migrated , but created new with new security as per company guidelines.

I am really attracted to Ghoti's approach , but feel that iwmigrate step will not work for me for 5.5 to 7.1 as it is not supported.

So when I saw this thread, I started wondering what may be the affect of backing store changes through the different versions that I am not seeing now, but may arise in the future.

nipper

2 points

I guess you can upgrade from 5.5 to 6.7.1 to 7.1, if you copy the 6.7.1 SP1 backingstore, it can be read by 7.1. There was a slight change at SP1 (I think) that is required for 7.1

That being said, there is a major change that you would not be using. When search was introduced, the backingstore was restructured to be much more hierarchical, more folders, less number of files per folder. That made search much better. To get to that point you need to install fresh or run iwmigrate. Use that script I mentioned if you want to see how bad things are.

namithapai

Thanks for the tips.

At this point of time we don't have plans of using the teamsite search feature.

I am going to try a fresh install of the latest version of Teamsite once we get a new box with just 4 cores.

Copy of store from 6.7.1 SP1

copy of all app code

Create new users.

Thanks for all the pointers. Helps to think aloud in type :-)

TestMapping.rptdesign

Migrateduser

Hi All ... me again (you may recall I started this thread!)

Happy to report my content conversion was a success... I also followed the instructions in KB article 58745 which eaqually applies to a v7.1 install and it all worked like a charm