There's no magical way to turn a website migration into a 3-step process, but with planning and some clever scripting, you can make things go a lot more smoothly.
First things first, is this a static site we're talking about or a dynamic site? There's a reason why most sites these days are dynamic. It's just impractical to manage and maintain a large site comprised of static pages. So if that's what you're dealing with, then unfortunately things will be a lot tougher. Otherwise, you can probably export the existing site's content into a common format and import it into the new CMS.
However, if you're dealing with a static site, I'd take one of two approaches. The first approach is to write a script that processes the static pages, extracts the contents, and then imports it into the new CMS. The quickest way to do this with bulk data is to extract it into a CSV file, and then when you've extracted all the data, use LOAD DATA INFILE to load all of the data in one go.
However, if the site was poorly kludged together and the pages are just too irregular/non-normal to process with a script (broken markup, different document structure on each page, etc.) then you'll need to do it by hand. In this case, I would just source the mindless data-entry work to someone else. You could even just advise the client to have their secretary do it. Otherwise, you could out source it and bill the client.
Secondly, before you make the migration, map out all of the old URLs to the corresponding pages on the new site. This is a critical planning step that a lot of people overlook, and it costs them a lot of lost traffic as well as years of SEO/SEM investment and PageRank. Pay particular attention to the high traffic/value pages. Which pages have the most backlinks? What are the pages receiving the most organic search traffic? What pages contribute to high conversion rates? Figure all of this out in your planning stage and make the appropriate 301 redirects to your new site structure. You don't want people clicking on an old bookmark and going to a 404 page.
Lastly, if you have an accommodating hosting plan, do not install the new site in the same directory as the existing site. What I like to do is create a new wwwroot folder (e.g. /www/mycompany.com-2.0) for the new site and assign it to a test domain (e.g. test.mycompany.com). Then you can test the new site out on your production server while the old site is still up (unless you're using virtualization to maintain identical hardware & software configurations between your production and test servers, you can't be sure that they'll behave the same). Once you've tested it out there, then simply change your Apache/IIS configurations so that the actual company domain is hosted out of the new directory.
