Like all web projects, when the site goes live you will require an ongoing support and development. We normally setup a BETA site to show our clients what it would look like so they can sign it off. With very large or highly programmed sites does anyone have a good way to deal with development and live site deployments
An (Dutch abbr.) OTAP environment (Development Testing Acceptation Production) should do the trick. Development and Testing is inhouse, acceptation and production are two different environments that are both maintained by the server administrators. Every release first have to be released on Acceptation, where both the customer and development can accept or reject the release. After an accept, exactly the same release will be released to production.
-edit: Try to sync the production data to acceptation before every release, to ensure maximum compatibility-
In online/public BETA releases, I think of the google services as a good example.
If you have a good finance way, you can host your BETA environments and the final one in different machines/servers/services. Later in time you just need to forward the requests to the servers you want on the current application state.
If you only have one machine or little resources, I think the best way is always to decouple the application as much as you can, in a way that you can update some module without crashing the application (without losing sessions, transaction/action flows).
.
Other thing you need to keep in mind is if this web site will be used by world clients (require registration) and some kind of DATA production, in this case I think the best way is always to share the same data storage (database) in the BETA and Final Release.
Script as much as possible. There will inevitably be differences in configuration etc, and it is vital that do your best to remove the chances of human error. Good tools include Capistrano, Fabric, and Ant (if you're on windows, you might also consider NAnt or MSBuild).
I like having a pre-staging (shared dev) environment, which is pushed to by a similar script activated anytime there's a post-commit hook in the Version Control System.