Will visitors know I've gone from an SSL site to a non-SSL site for HTTP?

Http links and https links are distinct URLs, so bookmarks will break, and suggested URLs in the browser history will break. You're probably serving out an error page or refusing connections on the https port, so those cases won't be pretty. But other than that, it'll be up to the user to notice the absence of whichever clues the browser affords them.

After the switch, users going to http://www.mysite.com won't get a warning about the SSL certificate. However, if users have bookmarked https://www.mysite.com they'll get an error unless your server redirects them to the non-SSL http://www.mysite.com URL. You should make sure that redirect is set up. Re: your problem yesterday, people who got security warnings were trying to use SSL, whether they knew it or not. Annoyingly, many browsers now hide the "http(s)://" portion of the URL in the location bar, so it's not always obvious when you're requesting an SSL URL. Your (old) server may have a redirect rule in place that sends users who have requested http://www.mysite.com to the SSL-enabled https://www.mysite.com - this is pretty standard practice for sites that use SSL. For your new site, just make sure that you have a redirect rule in place to catch all https requests and send them to the equivalent http URL, and your users won't see any errors.

Browsers don't default to HTTPS, so that shouldn't be an issue. However, if someone has HTTPS URLs of your site in their browser history, I've noticed that Firefox will autocomplete to HTTPS if they type in all or part of your domain in the location bar. So that could be a problem (but new visitors will be fine).

@sriracha: "For your new site, just make sure that you have a redirect rule in place to catch all https requests and send them to the equivalent http URL, and your users won't see any errors." -- unfortunately, you won't be able to set up such a rule unless the new server is accepting SSL requests and presenting a valid certificate (in which case you might as well serve the site over HTTPS).

"Annoyingly, many browsers now hide the "http(s)://" portion of the URL in the location bar, so it's not always obvious when you're requesting an SSL URL." While a lot of browsers hide http://, they'll all show https:// (as far as I know).

2nding the idea to check if there are images or something like that with https URLs that could have caused the error Fred mentions despite the URL in his browser's address bar being http.

As mentioned above, this will break any bookmarks that go to the old https URL. Check your web logs or analytics software to see how many people access the site through https. If it's an even marginally significant number, I would recommend installing the certificate from the old server on the new one, and redirecting users who access the site through https to the http server instead. If you can't get the old certificate, then purchase a new one—it's a relatively painless process, and inexpensive compared to potentially losing those users who had bookmarked the site as https.

You could test it out first. Change your network's internal DNS or your computer's hosts file to point to the new site.

First, thank you all, very helpful. None of my browsers (IE10, Firefox 16, Google Chrome 23) appear to hide "https://": if I go to https://www.amazon.co.uk then I see the https:// in the address bar for all three browsers, as floomp says. If I go to https://www.metafilter.com then I end up at http://www.metafilter.com, but I'm inferring from sriracha and richb that this is because MetaFilter has a valid SSL certificate that it uses to enable communication on the HTTPS address, the communication being "go and use the HTTP address, thanks!". (1) I won't be able to do this for my site unless I similarly provide a valid SSL certificate for the new site so it can do the redirect. So as aparrish observes I should check the server logs to see who this affects and make a call on sorting SSL for the new server. I'll test with Nonsteroidal's suggestion too, thanks. Thanks again to all, mentioned or not. If anything I've written above is wrong, or anyone else has any comments, I'll check back in tomorrow. (1) (Same for http://www.amazon.com. Slight oddness with https://www.metafilter.com and Firefox, where this does NOT work - I stay at https://www.metafilter.com)