Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Migration TS 5.0.2 to 6.1
fgomez
Hi!
We are planning the migration to Teamsite 6.1 from Teamsite 5.0.2. Our production server is based on MS Windows 2000 but we are going to install a Sun Solaris Server for the migration to 6.1 version: Is it possible? What about the user permissions?
Thanks in advance
Fernando Gomez
Find more posts tagged with
Comments
Adam Stoller
I don't believe there is any officially supported way to migrate between platforms like this - instead it is a series of semi-automated processes that you need to put together yourself where you transfer content from the staging (or edition) area of the source server to a workarea on the target server (via OD, tar, etc.) which requires that all the branches, workareas, etc are setup on the target server beforehand.
Also - you need to take into account the transferring of TeamSite Extended Attributes (if you're using the new OD 6 you won't need a script for doing this, though I'm not sure if OD6 supported TS5.0.2 - in which case you'll need a script to extract the EAs on the source server and apply them on the target server - scripts like this exist on this site, in the forums and/or tech library as well as on the support site)
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
ts_user
We were also doing some initial analysis on migration from windows (where we are right now in production w2k 5.5.2 sp3 ) to Solaris platform. I am not sure if you need to perform the backing store conversion (convert from 5.0 to 5.5.2 format) before you migrate to Solaris platform. Check the Toolbox-> Scripts archive section in the support site for "RecreateBranch.zip" file which contains perl scripts for getting and setting extended attributes if you have no immediate plans to migrate to OD 6.
Thanks.
Adam Stoller
If you're not going to upgrade on the same platform (Windows=>Windows, Solaris=>Solaris, etc) then doing the backing store conversion is not really necessary because it won't buy you anything.
You will end up *copying* data from one server to the other server - and you will essentially be losing all history. The only way to preserve history is to pull the data over one edition at a time - but all the ownership and timestamps will be lost (set to the current user and the current date). The only way to preserve some semblence of timestamps would be to fiddle around with the system time on the target server as you bring things over (not generally recommended and probably not appreciated by your IT staff). The only way to preserve ownership information would be to do a lot of chowns/chgrps everytime you brought files over (a significant amount of work for potentially questionable gain).
I think in general - you would strive to bring over [optionally] the last "known good" edition of content (along with the metadata), submit it, publish it, and then bring over the *latest* version of content (along with metadata), submit it, publish it, and then proceed from there leaving the history on the old server for however long you wish to keep the old server alive (in a read-only mode).
It's a bunch of work - requiring a bit of coordination and sanity checking as you go along - which also makes it time consuming - but I believe that's the only way to "migrate" content from a server on on platform-type to a server on another platform-type.
If you want to be able to use OD6 (to avoid manually copying the metadata) - verify if it works with TS 5.0.2 - if not, *then* you would gain something by upgrading the source server to 5.5.2 - but again, I'm not sure the ends justify the means in this case - and you'd probably be better using scripts for transferring the metadata (OD6 will *not* help with preserving historical date information, nor with user information since the two platforms have completely different UID systems)
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
fjvelasco
Hi
The backing-store is one of a lot of problems. The Perl scripts, the Java programs, the Tomcat and Apache integration, DataDeploy DAS mode, templates, OpenDeploy DNRs, Workflows and their scripts, Oracle connection trought Perl scripts... and the very most difficult of them: security. Unix security is another major problem growed by the LDAP integration of TS.
Interwoven consultants says that "migration is performed in only a weekend", I think that "migration is planned for months and performed in some weeks". The customers don't understand the proccess.
Gook luck ;-)
FJ
Adam Stoller
All good points - though I never said that such a migration could be performed over a weekend. The upgrade on a single platform *might* be able to be done that way (the final cut-over) but a cross-platform migration would take considerably longer for the reasons you stated (and probably others).
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
fgomez
Hi Ghoti!
We are planning to duplicate the hardware platform, and over the Solaris machine to proceed with an empty TS 6.1 installation. Is it the right way? Could we recommend our customer to go on with Windows platform instead of migrate to Solaris one?
Thanks in advance.
Migrateduser
Hopefully, It shd work.
you need to set the EA if you are using diff machine.
also you suppose to set the user permissions and ACLs.
It will work perfectly from 5.5.2 to 5.6. it is untested on 6.0.
plz update me about this progress.
thanx
Rishi Gupta
Interwoven certified teamsite consultant
satyam computer services limited India
Adam Stoller
I'm not sure there's any one "right way" - and you could suggest whatever you think is appropriate. There may be other reasons for them to want to switch to using a Solaris server (*I* prefer Solaris over Windows any day of the week - except if I have to play SysAdmin - and then it's an even draw ;-)
I think you need to first come up with a detailed rationale for both the upgrade and the migration before determining what you're going to do - and then from there determine how you're going to do it.
If 'history' is not required and/or they can leave the existing windows server up and running in read-only mode - the prospect of migrating to Solaris is much easier.
If 'history' is required and/or they cannot leave the existing windows server up and running in read-only mode - the prospect of migrating to Solaris will be very difficult and far from perfect.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
fgomez
Hi Ghoti!
For our customer, 'history' is not required
When you say: "They can leave the existing windows server up and running in read-only mode" What does it mean? Will it run as a backup one?
We are worried about the user´s permissions and the owners of workflows. If history is not required, could the migration to Solaris Server from Windows one, begin installing Teamsite 6.1 on Solaris machine?
Thanks in advance, again
Fernando Gomez
Adam Stoller
Leaving the existing windows server up and running in read-only mode means essentially freezing the backing store and allowing people to reference it if needed to track down some historical piece of information that doesn't exist on the new server. This is *not* a "backup" as you cannot interchangeably use one server or the other for doing your work.
Generally, leaving it around for at least a month after the transition is a good idea if for nothing else than "comfort-factor" - but also as a fall-back (not backup) in case it is quickly found that there are too many problems with the 6.x installation to use it right away and you need to get changes out (the changes would have to be re-created on the old server, but that might be better than waiting a week or more trying to figure out and correct whatever problems you run into on the new server ... again, this is only within the first week or two that you can seriously think of doing it - after that the content baselines will have diverged too much in most cases).
If you aren't preserving history - then yes - you start with a fresh installation of 6.1 on the Solairs machine; re-create the branching structure and workareas; bring over the content and EAs; cut an edition (to rollback to after preliminary testing) bring over all customizations (and spend time making sure they all work) and so-on. Some of this work will have to go on *while* the old server is still being used - so you'll probably have to repeat the content and EA transfer after you believe you have all the customizations working. If there were changes made to the customizations on the old server you'll have to merge those changes into the code on the new server and do some additional testing to verify they still work.
The first phase of this (initial transfer of content/customizations and testing) will probably take at least a week.
The second phase of this (final transfer of content and hopefully no changes to customizations) can probably be done over a weekend.
Somewhere along the line though you also need to spend time [re-]training the users.
Does that make sense? I've probably left out some details here and there - so you need to spend some time documenting what you intend to do and reviewing it before you get started.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
fgomez
Hi again Ghoti!
Once we Re-create the branching structure and workareas (manually I suppose): Can we bring over the content and EAs from TS 5.0.2 to TS 6.1 without any problems?
Thank you very much, again
Fernando Gomez
Adam Stoller
Yes - content can be winzip'd on Windows and un-tar'd on Unix. EA's can be captured on Windows and re-associated on Unix.
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com
Migrateduser
There's no formatting change issue? I seem to remember category/type being category\type on windows, but that may be just my sinility talking.
Adam Stoller
No - forward slashes should be used for EA's (and frankly for everything else IMO since they're understood on both Unix and DOS [provided they're within double-quotes]).
--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com