Hi, I'm Lorri Freedman.  I'll be publishing posts about photography and Photoshop here at CoolTechU. 
You can also see my work at PhotographyByLorri.com.  My first post is how to tweak photos taken in
low light conditions.

Here is an image taken at sunset from a moving van. My husband and I were taking a guided tour on
Zion Mountain in Utah. The cow is blurry and so is the background and foreground. What do you do? 
Well, it would have been ideal for the van driver to stop the van, but since he had no intentions of doing
so I had to think fast. This image was taken at an ISO setting of 200.

I quickly changed the ISO to 800, and I was able to get the cow in focus even though the van was still
moving and the sun was going down quickly. Below is the image.  Now that the cow is in focus, I have
something to work with. It’s time for some Photoshop.

I did a quick spot healing on one spot using the Spot healing brush on the cow’s coat. There was a
piece of dirt that bothered me. I usually do this at the end. So, I’ll save the rest of that for the last part of
this tutorial.

The first thing I do in Photoshop is look at the levels palette. To get to the levels palette, select the
Image menu, then select Adjustments, then Levels. A box will pop up called levels.

Actually, the levels don’t look too bad. I would move the right slider just a hair to the left to meet the
black part of the level. Then click ok.

The next thing I would do is zoom in and get rid of the tag on the cow’s ear. A little cloning should do
the trick.

Here (above) the clone stamp is active. You can tell because it is highlighted with a box around it.

When cloning make sure you keep the clone stamp as close to the area that you want to clone in order
to keep the same colors and texture you want in the area.

Next, I would go into Color Balance, found under the Image menu, Adjustments, Color Balance.

Move the sliders around until you’re happy with the look. Then give the image a small tweak with some
contrast. The contrast is found under Image, Adjustments, Brightness/Contrast. I wouldn’t go
higher then a 4 or 5. If you do, it will give the image an off-look.

Last, but not least, I would crop this image. I think it has too much foreground and a little too much
empty space on the left. The crop tool is found in the toolbar on the left.

Then just click on the checkmark in the toolbar that runs horizontal at the top of the screen:

I save the image and just go over the image to see if there are any imperfections, like little marks or spots
that you wouldn’t want on the finished image. For that I use the Spot Healing Brush, which is located
on the toolbar:

Here is the “before” image:

And here is the finished “after” image:

You can download a PDF version of this article here:
Troubleshooting in Low Light Conditions with Some Photoshop Tweaking.pdf (2.4 MB)

Keep in mind that the step-by-step guides I just posted are not a catch-all, end-all solution for transferring providers.  It's just a bunch of ideas that I wanted to share, so perhaps you can get a better grip on all the steps involved in switching web hosting providers if you have to face this scenario yourself in the future.

Now to continue my saga, which I hope will help you to avoid some of the mistakes I made along the way...

Host # 2

After leaving ASPnix, I signed up with HostingFest, which was another low-priced host recommended to me by a colleague.  Unfortunately, I didn't ask enough questions at the time of the recommendation.  I was in a rush, since e-mail just completely stopped working for days.  If I took the time to ask more details, I would have found out that the recommendation came from a short-term experience.  Apparently, this person switched due to the fact that HostingFest didn't provide all the features he needed for his planned sites.  So, the few times he had to contact their support resulted in a satisfied customer.  I also should have asked a couple of other people whom he had recommended their services to.  Their experiences were pretty negative.  I also should have Googled them to do some backing research.  I would have seen a lot of very negative (as well as some positive) reviews.

The problems I had started a couple of days after I joined.  HF uses the same control panel (Helm -- which is quite popular for its ease of use), and the same mail server software (SmarterMail).  Well, all of a sudden, e-mail just completely stopped working.  At times we couldn't couldn't connect, but most of the time, we'd connect, but would see no e-mail.  I would normally at least see dozens of spam messages come through every few hours, but got absolutely nothing.  I opened several tickets with them, and the communication was even worse than ASPnix.

From what I was seeing, I had a hunch that there was a problem that was unique to SmarterMail, since, coincidentally, both ASPnix and HostingFest were having similar issues at around the same time.  I had noticed that in the prior few weeks, spam volume had increased a LOT, so I had a hunch that SmarterMail was not dealing with this well.  I even posted a detailed ticket explaining my hunch.  No response at all.  It wasn't until two days had past (and some snappy "be patient" responses, with no other explanation, had been sent back to me)  that a general posting in the "News" section of their support site was created.  This looked to be the very first news item EVER created on their support page, and I had a hunch that my comment about that is what prompted them to use it.  The item stated that it looked like SmarterMail was being overrun with large volumes of mail (hmmmmm, spam, I'm sure), and the single server they were using maxed out on the number of e-mails SmarterMail can handle for a single server.  So they were working on getting a new server.

Still, another day past, with no e-mail.  I couldn't wait any longer, so I switched again.  Although their web servers seemed extremely fast, without e-mail, that was basically of little use to me.  I wrote them asking for a full refund, since they didn't live up to their side of the uptime agreement.  I got a quick response back to that, stating that they'll give me a refund "when they have time".  Ok.  I understand.  They're focused on getting additional servers up.  But it again begs the question -- just how many people are working at your company?  My very strong hunch is two.  Again, you get what you pay for.  I can understand that to a point, but don't make crazy service-level promises on your pre-sale site if you know you can't deliver.

Later that day, they e-mailed me saying that they issued me a refund.  It has now been two weeks -- and still no refund on my credit card statement.  Almost time to issue a chargeback.

Host # 3

This was mainly my fault.  In my panicked haste, I signed up with Easy CGI, which started off very well, and the customer service seemed good.  I had researched about a dozen different hosting companies this time, so I thought I made the right choice.  The price was decent at $19.95 per month.  The control panel was a little kludgy, but I didn't expect to need to use it much after the initial setup.  It was when I started adding the second host that I realized my mistake.  Apparently, the reason why customer service was so good was because it was $19.95 per domain!  Ouch.  For some reason, I thought they allowed up to eight domains per account.  When I asked them about this, they didn't understand where I saw that.  I re-checked, and they were correct.  Nowhere did it mention more than one domain.

I must have gotten confused between all the different companies I was researching.  So the lesson here is -- take copious notes when doing comparative shopping.  Oops.

Host # 4

After some prodding by one of the users of one of the sites I was supporting, I tried GoDaddy.  I use GoDaddy for registering my domains, and I always liked them.  I think their site is WAY too loud and obnoxious, with way too much marketing, but the controls are fairly decent, and they seem to have their act together.  And the price was oh-so-right.  In light of their customer support, their pricing is excellent.  I had read some negatives about their customer support, which is why I bypassed them at first.  I also read about another negative, which I'll talk about shortly...

I did hit upon a few road blocks when setting up the sites; mainly with MS Access database support setup.  I actually had to change a site to DSN-less connections, but that was fairly minor.  I also had to change one site's root application to work under ASP.NET 2.0, because that is a site-wide setting.  I'm not crazy about the way I have to structure the folders under a single FTP login, either (and they only support a single FTP account), but even that was not a show stopper.

I must have spoken to customer service on the phone about eight times, totalling over two hours, and not only were they very friendly, helpful, and understandable, it appeared that they're one of the shrinking number of companies truly doing phone support from within the US.  Not that there's anything inherently wrong with outsourcing phone support, but I always feel a layer of mistrust when someone who is clearly not American claims his name is "John".  Please, people, if you're going to outsource your phone support, please allow Partha to be Partha.  Anyway, whenever someone didn't have an answer to my questions, he or she would actually let me know that they weren't sure of the answer, and were going to put me on hold for a few minutes to ask a co-worker.  That's another thing -- they were always quick to answer (the longest wait was about 12 minutes, and the recording told me how long the wait would be), and quick to return after putting me on hold.  They would have been great, except for one, huge issue...

They must have the most restrictive e-mail "blacklist" in the world!  As soon as I switched over, I received an average of maybe two spam messages per day!  And I normally received over 100.  And it appeared that I was getting all the normal e-mail I expected...at first.  Then I found out that my father tried e-mailing me, and I never got it.  He did a few more tests -- nothing.  I then had him e-mail me at my gmail account to make sure it wasn't his service, and I got those ok.  Now I was starting to worry what other e-mails I missed.  I called GoDaddy, and had the first, and only negative customer service experience with them.  I gave them my father's current IP address at their request, and they looked up their blacklist.  Yep.  The entire octet of his address was being blocked, because "someone once sent a bunch of spam from a "nearby" address."  Wha?!?  Ok...what do I need to do to get e-mail from my father? "Well, you can have him get a static IP address, and we can unblock that specific address."  My mouth was hanging open, speechless.  They were telling me to have my father, who knows nothing about IP addresses, and very little else about computers besides surfing the web, e-mailing, and doing a bit of Excel, to get, and PAY FOR a static IP address just so that he can e-mail me and my wife?  Insanity.  I asked to speak to a manager, and asked him if he were in my position, wouldn't he be upset?  He admitted he would, but stated that GoDaddy needs to save people from themselves (not in exactly those words, but some to that effect).  And that it was worth blocking some innocent e-mail to prevent spam from getting onto their servers.  After I claimed this was like throwing the baby out with the bathwater, he said he'd see what he could do about changing company policy (yeah, right), and said I should e-mail their "suggestion box", because they seriously consider all suggestions.  He even told me that one suggestion was implemented the next day.  Uh-huh.  Well, I informed him that I did a search on the Web, and a lot of other people have had similar experiences with their blacklist, going back well over a year ago, so if GoDaddy was serious about considering a policy change, I didn't believe it would happen.

Bye-bye GoDaddy.

Host # 5

Hello WebHost4Life.  This one burned me up more than all the others, because of their sneaky marketing techniques.  At this point, I was convinced that there would be no budget solution that I could depend upon.  So since I was mainly hosting ASP.NET sites, I based my search on strong support for IIS, SQL Server 2005, etc., with at least a bunch of positive reviews (expecting many negative ones, also).  With support for unlimited domains under a single decent price, WebHost4Life seemed like the ticket.  They should get a ticket!

I started by transferring a single domain, which worked out ok.  So I began with the next domain.  When it came time to setup e-mail accounts for this second domain, I was surprised with a message that if I wanted e-mail addresses under this second domain, I would have to pay an additional $10 per year.  Since I had six additional domains, that meant another $60.  But that wasn't the point.  In no place on their pre-sale pages did it make any mention at all of this additional cost.  So I started an online support chat with one of their "professionals" (more on why I quoted that word, later).  Since you can get a transcript of your online support session e-mailed to you, I'm tempted to post it here in its entirety, but I'm going to give them a bit of a break and pass.  Besides, I'm not totally sure about the legality of doing so.  Basically, the conversation went something like this...

Me: I'm confused.  I added a second domain, but I don't see how to create e-mail addresses for this second domain.

WH4L: For your added domain to have email account, there is a charge of $10.

Me: Are you serious?  There was nothing that mentioned that when I signed up.  If I switch my site, I'll lose all my e-mail accounts, and I have 7 sites. I see the DNS settings point to the domain for e-mail also. Does that mean I lose all my e-mail if I don't pay an extra $60?

WH4L: Hold on a minute...

Me: Look at this page on your site: http://www.webhost4life.com/hosting.asp. There is nothing about an additional charge -- it says "unlimit domains" and up to 100 e-mail addressed for the plan I signed up for (advanced).  I can't understand why I lose e-mail capability when switching my other domains.

WH4L: For added accounts having email, you need to pay $10.

Me: Where does it say that? If you are grabbing my other domains' MX records, I lose e-mail unless I pay what is effectively ransom.

WH4L: Yes, you need to pay $60 or can lose all your mail.

Me (my mouth, again, hanging down in shock): Where does it say that on http://www.webhost4life.com/hosting.asp? This is equivalent to holding my e-mail MX records hostage.

WH4L: Hold on...its not on the site, but you should find it on your control panel.

Me: But I only get to see that after I join and pay $$$. It's a hidden cost, and unethical.

WH4L: It's not a hidden cost, we do let the customere know before signup.

Me: Show me where, please.

WH4L: Login to your control panel >> domains >> domain name.

Me (in shock): Like I said, that is AFTER I join and pay. Look what you are telling me...to log into my account to see the hidden cost...that implies that I need to pay BEFORE I can login to my account and see that. Please show me where someone can read that on your public website before someone signs up, and then I'll know I made a mistake. If there is no place on your site where it states the extra $10 per domain charge for e-mail, then it is a hidden, unethical practice. If there is a place, then I'll admit my mistake and decide what to do next with my account.

WH4L: I dont think i can help you in this. I am just a level 1 tech. I don't have access to the servers or accounts. (And this is one of their "professionals"?)  I can just show you the things where it is.

Me: You have access to the public website, so show me where it is there. You don't need to be any level to show me that.

WH4L: As I told you, it is not on the site...

Me: Right -- so it is unethical and illegal and misleading... Can I please have the direct contact phone number of your manager?

WH4L: Please hold on a moment, I will check for it...You can call on the following number and ask for manager...(Tel) 888.306.3780, (Tel) 323.980.8281.

Me: That is the main support number where you are put on hold for an hour...I'm looking for the direct line to your manager...

Me (five minutes later): Hello?

WH4L: I don't have that. You can place a ticket and leave your number on that. Our manager will get back to you.

Me (getting angry): So, if you wanted to call your own boss, you would have to go through your general number? What's your name?

WH4L: It's (his name).

Me: What is your manager's name?

WH4L: Let me see if any manager is available at this moment. Please hold on a moment...

Me: Thank you, but I really want to speak to them on the phone.  It is very difficult to communicate through instant messaging.

WH4L: Yes, i can understand that...will it be fine if I provide you with his direct email? ceo@webhost4life.com

Me: It's not much better than IM, but if you have no choice and aren't allowed to give out his phone number, that will have to do.

WH4L: You can mail our manager at ceo@webhost4life.com.

Me: Ok, thank you...goodbye.

WH4L: Bye.

Well, I sent a detailed e-mail to the "CEO", but needless to say, I received no reply.

In my final post of this story, I'll talk about who I finally went with.

My Web Hosting Nightmares, Part 1 - Background
My Web Hosting Nightmares, Part 2 - Preparing for the Transfer
My Web Hosting Nightmares, Part 3 - Starting With a New Host 
My Web Hosting Nightmares, Part 4 - Completing the Transfer

Ok, you've backed everything up from your old host, set up an initial site on your new host, and are ready to do the transfer of the first domain.

1. Note Old IP Address: I ping both the base URL (ie: CoolTechU.com) and the mail server URL (ie: mail.CoolTechU.com) and note the current IP address each ping resolves to.  You'll monitor your change based on these addresses in step 3, below.
2. Transfer the DNS: This is where I hold my breath.  This is the point where, if things don't work out quite right, e-mails can drop out of site, first-time visitors to your site could end up believing your site is gone forever and never return, and you can regret your decision to switch in the first place.  But usually it isn't that bad.  From your new host, note the DNS (domain name server) URLs and IP addresses.  Normally the host will provide you with two -- a primary DNS server and a backup, secondary server.  Usually, the URL (not the IP address) is all you need.  Go to the manager of your domain (mine is GoDaddy.com) and change the DNSs currently assigned.  Once you save your changes, the process is underway.  In effect, the change propagation begins immediately, making its way throughout the entire Internet.  You are normally warned that this could take from 24 to 48 hours.  Although this was true a few years ago, it seems to be a leftover CYA statement.  I've seen the change happen within 10 minutes at times (I check from a few different DNS servers to confirm), and within a few hours at most.  It's a lot faster than it used to be.
3. Monitor the Change: I normally do this in a few steps.  First, I ping both the base URL and the mail server URL, comparing the IP address to what I noted in step 1, above.  I try to do this from machines from at least three different networks.  Not everyone will have this luxury.  I have both DSL and Cable services at home, so I tested on machines hooked up to each of those networks.  Then I VPN into work, and do the same ping test from my machine there.  Once I see the base URL resolving to the new IP address, I post a "Temporarily Down" default page to the website of the old host, if I hadn't yet done that.  At this point, I need to FTP into the old host using the old IP address, since the site now effectively points to the new host.
4. Test the Website:  At this point, I'm ready to test the site from the new host, but I may still need to change back any temporary website configuration settings I made when testing the site after uploading using the temporary URL. When those changes are done, I then browse to the site using the normal URL.  The "Temporarily Down" page should not show up -- the page should open correctly.  Then I know for sure that the base URL change worked fine from that network.  Then I try it from the other two machines.  Your mileage may vary -- if you aren't able to test this from multiple networks, play it safe, and wait a few hours before doing the e-mail transfer test.
5. Test the Mail Server: If the ping tests in step 3, above, did not yet show the mail server change, I re-test that.  Once the change shows up on all three networks (again, if you only have access to one network, wait a few hours before doing this next step), I send myself a test e-mail from my old host's webmail application.  If I receive the e-mail on my new host, it looks like the mail server transfer is complete.  Then I change my mail client's settings, if necessary.  You may not need to change anything here, if the pop and smtp accounts are the same (they are usually mail.MyDomain.com for both).  Often, I'll use a different password for my e-mail account at the new host to help augment this next test -- this is because when I do the next tests, if I get an authentication error, I know right away that I'm still hitting the old server.  Then, I CLOSE and re-open my e-mail client.  I use Outlook, and it appears that Outlook cache's the old IP address that the URL resolves to, so it may still attempt to hit the old host's server.Other clients may do the same thing, but I'm not sure which.  Neglecting to give this instruction to the users of my servers is the cause of more questions and problems than any single other thing after a transfer.  Then I send myself a test e-mail from two different accounts.  If I receive those fine, I reply to each of these messages.  If that works fine, then I know this test is complete.
6. Setup Other Services: Now that the two main pieces of the domain are working, if you have any other services that you need to activate (such as SharePoint), then do that.  My sites are pretty basic right now, so I'm normally done with this initial domain at this point.
7. Setup Aliases or Domain Pointers: If you have multiple URLs pointing to the same site (ie: I have MarkFreedman.net and MarkFreedman.org pointing to MarkFreedman.com), set this up next.  Each host has a different way of doing this.  Some simply allow you to create an "alias" to an URL, where you would simply enter the URL to point to it.  Other hosts will require you to add a second domain with this URL, then on the control panel section for maintaining a website, allow you to "point" that second domain to the website setup under the first domain.
8. Test Alias Access: Now that the aliases are setup, I test the site and e-mail accounts, making sure all results are equivalent to the main domain.
9. Setup More E-Mail Forwards: I got burned with one of the hosts because of the following: Normally, when you have multiple alias domains pointing to your main domain, e-mails will also get directed to the main domain.  In other words, for e-mails going to my MarkFreedman.com account, if anyone sent anything to MarkFreedman.net, it would still get to the .com mailbox.  But this did not work for my current host.  I had to add e-mail forward accounts at the .net domain to point to my .com addresses.  This is a very annoying pain, because for one of my domains, I had five times as many e-mail addresses to create.  At least forwards are simpler.  They don't need passwords, etc.
10. Notify Users of the Domain: At this point I'll put together individual peronalized e-mails to the alternative address of each person who has an account at this domain, telling them about the switch, explaining the reasons for the switch, giving them their temporary e-mail passwords (and FTP account info, if necessary), remind them to change their password through the new webmail system, point them to instructions on how to use the new webmail client, and give them instructions on how to access their old webmail account in order to clean up any messages still sitting there.  I usually give them a deadline, because I need to cancel the old account as soon as possible.  If they don't meet that deadline, that's when I go into their old accounts myself, and forward the messages to their new accounts.  I warn them that I need to do this, before I actually do.
11. Delete Content from Old Host: Even though I'm closing the old account, and deleting the old websites / domains through the control panel, I first take the extra, precautionary step of deleting all the files via FTP first.  That gives me a sense of control, even though they can easily have a backup already.  Of course, if you have any real sensitive data, it should always be encrypted on the site or the FTP to begin with.
12. Delete E-Mail Accounts from Old Host: Similarly, I manually delete all the e-mail accounts from the old host before deleting the domain.  Do whatever you feel comfortable with.  I'm always extra cautious, and manually delete the accounts (after everyone had a chance to check and forward any remaining e-mail, of course).
13. Delete Old Website and/or Domain: The control panel should have an option for deleting a domain.  If it also has a separate website option, then delete the website first, then delete the main domain, and each related "alias" domain.
14. Transfer Remaining Domains: Well, one domain down, six (for me) to go.  When you feel comfortable that the first transfer is working fine, lather, rinse, repeat.  Isn't this fun???

In my next post, I'll continue my hosting nightmare story.  I was with six separate hosting companies in two weeks.  Yep.  Fun.

My Web Hosting Nightmares, Part 1 - Background
My Web Hosting Nightmares, Part 2 - Preparing for the Transfer
My Web Hosting Nightmares, Part 3 - Starting With a New Host 
My Web Hosting Nightmares, Part 5 - My Continuing Story 

Now that you created your lists, did your backups, signed up with a new host, and were activated with that new host, you are ready to begin the transfer:

1. Create Domains: Each host is a little different, but all of them have an equivalent step to "creating a domain".  Start by establishing the domain for your least impacted site that at least crosses over some significant common features (website, e-mail, FTP).  In this way, you can test the effectiveness of a single transfer before committing to the rest.  This "one-at-a-time" approach helped me a couple of times over the past couple of weeks.
2. Create Webs: Again, each host is a little different in how they let you set this up.  Some combine the "create domain" and "create web" step into one, and then allow you to specify "alias" domains to point to the original one you set up the web for.  Others keep these as separate steps, and allow you to set up and specify a domain as a "pointer" to another domain.  Again, try to review the host's control panel tool before starting the transfer process so that you are comfortable with the workflow.
3. Create FTP Account(s): You'll need to set up at least one FTP account in order to start uploading your website content.  Some hosts provide you with an initial account to use, but for others, you'll have to set one up yourself.
4. Find or Establish a Temporary URL: Here's another Catch-22.  You're ready to upload your content, but you're still hosting your site at the old host, and are not ready to transfer the domain.  Some hosts will provide you with a temporary URL, which may look something like this: MyDomain.com.Myhost.net.  Others require you to click a button to generate a temporary URL for the site.  Others may supply you with only the IP address of the shared host (most likely, on a budget plan, you'll be on a "shared host" plan, with several websites from several of their customers living on a single IP address).  Your login account would dictate the folder you'll be placed into upon FTP connection.
5. Connect Via FTP: Different hosts will provide you with a different folder structure to use.  Some will give you a root folder in which you need to create a subfolder for each site.  Others will require that you place your initial website into the root folder, and require you to create subfolders for your additional sites (making it seem like those other sites are second class citizens).  Others will provide you a different FTP account to access each site.  Personally, I prefer the first option, because it allows the convenience of maintaining all sites from a single login.  You could usually create separate FTP accounts on your own, if you want other individuals maintaining sites they're responsible for, without having access to all the sites.
6. Upload Site Content Via FTP: Most hosts provide a web-based control panel alternative to FTP, but those are usually very painful options that you should only use when in a bind, since you can usually only upload a single file at a time.  Others provide a web-based FTP client.  But with several free FTP tools available for download, I strongly recommend this option.  As you upload your content, save any database files for last.
7. Setup Databases: Depending upon the host, you may need to "initialize" or "setup" database areas explicitly (look for options like MS Access, SQL Server, MySQL, ODBC, etc.) before uploading your database files.  Take care when doing this to understand the implications.  One host I used only supported FileDSN instead of SystemDSN, requiring me to change code before uploading.  I ended up resorting to non-DSN coding changes in this case, because it never quite worked through DSN.  Yeah, I'm using Access for one of my sites.  I know, I know.  I plan on rewriting that site soon, anyway.
8. Set Web Server Settings: I'm only familiar with IIS right now, so I'll only mention that here.  Most control panels allow you access to the most commonly used IIS settings.  Anything not available via the control panel will require contacting technical support.  Start by setting up any virtual directories.  Then specify any "applications".  Then, specify the technology you will be running the site under.  These days, under IIS, you'll always have an option for ASP, you'll usually have options for PHP and CGI, and you'll usually have an option for ASP.NET 1.1 or 2.0.  Beware that some hosts only allow 1.1 OR 2.0 for a website, where others allow you to set this independently for each application.  On one of my hosts, I had to convert to ThinkJot for my blog instead of dasBlog, because the host did not allow for a mix of 1.1 and 2.0, and under 2.0, they did not allow for full trust rights.  ThinkJot is a converted version of dasBlog, equivalent in every way to dasBlog 1.8x except for the fact that it will run fine under medium trust.  A complete rewrite of ThinkJot in ASP.NET 2.0 is currently in alpha.  Then set the correct access rights to any folders for the site, if they stray from the default (usually when you need write rights).  Again, each host gives you different levels of control here.  In my current host, I had to give write rights to the entire site, just to be able to write content and log files under a couple of subfolders.  Finally, set any default page names you'd be using on the site.
9. Test the Website: Now is the first moment of truth.  Try hitting the site via the temporary URL or IP address.  Keep in mind that some sites may contain configuration settings that point to a known "home page" URL for certain functionality.  In these cases, temporarily change the config file to point to the temporary URL or IP address, or just trust that if the home page works, the other functions will work after converting the domain.  It depends upon your comfort level at this point.
10. Setup E-Mail Accounts: Now that the site seems to be working, you'll need to get the e-mail accounts setup to prepare for the cutover.  This can be a little tricky.  Setting up the accounts (lists, groups, forwards, etc.) is pretty straightforward (although some hosts require you to also specify a maximum mailbox size for each account, divided from your maximum allocation.  Still no big deal, and easy to change after the fact.  The tricky part is making sure that any leftover e-mail sitting at the old host can be accessed by everyone before cancelling the old host.  Usually, the old host's webmail can be accessed via a generic URL (only your e-mail account login should be required for accessing the old mailboxes).  I've had occasions where I was forced to go into someone else's mailbox and manually forward the leftover messages to their alternative address, in order to cancel the old host quickly.  I make it clear that I have access to other people's accounts for purposes such as this, only.

In my next post, I'll go through the steps for completing the transfer, beginning with the DNS change, and then discuss tying up any loose ends.

My Web Hosting Nightmares, Part 1 - Background
My Web Hosting Nightmares, Part 2 - Preparing for the Transfer
My Web Hosting Nightmares, Part 4 - Completing the Transfer
My Web Hosting Nightmares, Part 5 - My Continuing Story 

Transferring seven domains is an exercise in juggling, timing, and patience, not to mention frustration.  Frustration of learning a new control panel UI.  Frustration of knowing that some e-mail may fall into the great bit-bucket in the sky.  Frustration of e-mailing everone's alternate address to give instructions of how to access the new mail server, new webmail, new temporary passwords, new FTP accounts, etc.  The process can easily take a full day of coordination, especially if you hadn't done it in a while.  Because I've done it so many times these past two weeks (you'll read why), here's a list that you may find helpful if you find yourself in the same situation.  There may be tools out there to automate some of this, but remember -- this is for hosting on a budget (one of the reasons you may need to resort to this more than once), and you may not want to spend the money for utilities you may only use once or twice:

1. Try Demos: Try out the sample control panel on the hosts' sites.  If you can't play around with a sample before joining, don't use them as a hosting company -- even if you already are familiar with the tools.  Any company who doesn't give someone an opportunity to experiment with their tools before joining them is festering with many more problems that you'll discover after you've already committed to them.  Make sure you can play around with their web hosting control panel and their webmail client.
2. Select a Host: This is hard, and will need a post of its own one day.  I looked at about a dozen before making my first (mistaken) selection.  Just keep in mind one thing -- all these "web host review" sites should be taken with a grain of salt.  I have a hunch that several of them are plants.  You'll also find both good and bad reviews for about every "budget" hosting company.  It's the nature of the beast.  If possible, get a personal recommendation.  I wish I took that advice two weeks ago.  On a budget, it is quite rare to find a host with telephone support.  Some provide real-time online help, but too often that is just pre-sale, or it just seems too "robotic".  Most likely, you'll only get a first-line technician through this method.  It's even rarer to get a direct IM account for a support person (which ASPnix did provide for me).  E-mail support is the most you can really expect in a budget plan.  Normally, you'll only get a guarantee of 24 hour turnover, but you'll want urgent requests to be answered in an hour or two.  This is something you can only really test out after you sign up.  Never go by the pre-sale response time.  That will often be a lot quicker in order to obtain the sale.  GoDaddy was one of the few hosts I found that actually had very good phone support (which they encourage you to use).  But they have other issues, which I'll discuss in a later post.
3. Sign Up: Pick a plan, and sign up for it.  If you don't know exactly what you need capacity-wise, you can usually upgrade (or downgrade) later.  But if you're facing a crunch, like I did (e-mail was down for days), you may not have any choice but to make a quick decision.  Even if you are parking temporarily until you can catch your breath -- sort of like renting a house when selling your old house while buying a new house.  Be aware that some hosts set your account up immediately, while others can take up to 24 hours.
4. List of Old IP Addresses: Make note of the IP address(es) of your current sites -- for both the web address and the e-mail server address.  You'll need this to figure out early on when the domain name server change actually occurs.  More on this, later.
5. List of Domains: Make a list of all your hosted domains; whether they're actual domains or just parked (aliased) domains pointing to another of your domains.
6. List of E-Mail Accounts: For each domain, make a list of all the e-mail accounts hosted at each domain.  That includes all actual accounts, all forwarded accounts (and the addresses they're forwarded to), all groups (addresses that forward e-mails to multiple other accounts), and settings for each address.  You will not have access to passwords, so after you switch, you will have to assign temporary passwords to each account.
7. List of Secondary E-Mail Accounts: Get secondary e-mail addresses from each person who has one of the above addresses.  This will be the only way you'll be able to send them details about the new account.  Yep -- Catch-22.
8. List of FTP Accounts: For each domain, make a list of each FTP account and the folder rights each of these accounts have.  Yep...you've only begun the process...
9. List of Websites: For each domain, make a list of each website, sub-web, virtual directory, technology required (.NET 1.1 / .NET 2.0 / PHP / CGI, etc), folder rights, database info (ODBC, connection strings, etc.), and any other server settings you may need to propogate to the new host.
10. Lists of Everything Else: I covered the most common options, but you may use other tools, such as mailing lists, stats, SharePoint sites, etc.  Make a detailed list of everything.
11. Stop Updateable Sites: If there are any sites that you want to retain history for, such as sites that log visits, create accounts, take orders, etc., replace the home page with a "temporary down" page explaining the situation.  Make it clear that you should be back up within 24 hours, and if necessary (especially for business sites), an alternate way to contact you in the meantime.  As I mentioned in my earlier post, you want to communicate very clearly with your customers.  Be honest with them about the situation.  Do NOT keep them in the dark.
12. Backup Sites: If you haven't done so lately, make a complete current, folder by folder backup of all of your sites.  That includes any folders containing log files you may want to keep (such as for dasBlog and other similar sites), database files (that may be in a separate db folder off the root of each domain, etc.).
13. Backup Backups: If the copy of your sites that you just downloaded to your hard drive is your only copy, then you know what you need to do next ;-). Backup, backup, backup.  Use whatever method you are comfortable with, and make TWO backups.  My rule of thumb is to always make at least two backups.  If you make only one backup, Murphy's law will ensure that it will always be bad.  Two backups always seem to result in two good backups.  Who knows why?  But it always seems to be true.  One of life's mysteries.

In my next post, I'll continue the list from the point of setting up your sites at the new host.

My Web Hosting Nightmares, Part 1 - Background
My Web Hosting Nightmares, Part 3 - Starting With a New Host
My Web Hosting Nightmares, Part 4 - Completing the Transfer
My Web Hosting Nightmares, Part 5 - My Continuing Story 

I've been hosting seven websites on a budget for several years, now, including this one.  I started out hosting these sites from my home -- I had a couple of servers and dedicated IP addresses over SDSL funded by my former consulting company, of which I was one of the owners.  Virtually total control (total control over the boxes; not as much control over the line).  But a headache.

Being responsible for keeping up the servers and the sites were never what I wanted to spend my time on.  We have a flakey power situation at my house.  When there's a hint of rain or wind, the power goes down.  Something about "old wires across trees" or some other similar excuse is what our electric company would claim.  And someone nearby always seemed to manage to crash their car into a pole holding up these lines, also causing an outtage.  Not an ideal solution for reliable hosting.  My company wasn't about to invest in a generator for me, either, so it was always touch and go -- especially when we went out of town for several days.  If the power went out, no one was around to restart the servers when power was restored.  So it was either downed sites (and, more importantly, e-mail) for the rest of the trip, or an early return home.  I was coming to an impasse.

Well, after I left the old consulting company, turning it over to my former partner, it continued to fund the line (around $250 per month).  But the reliability problems remained.  And just when it was getting where reliability was worsening, and I no longer wanted the responsibility of self-hosting, the company closed up shop, forcing me to find an affordable alternative.

I don't remember where I found the first host I tried -- it may have been a recommendation from a colleague.  It was ASPnix.  The price was right, and they even allowed me two extra domains (above the standard five).  They actually upped my limit to 10.  But at only $77.70 per year, something had to give.  There were several outtages over the year or so I was with them, but they were fairly responsive at first -- I even had IM access with their main contact, Roma.  Roma was very friendly and helpful, so even when they changed their policy for ASP.NET 2.0 sites to medium trust across the board, I stuck with them (and even changed to ThinkJot for my blogs, since dasBlog would not run under less than full trust).

But serious e-mail and server problems a few weeks ago brought my relationship with them to an end.  It wasn't so much that there were constant issues where the e-mail server kept going down.  That was tough enough.  The real problem I, and several other of their customers were having with them was their absolute lack of communication about the issues.  I still had some occasional IM contact with Roma, but it was harder to reach him.  But there were only rare posts on the site or forums about the issues, and usually very lacking of details.  They'd say the "problem was solved", with no explanation or anything.  And on top of that, the problem wasn't really solved.  The outtages kept happening, more and more, for longer periods of time, and less and less communication.  The comments on their forum were getting more derisive all the time, and they still didn't get the importance of customer service.

I finally reached Roma via e-mail and then IM, and he basically claimed that they were struggling with sudden issues with SmarterMail (the popular mail server they use).  Basically, they couldn't figure out exactly what the issue was, and implied that they were having trouble contacting the vendor.  When I cautioned Roma that they are risk losing customers more over the lack of communication than the technical issues, he stated a common claim that he was so busy trying to solve the issue, that he had no time to communicate about the issues with their customers.  Notwithstanding the fact that they definitely had a resource issue on top of everything else, I explained to him a concept I have learned over the years:

Users like progress bars in their software for long running tasks.  We are not as concerned that refreshing this progress bar may add a couple of minutes to the total operation.  As long as we have an idea of what is happening, and how much longer it should take, we feel in some sort of control.  We can decide if we can grab a cup of coffee, go to the store, or buy new software.  We may not be thrilled with how long it's taking, but at least we have feedback and can decide what the next plan of action is.  We're not left in the dark.

Similarly, we customers like progress indicators from our service providers.  We don't mind if it takes a few more minutes to solve the problem, as long as we understand what the problem is, what is being done to try to resolve it, approximately how long it will take, and what steps are being taken to avoid having the same problem in the future.  When we're kept in the dark, it is extremely frustrating, and every problem seems worse and seems to take longer to fix.  We're ready to jump ship ASAP.

When I explained this point of view to Roma, he seemed to get it.  He had recently posted on the forum for the intention for better communications going forward, but had seemed to forget that promise.  I was hoping that my analogy helped him see exactly why this was so important.  I reminded him that many people were only sticking with ASPnix because they always showed promise for a solid low-cost hosting solution, but that they were still risking mass exodus.

Unfortunately, after an initial limited post about the problem, the next two days were even worse.  Communications stopped completely, and Roma was no longer anywhere to be found on IM.  I finally had to switch hosting companies, and e-mailed Roma about my cancellation, asking for a full refund (even though the annual fee is normally not refundable) because I had just renewed a couple of weeks prior.  To their credit, Roma wrote me back to say that he understood, and they did, in fact, issue me a full refund.

I wish them luck in resolving both their technical and support issues.  As I learned at my next hosting company, their problem with SmarterMail was not unique, and neither is their problem with support.  I'll talk about that in a future post.  In the next post, I'll start to discuss the steps I take when switching web hosting companies.

My Web Hosting Nightmares, Part 2 - Preparing for the Transfer
My Web Hosting Nightmares, Part 3 - Starting With a New Host
My Web Hosting Nightmares, Part 4 - Completing the Transfer
My Web Hosting Nightmares, Part 5 - My Continuing Story