There are a number of ways I've seen this sort of thing handled:
Share the work out
The most obvious thing to do is share the work out among existing resource (assuming this is possible). How to ensure the developers hit the ground running is almost an answer in itself but ultimately, it boils down to properly recording requirements, designs and progress. Things like pair programming can also assist greatly here.
Push the deadline back or attempt to claw back time
Check with the customer to see if the deadline can be extended. Alternatively, it might be possible to gain addition development time by working evenings, weekends and holidays.
Drop other tasks
Are there any other non-critical tasks that can be temporarily dropped to make room?
Is there work planned after the development that can be brought forward such as documentation, test scripts and configuration?
Admit it could be late
Speak to the customer early. It might be possible to deliver in part - or at the very least, you could get a decent steer on the relative priorities of other things.
A possibility - but this itself carries risk. It will take time to get them up to speed and as they're temporary, they could just leave leaving you even worse off.
Check the critical path
If other parties are involved - check that they are still on target. There is little point in moving heaven and earth to get something finished if say, the test team are a month behind on testing things.
Accepting the realities of risk
There is a common phrase in the legal profession that states that hard problems create poor solutions. It can be tempting to try and get everybody to understand everything to cover all eventualities. This however, is a fools errand.
Developers should be spending quality time on their own developments. Consuming an ever increasing amount of time becoming au fait with other developments is a highly questionable activity. A reasonable middle ground might be to have a subject matter expert and a deputy.