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; } } }

Migration from Windows(TS 6.7.2) to solaris(TS 6.7.2)

LIWoven

Hi All,

We want to do migration from Windows Machine to Solaris Machine.
There is no upgradation and we are using Teamsite 6.7.2 and Livesite 3.1.

Can anyone give some guidelines that what steps should be performed so that we can migrate our entire
-> teamsite/Livesite content with extended attributes
-> configuration files
-> users
-> workflows
-> all customization/custom code.

I read in forums that there is one migration manual available on support site but i am not able to get any.
Please specify where i can find any manuals related to this.

Thanks in Advance
Monika

Find more posts tagged with

Comments

Adam Stoller

Hi All,

We want to do migration from Windows Machine to Solaris Machine.
There is no upgradation and we are using Teamsite 6.7.2 and Livesite 3.1.

Can anyone give some guidelines that what steps should be performed so that we can migrate our entire
-> teamsite/Livesite content with extended attributes
-> configuration files
-> users
-> workflows
-> all customization/custom code.

I read in forums that there is one migration manual available on support site but i am not able to get any.
Please specify where i can find any manuals related to this.

Thanks in Advance
Monika

I don't believe the migration manual will help much since I believe it focuses on supported migrations - switching OS from Windows to Unix (or vice-versa) is not supported - so unless you want to spend a lot of hours trying to recreate the history of all your files one-by-one, you're pretty much stuck with a surface copy of the files from the staging area on the source server to the workarea on the target server - and copying the EAs and such as well -- If you have a reasonably up-to-date version of OD handy on both servers you should be able to configure it to help you do these surface copies and preserve the EAs as well.

Thats for the content.
For the other stuff:

If you don't feel comfortable doing this kind of thing, I'd recommend hiring a consultant (such as Nipper, Boris, or myself) who has significant experience in TeamSite development and server migrations, to help you get it done.

nipper

Ghoti hit the majority of the issues. I just spent some time doing it and will through out another nugget: scripts. Any perl scripts at the very least will need to be changed for the shebang line. The invocation will require a new command as well. Depending on how well whoever wrote things stuck to standards. One thing I hit was code like this:


$iwhome = TeamSite::Config::getiwhome();
.
.
.
$pathToPerl="C:\\Interwoven\\iw-home\\iw-perl\\bin\\iwperl";

Even though they had the information to make that portable they still messed it up,

ALso, DCTs & TPLS can have perl embedded as well.

Good luck,

Andy

LIWoven

Thanks all for replies. It seems that if we have to do a lot of manual things if we do migration b/w two differernt OS/Platforms.

Just for my knowledge i want to know that does same applies if we want to do migration within same platform(Windows-Windows).

All steps remain same for migration within same platform or they are different??

Regards
Monika

Adam Stoller

Thanks all for replies. It seems that if we have to do a lot of manual things if we do migration b/w two differernt OS/Platforms.

Just for my knowledge i want to know that does same applies if we want to do migration within same platform(Windows-Windows).

All steps remain same for migration within same platform or they are different??

Regards
Monika

Whenever you switch servers you have to consider what's the same and what's different between the two environments, and then consider what (if any) impact the difference might make.

Clearly if you install TS in a different path on the second server - you have to make sure that any such path references in your configuration files and/or customizations are updated accordingly.

If you use local disk accounts and/or groups on a Windows machine, you have to remap them using iwidmap on the new Windows machine (generally you will always have at least a few such entities that need to be remapped) - and there are good KB articles about how to use iwidmap on the support site.

Depending on how your workflows were written, you may be able to transfer active jobs from one server to another (if so desired) - or you may have to make sure not to migrate the jobs at all.

If you're not comfortable doing this kind of thing - perhaps because you don't have that strong a background in TS - you should consider hiring an experienced consultant to help you through the migration (whether we're talking about same OS's or different OS's) - as ultimately that will probably save time (and money) and will be more likely to produce good results. Otherwise you'll probably end up on the phone with Support a lot - who may help you with the configuration files but probably won't touch custom code (including, but not limited to: workflows, DCTs, FormAPI, custom menu items, etc.)

If you are comfortable with it - great!

nipper

Some depends on the coding standard in use. I have seen some implementations that would make it difficult to move from 1 windows server to another (hardcoded host names etc). But staying within the same architecure is easier.

That being said, if it is appropriate to move to Unix then do it. I went from a Windows env to a Linux env recently, while I estimate 8 weeks, I was able to knock it out in a couple weeks. What we are talking about is worst case - it can be easier.

Andy

LIWoven

Thanks all for your replies thats really useful

Ugan

Cross Platform migration is not possible/not recommended it leads to recreate the whole application initiating from first step starting from creating users ending upto creating content. While Unix based OS migrations for upgrades like TS on Solaris to TS on Linux and vice versa are possible.

In your second reply you mentioned windows to windows ? is that windows OS migration (ex: TS on w2k to TS on w2k3) ? if so you can follow the upgrade steps, since you are doing for same version you will not require much manual changes apart from the bigger activities like migrating users and migrating content.