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

How to migrate from 6.7.2 w Derby to 7.4.1?

Binettoid

Hi all,

It's been a while since I did this kind of a migration but, if we didn't need old editions or history, I think we'd have it covered. Alas, we do.

Things are made worse by the use of Derby (the default in 6.7.x).
Does anyone remember the issues faced when migrating from this environment, and know anything to watch out for in the shiny new environment?

Also, will workflows from the old environment work in the new?

Many, many thanks for any insights.

Find more posts tagged with

Comments

Adam Stoller

It's been a while since I did this kind of a migration but, if we didn't need old editions or history, I think we'd have it covered. Alas, we do.

Are you doing an upgrade on the same server, or a fresh-installation on new servers as part of the upgrade?

Things are made worse by the use of Derby (the default in 6.7.x).
Does anyone remember the issues faced when migrating from this environment, and know anything to watch out for in the shiny new environment?

This sounds like an upgrade in-place. You can try to check with Support - I have no idea whether the data stored in the derby db gets migrated to the newly selected db, nor do I know if it really matters too much unless you're actively using Reporting (again, worth checking with Support)

Also, will workflows from the old environment work in the new?

Workflow templates? Workflow Models? or existing jobs?

can make your life a lot easier with regard to customization migrations. It won't work on the store's themselves, but you can use it to compare/transfer files within the workareas and on the local disk.Hope that helps.

Binettoid

Hi Ghoti, thanks for your response!

This is a migration to an all-new platform.
So, we'll be installing a new (set of) server(s) from scratch.
Tasks to be performed include:
- Migrating user accounts - only 10-15 active users, so I'm interested in divorcing the user accounts from AD and managing them completely within TS. This is still possible in 7.4.x, right? Pros/cons?
- Migrating content - will moving the iw-store to the new platform recreate editions, history and content files, or are the versions in question too different to allow this operation?
- Migrating EAs - have some custom scripts using the iw-scripts that worked for this up to v.7.1 - assuming we'll be able to use the same approach to extract EAs from Derby but are there any gotchas here and will this approach still work in 7.4.x?
- Migrating Workflow templates - any issues moving these from 6.7.2 to 7.4.1?
- Migrating deployments - again, as above
- Upgrade and (re)configure disparate OpenDeploy receivers
- Install SSI for Apache page previewing

Does this make sense? It's so easy to forget something...
Many thanks!

Adam Stoller

This is a migration to an all-new platform.
So, we'll be installing a new (set of) server(s) from scratch.
Tasks to be performed include:
- Migrating user accounts - only 10-15 active users, so I'm interested in divorcing the user accounts from AD and managing them completely within TS. This is still possible in 7.4.x, right? Pros/cons?

They're still AD users, and essentially all you should need to do is copy over the

IWHOME/conf/roles/tsusers.xml

file and, if you used it, the

IWHOME/conf/tsgroups.xml

file. The tsusers.xml file will need to be edited slightly to change any local-server users (like "Administrator") so that they have the new server name as the domain. If you had other local-server accounts you'll either want to do the same (and recreate them on the new server) or ignore them and take care of them through the use of iwidmap (which you may have to use anyway, especially if there were users who no longer exist or are no longer involved with using TeamSite)

- Migrating content - will moving the iw-store to the new platform recreate editions, history and content files, or are the versions in question too different to allow this operation?

You can generally simplify this process by using the existing content store(s) from your old server on your new server - but you need to be careful about this:

Sounds right.

Binettoid

This is gold, thank you Ghoti!
Between your insights and the documentation, the dots are joining up...;-)

Perhaps a couple of smaller points:
- Regarding user accounts - the new platform is to be a remote hosting environment 'in the cloud' - it would therefore be simpler to migrate user profiles and sever connectivity with AD, Domains, etc. and simply manage the small number of users completely within TeamSite. Is this consistent with what you describe here?

Regarding the content migration, can I just clarify:
- Stop iwserver on the new server and rename IWSTORE/default to IWSTORE/741_default
- Put the 641 default store into place on the new sever in IWSTORE/
* When you say 'put the 641 default store on the new server', you mean 672 don't you?

- Start the iwserver process
- Use iwstoreadm to deactivate the default store and activate the 741_default store
*so we're pointing TeamSite at an empty, new store?
- Use iwmigrate to transfer the /741_default/component-guide branch into /default
*why the component-guide branch?
- Deactivate the 741_default store and activate the default store (when you're completely done, remember to remove the 741_default store directory)
- Stop the iwserver process and run iwfsck -d on the backing store
- Start the iwserver process and run iwfsshrink on the backing store

Our iw-store is apx. 30GB in 4 branches. Should we attempt iwfsshrink before migration? We can try to break it up into branches to reduce the file transfer size.

Many, many thanks again!

Adam Stoller

Perhaps a couple of smaller points:
- Regarding user accounts - the new platform is to be a remote hosting environment 'in the cloud' - it would therefore be simpler to migrate user profiles and sever connectivity with AD, Domains, etc. and simply manage the small number of users completely within TeamSite. Is this consistent with what you describe here?

TeamSite does not have its own innate sense of users (it does for groups, but not users) - so the users would still be AD users. You can manage the users within the TeamSite Admin UI but, again, they would still be AD users so the iw.cfg would have to be configured to connect to your AD servers even if the TeamSite servers are being hosted in some other domain.

Regarding the content migration, can I just clarify:
- Stop iwserver on the new server and rename IWSTORE/default to IWSTORE/741_default
- Put the 641 default store into place on the new sever in IWSTORE/
* When you say 'put the 641 default store on the new server', you mean 672 don't you?

Sigh - fingers were off - yes I meant 672 not 641 (I don't think there was a 6.4.1 release of TeamSite ;-))

- Start the iwserver process
- Use iwstoreadm to deactivate the default store and activate the 741_default store
*so we're pointing TeamSite at an empty, new store?
- Use iwmigrate to transfer the /741_default/component-guide branch into /default
*why the component-guide branch?
[...]

The 7.4.1 store will not be completely empty - it will have the /default/main/component-guide branch within it, hence you want to migrate that branch into your migrated 672 default store. It just makes sense to get the version of content within the 741 component-guide branch into what will be, ultimately, your 741 store. You could keep them separate, but that would mean having to have a license for multiple stores ($$) and chances are there may be some internal expectation that the component-guide branch lives within /default and not some other store (e.g.: /741_default)

Our iw-store is apx. 30GB in 4 branches. Should we attempt iwfsshrink before migration? We can try to break it up into branches to reduce the file transfer size.

There has been discussions in the forums about a possible but in one of the older versions (I believe 6.7.2) where it was recommended that you do not run iwfsshrink on that system. So unfortunately, you have to pay the "time" for transferring the 30GB store to the new server, but after you've gotten it in place (as previously described) and verified it with iwfsck, you should run iwfsshrink on the 741 server (you can run iwfsck on it again afterwards if you want, for that warm fuzzy feeling)

Binettoid

Great stuff, thanks again Ghoti!

Samir_Friend

Great stuff, thanks again Ghoti!

Hi Binettoid,

Can you please post what worked for you and what not with the approach that Adam suggested?

I have a 6.7.2 SP2 system that needs to be migrated to 7.4.1 and I read somewhere that the stores for these versions are not compatible so this activity might require a hop to 7.1 or 7.3.2 before it can be moved to 7.4.1 via direct store copy. Can you please confirm?

Thanks!

itsamb

Hi,
Are you able to get this working? I will have to do the same store migration.
Experts, is there any issue with migrating content from store 6.7.2 to 7.4.1?

Thanks,
Amit

workers.rptdesign

Binettoid

After a few delays, we are about to start this.
I'll let you all know how it goes.