March 14, 2011

Migrating to Perforce


Planning and execution strategies for migrating from ClearCase, Subversion, and other legacy SCM tools

Moving to a new SCM system is a complicated effort. The process can be delicate, and requires careful planning. Of course, Perforce is here to help!

This brief article is a summary of what you'll need to consider as you plan your migration. These notes aren't comprehensive; in fact, my first and strongest recommendation is to contact Perforce Support in the earliest stages of your migration planning. Our Support team can guide you along the data migration process. Of course, our Consulting team can provide more hands-on assistance, including some detailed information on migration strategies.


Before you start to dive into the nuts and bolts of moving your data over, here are a few essential points to guide your planning.

  • Who are the key stakeholders that should be involved in planning? The list would certainly include IT, the SCM administrators, and a representative group of users. Development managers, product architects, and lead developers would have valuable input.
  • Clearly identify the current state of your legacy SCM system, including the version, the location of the server, and any customizations done to it. Run any available data verification utilities; if you have corruption in your data, you want to know about it now, not halfway through the migration effort.
  • Plan your new Perforce deployment. Make sure your hardware is sized appropriately, and that you have a good backup solution in place. Plan appropriately for distributed development scenarios. (Pay extra attention if you're moving your SCM system to a new platform, handling Unicode data, or introducing other complications.)
  • Capture what does and doesn't work well about your current SCM configuration. Is your branching strategy a mess? The migration project is a good time to fix that. Have you developed a set of in-house tools to support your users? Those may have to be ported to work with Perforce.
  • What are the key schedule milestones to consider? Is there a big release coming up soon that can't be disrupted?
  • How long will the legacy SCM system be available? Should licenses for the legacy system be renewed? If so, for how long?
  • Are your users comfortable with the switch? Do they need training? Are your administrators and power-users aware of Perforce best practices?
  • Identify how much data you need to bring over. (More on this subject a little later.)
  • What tools and automation interact with your existing SCM system? For example, do you use defect tracking integration?
  • When will each team of users cut over to Perforce? Will all users transition at once, "Grand Opening" style? Or will you plan a phased approach, with different teams moving at different times?
  • How will you measure the success of the migration effort? (Possibilities include verification of imported data, reproducibility of important builds, and a measure of impact on productivity.)

Again, Perforce Support and Consulting can help you in this planning effort.

Data Migration

There are three possible migration strategies, listed below. From top to bottom, the strategies give you a more complete imported history in Perforce, at the cost of time and complexity.

  • Migrate nothing. Leave the old system available as a read-only archive, and start from scratch with Perforce.
  • Use the Baseline and Branch Import (BBI) approach. This approach identifies and imports selected key snapshots of the data, and establishes the basic branching relationship between them. For instance, you might choose to import a 1.0 release, a 1.1 patch, and the current main and development codelines. The branching history would be recreated in Perforce; for instance, the branching history would indicate that the development codeline was branched from main. The BBI strategy is easy to automate (our Consulting team has a set of scripts available), and is independent of the legacy SCM system.
  • Import as much as possible. Sometimes called a Detailed History Import (DHI), this approach attempts to make the history of your data in Perforce appear as if you were using Perforce all along. The DHI strategy requires a tool for the legacy SCM system. Tools are available for a variety of systems, including ClearCase, Subversion, and Visual Source Safe. The ClearCase tool is a new gem that we're just unveiling, so stay tuned for more information on that one.

Once you've decided on a migration strategy, you can start nailing down a more detailed schedule, with better level of effort estimates. Phased or incremental migrations are possible, but the complexity varies depending on the migration strategy and how the work will be split into phases.

Putting It All Together

Now that you've done some planning and selected a migration strategy, be sure to test the migration, preferably in an environment that closely resembles your production environment. After a test run, validate the results thoroughly. If all goes well, you can set a time for the actual migration, allowing plenty of time for validating the results again.

Once you've planned for and executed your move to Perforce, be sure to monitor the situation actively. After three or six months, how are your users doing? Is your deployment architecture working as planned? Are there upgraded versions of Perforce server and client software available?

Again, be sure to contact us if you need help in this important early phase of usage. We want you to be successful!