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 Upgrade

mksiw

TeamSite backing store conversion and TeamSite upgrade [5.0.2 to 5.5.2]:

We're planning a upgrade from 5.0.2 to 5.5.2 in Win2k environment. The Same server is going to be production server after upgrade. Iam looking for a some valuable tips from you to have a minimum downtime. I have another Development Box for doing the conversion of Backing store.

I feel someone should have gone though this risky process ...looking for your valuable input from your experience...

thanks
IW_mksw

Find more posts tagged with

Comments

gwen1

We went through this process on Solaris, not W2k, but hope to be of some assistance. We converted on another server and moved to production one after the upgrade. Planning is the key, including planning for failure. I ran several test runs prior to the real time. In my testing, was able to get some maximum estimations, etc. When began the actual production conversion had a strong idea of time involved. I also broke the conversion process up in several stages. One branch at a time, etc. Between each conversion script, backed up the newly created backingstore and ran the backingstore check utility against it. [This paid off since the 5.5.2 server was rebooted in the midst of a conversion script] Conversion script must end on an edition for it to be a good run and if stopped in the midst of the must start all over again. Started conversion a few days early and users saw no impact to performance. My only outage to the publishers was during the final conversion which was only that day's publishing and during the software installation. Started at 5 p.m. Friday night and testing, etc was completed by noon the next day.

Gwen

NathanW

Im about to embark on a similar exercise. It would be great if you discover any 'undocumented' features or tasks during your upgrade if you could post them here fo us all to share.

Gwen seems to be taking the same approach as us - lots of planning time and planning for failures.

Fingers crossed we dont have any problems......

Nathan Wall
Department of Transport and Regional Services (Australia)

NathanW

Gwen

For those of us just starting out on the upgrade - would you be able to share some metrics about how long the process took?

For example - how many branches and editions were you working with?

Did you transfer all of your previous editions?

How rigorous was your testing? DId you miss anything that didnt show up until later?

Despite all the techno documentation that IWN provides I think these kind of metrics / issues checklists are really missing........

Cheers

Nathan Wall
Department of Transport and Regional Services (Australia)

gwen1

The actual conversions took around 38 hours. This metric does not include time lost due to checking of the backingstore, backups and time lost due to the server reboot. We have 14 branches but the bulk of the content published on a daily basis is on only one branch. On that branch, approximately 2000 files are submitted on a daily basis and there is approx 33,000 files/directories present. A few of the other branches have a large amount of content but does not change as much on a daily basis.

We did not convert the entire backingstore. We fell under new SEC regulations beginning the month of the upgrade, so wanted all of that content in the same format. (We currently already have a process for retrieving documents from old backingstore on another server) We converted about 2 weeks worth of content. The initial edition conversion took the longest, since it basically clones the content it finds. The branch with 33,000 documents took close to 10 hours for the first edition to convert. Since we only publish one edition per day, the following editions for that branch took approximately 1 hour apiece. Smaller branches where there were only 500-800 submits per day did not take that long.

Application team tested staging files in editions during one of the tests. Also checked that the history for several files were intact.

I mostly tested the scripts and process to determine timeline and servers. My initial plan had been to convert everything during the upgrade weekend, but testing showed that unless everything went faster than expected, we would not have time. Networks that your servers lie on will play a big role. My two servers were not on the exact same subnet although they were both on production subnets. Server CPU in our case could also play a factor. I would recommend using something bigger than the minimum listed in the documentation, we overwhelmed a single CPU server during testing of this.

Gwen

Migrateduser

The time to convert is dependent on many things, including the size of the store you are converting, whether you are converting all editions, how many editions you have, whether you have in-process workflows you want to preserve, how much testing you want to do, whether you want to update any WF or Templates or not, etc.

I think there are some pretty good information on the support page:
https://support.interwoven.com/library/manuals/teamsite/552upgrade/552upgrade.asp

From reading the upgrade closure paperwork from IWOV consultant conversions, the process takes from 2-10 days. I have not seen any paperwork indicating longer, unless new templates or workflows or users were involved.

lissa

mksiw

It will be really nice if anyof you share your encountered UID issues.

In my case I have no domain. All the users and groups are local to the teamsite server. If this is the case do I need to do IWIDMAP twice both in the dev server and again in production server after I move the whole backing store to prod after testing.

thanks

Migrateduser

We have also seen some customers take the route of copying content to the new TS 5.5.2 store instead of doing conversion. This option is good for some of the content where version history isn't important to you. If you have some Branch where you just want to take a snapshot of the content and start from there in the 5.5.2 system, copying the content will be quick for you to get started on new initiatives. As Gwen mentioned, if you don't need all of the old editions in the past few years, you can cut your conversion time by starting from x number of weeks/months back. Be sure to plan this carefully because you are essentially starting a new base for your version history in the new store.

mksiw

Thank you all for your really valuable tips.