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

transitioning TeamSite to another OS

jrMugz

Greetings,

We are wondering what might be the main challenges of transitioning a TeamSite system from Unix to Windows, as we are looking to do this for a client that we would host.

Please advise on what it would take for this transition.

Thank you,
Jim

Find more posts tagged with

Comments

nipper

Serious project, this is not a trivial task.

There are 100 moving parts you need to coordinate/change. Hope you have done this before or get someone who has.

Why change platforms ? Do not mix OS if you can help (i.e. push from Windows TS to Linux RTE).

Adam Stoller

Greetings,

We are wondering what might be the main challenges of transitioning a TeamSite system from Unix to Windows, as we are looking to do this for a client that we would host.

Please advise on what it would take for this transition.

Thank you,
Jim

Do you need to transition to Windows - or just from Unix servers to i386 servers?

I.e. - you could go from Solaris to Solaris x86 or Linux - both of which would probably entail much less in the way of changes to customizations than moving to Windows.

I believe you can migrate the backing store from Solaris to Solaris x86 or Linux - you absolutely cannot migrate the backing store from Unix to Windows.

Bowker

We are a mixed shop - TS on Windows, LS on Linux.

If you have customizations on the Linux version of TS they will obviously need to be looked at closely.

One of the largest issues you may have, depending upon your situation, is file name collisions. If you have file names like: annualReport.pdf and annualreport.pdf in the same directory you will have to make a decision which to keep. You can't have both.

We looked in to going the other direction and found that our customizations would require too much time/money/effort/.... and stuck with the windows environment for TS.

Adam Stoller

We are a mixed shop - TS on Windows, LS on Linux.

If you have customizations on the Linux version of TS they will obviously need to be looked at closely.

One of the largest issues you may have, depending upon your situation, is file name collisions. If you have file names like: annualReport.pdf and annualreport.pdf in the same directory you will have to make a decision which to keep. You can't have both.

We looked in to going the other direction and found that our customizations would require too much time/money/effort/.... and stuck with the windows environment for TS.

Understood - but you were starting with TS on Windows - yes?
The original poster seems to be starting with TS on Solaris (presumably *not* x86) - so the question is whether they really want to move to Windows or just want to move to x86 boxes - for the latter, they could choose Windows, Linux, or Solaris 10 (at least for 7.3.1 and possibly earlier versions in the 7.x area - can't remember off-hand when Solaris 10 for x86 started being supported).

Hence my question about whether they really want to go to Window - and the fact that if they do - they basically lose all version history (or have to go through a lot of contortions to re-create it) because the backing store cannot be migrated in that scenario.

jrMugz

Thanks for the responses. To be clear we are moving from a Solaris (RISC) on both the TeamSite and Web servers to a 100% windows environment. We have a good grasp of the file names and customizations. Our concerns are around migrating the application components, templates, database, stores etc. Please advise, and thanks again.

Jim

nipper

You cannot move the stores.

You have to use OpenDeploy to move branches from one store to another. That loses a lot of history.

Customizations ? Depends on what they are. Often finding them is harder than moving them. But if they are written poorly, you will have a lot of work to do.

This will be a completely new install. Then you copy everything over and start fixing things.

This could be a 2 week project (OK, on the very light side), or could be 4-6 months (on the ugly side).

Adam Stoller

You cannot move the stores.

You have to use OpenDeploy to move branches from one store to another. That loses a lot of history.

To be a bit more precise, you would be using OpenDeploy to transfer a copy of specific versions of the files (from an edition, staging, or a workarea) from the source [Solaris] server to a workarea on the target [Windows] server - you'll probably want to make sure you're transferring EAs, but you won't be transferring any of the history, comments, user-information associated with the files - they would all end up getting submitted by you (or whatever account you're using on the target [Windows] environment) with the current date and time and with whatever comment you decide to use.

You could build up a more complex process that attempts to preserve some of that information from the source side or a much more complex process that attempts to re-create some or all of the historical versions of the files -- but that's way beyond the kind of thing that is likely to be discussed in any detail within a public forum.

Customizations ? Depends on what they are. Often finding them is harder than moving them. But if they are written poorly, you will have a lot of work to do.

This includes things like path references (fortunately, moving from Unix to Windows you don't have to worry about the direction of the slashes - just the actual path), and assumptions about OS-specific CLTs (e.g.: Unix has ls, Windows does not - unless you're using Cygwin or similar). As nipper indicates, the better the code was written, the fewer the problems of this kind you are likely to run into - and vice-versa.

This will be a completely new install. Then you copy everything over and start fixing things.

This could be a 2 week project (OK, on the very light side), or could be 4-6 months (on the ugly side).

I don't think I would even consider it as being less than 1 month (you could get lucky - maybe there were no customizations or the few that were there were very well written; maybe there's very little content to actually get moved - like they had only been using TeamSite for 1 week before they decided to switch platforms, but ...) - and the amount of time it will take is dependent upon degree of customizations, the level of information that is desired to be preserved, and the skill of the person / people involved in doing it (I'll let you be your own judge of your competency).

jrMugz

Thanks again for all the feedback, everyone.

So, what I am hearing, please confirm, is that we can

1) install a new version of Teamsite.
2) use OpenDeploy to transfer the application components, templates, database, stores etc from the Solaris to the Windows; but lose all of the version history.
3) do our personal customizations manually, which can take a while or not, depending on how easy to find.

One other question, ghoti, you said "you'll probably want to make sure you're transferring EAs"; what do you mean by EAs, what does that stand for?

I realize you're saying just the current records can be transferred, but not sure what the EA acronym is specifically referring to.

Thanks,
Jim

Adam Stoller

Thanks again for all the feedback, everyone.

So, what I am hearing, please confirm, is that we can

1) install a new version of Teamsite.

Correct.

2) use OpenDeploy to transfer the application components, templates, database, stores etc from the Solaris to the Windows; but lose all of the version history.

NO - you are not transferring databases or the backing store with OpenDeploy. I'm not sure what database information you would be transferring anyway (probably none) - but you would only be transferring content from within TeamSite to the new server - not the backing sotre.

3) do our personal customizations manually, which can take a while or not, depending on how easy to find.

Correct, essentially.

One other question, ghoti, you said "you'll probably want to make sure you're transferring EAs"; what do you mean by EAs, what does that stand for?

Given that you don't know the term EA - you're probably looking at something closer to the 4-to-6 month range for doing this - possibly longer, and it sounds like you should be bringing in a knowledgeable consultant to assist you.

I realize you're saying just the current records can be transferred, but not sure what the EA acronym is specifically referring to.

Thanks,
Jim

"EA" = Extended Attributes / Metadata.

Bowker

(correction)

IWMIGRATE will not work cross platform. (I'm getting old, memory failing)

According to support 2 years ago, IWMIGRATE will only work for the same platforms.

(sorry for my forgetfullness)

mart2001

Does it matter if the backing store is on a SAN/NAS? Can you just unplug the SAN/NAS from the Solaris TeamSite machine and plug it into the Windows TeamSite machine?

nipper

Does it matter if the backing store is on a SAN/NAS? Can you just unplug the SAN/NAS from the Solaris TeamSite machine and plug it into the Windows TeamSite machine?

Nope, that does not work. Solaris to Linux works, not DOS to Linux

Adam Stoller

Nope, that does not work. Solaris to Linux works, not DOS to Linux

Or vice-versa ...

Frederik

some good info, even for long-time "expert" on this side of the keyboard Smiley Happy

I didn't know that iwmigrate can't be used cross-platform Win-Unix/Linux.