A few thoughts...
First assess the quality and readiness of your team and its tools; most of the points in "The Joel Test apply.
The work you need to do will depend entirely in the quality and level of documentation of the codebase. The authors may have made your life hard or easy. You may over time need to make changes to the code simply to make adaptation more efficient where the author has specialised what you need to be generalised.
Ensure the build process is reliable and coherent and ideally "one-click". Write scripts and makefiles if necessary.
If not already done, work through and document all the known configuration points; i.e. all the macros, configuration files, constants, compiler options etc. that are likely to be needed to adapt the code to different targets. That way, when you adapt to a target, you have a check-list of areas than may need changing for each port, and can predetermine the workload an provide accurate schedules. Of course it make take one or two ports before all the config points are discovered and documented, and schedules are accurate.
If the documentation is incomplete and you have the budget, deploy a tool such as Understand to help navigate and visualise the code. Free alternatives include Doxygen, and your existing IDE or UML tool may have useful reverse engineering and code navigation tools.
Before you do anything else, of course your code must be under some sort of revision control and configuration management system. Don't change a line without one!
A test methodology and plan is probably necessary, either tool supported or manual so that all ports are tested to the same level, and so that regression testing (testing that fixed bugs remain fixed) is applied.
If you really want to get slick and efficient, deploy a continuous integration system CruiseControl, so that every change is built and verified automatically.
You may consider deploying some of your team not on the actual code adaptation, but rather developing and improving the code adaptation process.