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

Using iwmigrate to copy content stracture

melthan

Hi,

I have a requirement to clone the existing content store without the content to another store in a newer version of Teamsite. I only need to retain the store structure that includes all the branches and sub-branches, workarea and permissions. I tried using iwmigrate, but it is coping all the content along with it. Has anyone done this before?

Thanks in advance

Find more posts tagged with

Comments

nipper

Hi,

I have a requirement to clone the existing content store without the content to another store in a newer version of Teamsite. I only need to retain the store structure that includes all the branches and sub-branches, workarea and permissions. I tried using iwmigrate, but it is coping all the content along with it. Has anyone done this before?

Thanks in advance

iw_migrate implies it migrates content.

You may be able to run iw_migrate with no editions (basically getting the latest version of everything) and then removing the content. If there are so many branches that doing this manually takes more than a couple hours, you can write a perl script to do this, but I would really think about doing it manually first.

melthan

Hi,

nipper - Thanks for your reply.

We have thousands of branches and since we are moving to a newer version of Teamsite, the migration of the content will increase the downtime which is not feasible for us at this time. Any other suggestions?

Thanks

interDev

Hi,

nipper - Thanks for your reply.

We have thousands of branches and since we are moving to a newer version of Teamsite, the migration of the content will increase the downtime which is not feasible for us at this time. Any other suggestions?

Thanks

As nipper mentioned, write down a perl script to copy all the branches, premissions, roles etc. this would be best possible solution for you.

Adam Stoller

Hi,

nipper - Thanks for your reply.

We have thousands of branches and since we are moving to a newer version of Teamsite, the migration of the content will increase the downtime which is not feasible for us at this time. Any other suggestions?

Thanks

I'm a bit confused. If you really only want the structure (with permissions) - then you should be able to write a script that can capture the information on the source side (creating a data file) and then use that information (from the data file) on the target side to re-create the structure with the permissions. There are a number of CLTs you can use to capture the various bits and pieces of permission information, near-basic directory walking code should be able to be used to capture the actual structure information -- probably about an hour or two's worth of work if you know what you're doing.

If you're moving from a pre-6.7 version to a 6.7 or 7.x version, you'll have more work to do since the role and permission information is different.

If you're moving to a new server along with a new version - iwmigrate is probably the best way to go unless you plan to start from scratch as far as content is concerned (highly questionable, but possible), assuming you've been doing a reasonable job of creating editions on the branches at regular intervals you can choose to migrate only the last N edition's worth of content rather than the entire history. If you plan things out right (and follow the plan) you can do multiple passes for the migration - and do most, if not all, of it on the new server thereby reducing the downtime for people who are using the old server (until the actual cut-over, but even then the downtime can usually be kept to a weekend if you did things right).

If you don't know what you're doing - I suggest hiring someone who's done this kind of thing before (myself, nipper, boris, and probably at least a couple of handfuls of others who frequent these forums), as you'll only end up costing yourself more time and money doing it wrong.

nipper

With "thousands of branches" someone really needs to look over what you have and restructure that. I have seldom seen more than 100 and that was a huge waste. There are certainly cases where 200-300 may be appropriate, but thousands ? IDK...

melthan

Thanks for all the responses

Yea we have way too many branches. I guess it is a unique case. But the plan is to reduce it as much as we can as part of the migration.

Based on the benchmark that we did, it will take more than a weekend to complete the just the migration. But then you add in the testing and other activities, the window was span across a week (which is not feasible).

Our original plan was to recreate all the branches, workareas and set the permission using a script. Then finally, use OD to copy the latest content (no need to retain the history) so that the content is recreated in the new format.

But we wanted to see if the same can be achieved using "iwmigrate" to avoid the script part.

It is looking like we have to go down to the script route or segment and use iwmigrate with multiple short outages.

Thanks

nipper

Just for a frame of reference, a weekend to run iwmigrate is considered short.

But that is often with 10's of branches and thousands of editions

Adam Stoller

Just for a frame of reference, a weekend to run iwmigrate is considered short.

But that is often with 10's of branches and thousands of editions

True - I wasn't taking the "thousands of branches" literally as being thousands of [content] branches ... I know a number of implementations in which there are numerous branches set up to provide structure, but only the leaf-node branches actually contain content.