you can avoid a lot of problems by using a subdomain for the secure content.
create a set of rewriterules that will externally redirect requests for the old urls to the new urls.
make sure you canonicalize your urls so you are only serving secure content with the https: scheme and only non-secure content with the http: scheme.
be sure to use fully qualified urls or relative to the domain root for external files so they have the same protocol as the page.

[edited by: phranque at 2:16 pm (utc) on Feb. 4, 2010]

we also use relative links within the site, and not the full path, in the code. helps a lot.

All of the below is rendered incorrect if you are using a single directory for secure content. Most developers don't.

There is often confusion about relative links. These are both relative:

../../../images/some-image.jpg
/images/some-image.jpg

The first is relative to the current directory, the second is relative to the domain root. If you always use the second, it doesn't matter how deep in your directory structure a page is, it will always find /images/some-image.jpg.

So this is the first step in dealing with HTTPS/non-HTTPS, set all your links, images, etc. relative to the domain root, and they will be fine. This also makes moving files to and from the SSL pages very easy, no special treatment required.

The second thing to take note of is external objects you wouldn't suspect. Two examples are to be sure to use the secure version of the Analytics urchin, and to take it off when moved to non secure areas (or, use the if/else code,) and if you have any Flash, the URL to the download plugin page needs to be the secure version for SSL, non secure for non SSL.

Last, you can always add this to secure scripts to nix old links or non-secure access:

if (! ($_SERVER['HTTPS']==on)) {
header("location:https://example.com/"this-script.php");
}

Invert that for non HTTPS pages.