Is a Intralink 3.4 fileserver clone really required for test migration to 9.x?

Clarification: I meant hundreds of gigabytes (not megabytes)

Gerry.

Gerry,

As you have probably seen, the data migrator (DM) includes scripts that are copied over to the Pro/I 3.4 data source system. Two important scripts are run in succession on the Pro/I data source system to put it into a mode that allows the DM running in a Windchill shell on the Windchill destination system to connect with the source and carry out its migration duties. The two scripts on the source system first place it in a somewhat restricted mode, the second script completely restricts all user log in. So, if you have a Pro/I system that must remain in production while trial migrations are being carried out, the only path I know of is to create a full clone, put that clone in that very restrictive mode, and use the clone as the source system for the DM.

Full clone means another system with Pro/I installed (and the typical installation of the file server and data server), a valid import of the production dump file, a copy of the data vaults mounted to a local drive to the clone system, and the pointers within the database redirected from the production vaults to the clone vault location. So yes, this means you need a system just can handle the data size of the production system.

It is common to create the clone on the same OS as the production – but this is not necessary. I have a clone running on MS-Windows of a production system running on UNIX. It’s easy to jump OS’s with Pro/I 3.4. Once this clone is completed, you are free to proceed with your DM efforts, tests, trials, etc. If you find issues in the data, you can try out remedies on the clone before attempting to do so on the production system. Some folks never touch the production system but apply all data cleaning efforts on the clone.

The DM does not modify the source Pro/I vaulted data. You do not need to deliberately place the vaults in RO mode. As mentioned above, two scripts are run to toggle the data server to place it in migration mode. You run two more scripts to toggle it out of migration mode and you can log back into it.

You have a lot of data to migrate. The last thing I would want to do is to use hardware (i.e.; a cheap TB drive) that has low performance (like throughput). When carrying out the ten major migration steps (Document, Links, FT, UDA, etc.), there are times when the DM stresses the Windchill destination system CPU’s. If you are using a multi-tier Windchill destination system with the database (i.e., Oracle) running on a different box, the rate of data writes can get very high. I have seen some steps take days to complete.

I once did a migration from a non-PTC product to Pro/I and the hardware I had to perform the data migration was older CAD workstations (with relatively large hard drives) hooked up to the network. It worked. It was painfully slow. It was really cheap. I don’t want to doit that way again.

Doing a DM from Pro/I to Windchill is not trivial. Some level of hardware is needed below which I would be hesitant to even pursue it.

Jon

Many thanks to all that replied.

There were some conflicting replies.
But the consensus was that I should do the following:
1) Clone the 3.4 dataserver and create a new, dummy fileserver.
On the clone dataserver, move the vault(s) to the dummy fileserver, but do not allow the tool to actually move the files, nor move them manually. Therefore, the dummy vaults are empty. In my tests, I used SQL statements to redefine the vaults, which was much faster and easier than using the DMSU,
2) Do the migration in Pre-Copy mode, which will not access any fileservers.
3) The 3.4 vaulted files should be copied to the same drive where the Windchill vaults will be.
During migration, the files will simply be moved to their final location, which is fast and minimizes disk space requirements for the migration.

Thanks again.

Gerry