Recently, we performed a successful migration of around 68,000 CAD documents for one of our clients. We went from our old PTC PRO/Intralink 3.4 server to a shiny new PRO/Intralink 10 server with very few disruptions and issues. This may seem like a daunting task and believe me, it was not easy. I’m writing this blog to tell you a bit about my experiences with the migration and 5 simple steps you can take to make your migration a relatively pain-free experience!
Below are some general steps and procedures that apply to most installations (although every organization is unique in how they manage their CAD document control). Feel free to comment and provide your experience, as I’ve found that knowledge sharing in this field goes way beyond a boring user manual.
Step 1: Plan, plan, plan
The key to a successful migration in the PRO/Intralink world is: planning. By plan, I mean to think of every contingency and pitfalls and disruptions that will come about due to this migration. For us, we started planning this migration about 10 months ago. It may not be required at your company to plan that far out, but definitely give yourself time to come up with everything to make your migration successful. Some items that we planned for and that you should keep in mind:
- What needs to be migrated
- How to do the migration
- When to do the migration
- A test migration plan
- Rollback plan in case of migration failure
All of these are important to get in place before doing an actual migration. When we were doing this migration, each one of these bullet points were addressed and executed. If we had not done this type of pre-migration planning, the real migration most definitely would have failed.
Step 2: Over capacity, not under
One thing I saw in community forums regarding migration from 3.4 to 10.0 was the fact that the new system ran far slower than the older system. That makes sense as PRO/Intralink 10 is built on a modern platform and as such, requires modern infrastructure to handle the capacity. What might have worked for 100 simultaneous users on a 3.4 server will definitely not work for a 10.0 server. One infrastructure change we made when going to 10.0 was we host the Oracle database on a separate server. If your organization can’t have separate server, make sure the system you build is powerful. I recommend a minimum 16 gigs of RAM, and at least 2 quad-core or more processors. This is all dependent on how many users you’re supporting. The key is to make sure you have more capacity than less capacity.
Step 3: Setup a test server
It goes without saying that you should have a test server setup with PRO/Intralink 10 before you even consider doing a real migration on production servers. This gives you a chance to test out changes, perform test migrations, and even let users play with the new system with test data so they can get familiar with the new interface. I highly recommend setting up this test server as a VM (virtual machine). That way you can utilize snapshots and revert to them. This comes real handy when doing test migrations. I probably reverted to my snapshots over a 100 times when I was testing on our server.
Step 4: Perform a test migration
Actually, you’ll need to perform several test migrations, not just one. The PRO/Intralink data migrator tool provided by PTC is somewhat straight forward but it does have a lot of quirks and doesn’t always work the way you expect it to. As such, you should perform a test migration as many times as you need to so you feel comfortable with the process and steps involved. For our test migrations, I was able to find an old Sun server that I copied our production server’s configuration to and setup as a test server to practice migrations from. It worked great and I would say it’s a MUST before doing a real migration.
Step 5: Be prepared
It goes without saying that you will encounter issues and questions from users after you perform the migration. Just be prepared to handle these issues as they come up. If a major issue occurs after migration (data loss or corruption), be prepared to rollback to your old system so you can work out what that issue was. If you had done test migrations, you should have identified any major issues during those exercises, but you can never know for certain when doing the real thing.
One issue we encountered when we released the 10.0 server for production was slow performance when put under load of several users. We had test users on our test server, but the most that were connected at once were 2 or 3. Once we had 15-20 users on the production system, we noticed the performance of the server dropped drastically. We overcame this by increased the Java heap sizes, and then restarted the server. All of a sudden, performance was ideal! If you know that beforehand, you can prepare for it and optimize your system.
Summary
I hope that these steps help with your migration. I realize that every organization and structure is unique and not every scenario that could happen would happen, but following these steps will definitely put you on the right path for a successful migration. Again, please comment below and provide any experience you’ve had or if you have questions, feel free to ask!
Bradley Tinder, System Integrator, SPK and Associates
