It depends on several factors. What is your staff using now? Is it Windows or Unix? If it is Unix, your learning curve will be lower than if it were Windows, since Linux is similar to Unix. There are classes that are designed for Unix administrators learning Linux that will focus on what Unix admins will need to know to administrate Linux systems. Essentially, Windows people will be starting from scratch. Either way, I would send them off-site to training classes because I'm not particularly fond of on-site training as your staff will be running in and out from training to fixing production problems.
The type of training will hinge on which Linux variant you will be choosing. Though the actual Linux kernel may be the same, the interface and management utilities will be different. Some training centers focus more on Red Hat than SUSE and vice versa, so you will want to make sure you are being trained on the same Linux you will be using. Make sure the version is the same, as well, due to substantial variations between versions. For example, there are many differences in how to do Logical Volume Manager (LVM) related tasks with RHEL3 and RHEL4. If your application does not support RHEL4, why take a training class in RHEL4?
Regarding a porting schedule, again this revolves around the type of applications you are porting, what you are porting from, how many environments you will be porting, etc. As a general rule, I'm a big believer in doing a Proof of Concept (POC) prior to implementing an all-out migration. If a vendor is selling you migration servers and hardware, let them pick up the tab for a POC. If not, do it on the cheap.
This was first published in September 2006