What you are proposing sounds like an A/B swap. (Similar question)
There is an IIS addin tool from Microsoft called Web Deploy. It will automate most of the physical motions of deploying updated code into IIS but your requirement of seamless migration is the sticky point because you have long-running file-transactions. The best way to handle this is to get a load balancer, run with two production instances of your site at the same time and have a third instance for staging updates.
(BTW, Azure is doing something like this with "Cloud Services" -- there's a "Swap" command to do this exact thing.)
Going back to your particular setup, consider this configuration:
One IIS machine, two Web Sites. Web Site A and Web Site B. They do not point to the same files. They have their own folders. Web Site A is online and serving users in production, while Web Site B is offline. When you are ready to update, you update Web Site B, then swap On/Off Web Site A. Now B is online and A is offline. This is an A/B rotation. Later, when you do your next update, you update A, then swap On/Off with B. Now A is online and B is offline.
That exact moment, when you swap, there is the possibility of losing traffic -- (and you will probably kill those file transfers) but if your app is low volume, maybe no one will notice (you decide). However, if this is mission critical, high volume, site -- get a load balancer and use it as others have described.
What WebDeploy won't do, (as far as I know) is swap On/Off site A and site B. For that, you'll need to write a script and do it at the command line.
The benefit of the Web Deploy + scripts is that you can eventually automate this and maybe tie it into a continuous deployment system.
The long running file transfers are probably impossible to save with this setup. Another challenge is any in-memory state of your app. If your web app was designed with in-memory data, then you'll lose it when you do the A/B swap. If the programmers are using session, you may be able to turn on the session service. The session data will not be in the same process with the rest of the app and might survive the A/B swap. Talk to your programmers about how the app manages in-memory data. Maybe it doesn't actually have any. Maybe it can be easily recreated once the app reloads -- (e.g. rebuilding a cache from database)
Best Answer
AFAIK, there is no way to get PHP to do that.
What you probably have to do is simply adjust your PHP application to operate similar to how Drupal ond some other PHP apps work. Various configs are placed in a directory structure like so.
Basically the PHP application will look at the FQDN the incoming request intended for, then it will try to load a config for that, and then it will try less-specific locations until it selects the default all-sites config.