What should I consider in planning a migration to Subversion?

First, you need to perform a needs analysis to evaluate the cost vs. benefit for performing the migration. Second, you need to execute an environment assessment to determine what limitations there will be on any migration given the differences between your legacy version control tool and Subversion. Third, you need to establish a new configuration management plan that starts with identifying your true business needs and then looks to best implement them given Subversion's functionality. Finally, you will need to educate the users on Subversion, your modified processes, and on the migration process itself.

• Why wouldn't I want to migrate my whole repository?
  You may have accumulated a lot of junk that you don't use and don't want, and it is stored in your legacy repository. In addition, very few projects will find sufficient value in being able to access the historical data from the new repository to offset the costs (both monetary and time) of the migration. Most projects are better served taking a very limited set of revisions (snapshots) into Subversion, but retaining some ability to access the historical data (think archive) in a slimmed-down architecture for that product.