Almost a decade ago, started hosting my blog with DreamHost. Needless to say, I’m no longer a DreamHost customer. I had intended to let this change pass without any mention. That was until I went through DreamHosts’s account closure process.

I think many times people on both sides of the fence, take these kinds of decision personally. And many people make decisions like this when they’re angry immediately in the aftermath of something happening.

I don’t bear any ill-will towards DreamHost, while their actions played a large part in why I left, so did their product portfolio at the time, and even my own preferences for how I wanted to do things going forward.

Being passionate about your business is important for small business owners. At the same time, it’s important to recognize that some customers are going to leave. Some will be happy; but external factors demand they go elsewhere. Some will be angry; because of something you’ve done, or haven’t not done. Some will be in the middle.

Moreover, these kinds of changes are stressful. Certainly to the customer, and potentially to the people who make up the business as well, especially if it’s a small one.

For the business, especially a small business, a customer leaving can raise all kinds of concerns. Why are they leaving? What are they going to tell people about your business? Aside from the direct loss in income, if they start telling people the business sucks, how might that going to affect future income?

As a customer, I don’t like being in the position where I’m being forced to explain myself before I can’t close my account.

In some very real ways, I think it’s a good sign that a business cares enough about their operations that they want to know why a customer is leaving.

At the same time, when a customer is leaving don’t get in their way or come across as demanding. The soon to be ex-customer does not owe you an explanation for why they’re leaving, and if they choose to share any information with you, you should be thankful for that and not demanding more.

This was the problem with my parting experience with DreamHost — demands that I answer questions about why I was leaving.

When I closed my account, I was presented with a survey about why I was leaving, where I was going and so forth. A survey that I couldn’t leave empty or partially filled out.

I don’t feel I owe DreamHost an explanation. I don’t feel my clients owe me that explanation either. And as a customer, I don’t like being in a position where I’m being forced to explain myself before I can close my account.

On what’s very likely to be my last interaction with this company, they wouldn’t just let me go in peace. As a customer, this relatively minor action was sufficient to prompt me to write and talk about something that I had no previous intentions to do. My final experience with DreamHost wasn’t positive, or even neutral. I’m going to remember this, and when people ask me who is a good hosting provider, I’m going to be much more inclined to say nothing or respond negatively, than recommend DreamHost now.

My History With DreamHost

I came to DreamHost in late 2007 to host a blog. After doing some research DreamHost consistently came up as a good hosting company. Their prices and features were good, so I signed up for their shared hosting plan.

Shared hosting means that your site, along with a whole lot of other sites are all served from the same server. This is generally good for all parties involved; better hardware utilization for the host, lower costs for the users.

However, there are downsides. Since the resources are shared, if someone’s site goes amuck or a site not the same host gets super popular or DDoSed, your site is impacted too.

In late 2011, DreamHost offered virtual private servers (VPS). VPSes offer dedicated resources and more control over the software configuration. Best yet, for early adopters, they were offering a $5 discount (which amounted to 50% off on the base configuration). I upgraded to their VPS service.

For the most part, DreamHost had been a pretty solid experience for me. Okay sure, I can quibble about things now and again. But over nearly 9 years of use, problems were mostly few, isolated, and resolved pretty quickly.

That was until November of 2015.

Changes to the VPS Accounts

In November of 2015, DreamHost notified their VPS users that they would be removing sudo/admin users from their VPS accounts as part of a product re-alignment. When I bought my VPS, this was one of the selling points of me.

Their email went on to say that if I wanted to retain admin level access, I would need to change to their DreamCompute service. Further, this change would be going into effect in less than 2 weeks. Finally, as a short term workaround, I could open a ticket to extend that time frame to allow me to transition to DreamCompute or update my sites/services.

I don’t begrudge DreamHost for changing their products and services. I had no long term contract for what would be supported on my VPS so they were perfectly in their rights to change things.

Moreover, I can completely understand the needs to re-align a product or change it’s prices. When they first sold VPSes, they were the only option besides shared hosting. Now, DreamHost was building their cloud compute platform and the VPSes needed to be adjusted to fit with the larger product strategy.

For me, the changes weren’t the problem. It was the way they made the changes that prompted me to start questioning whether DreamHost remained a good fit for me.

Bad Timing

To start with, I felt the timing was really poor on a number of counts.

First, the deadline was just after Thanksgiving weekend. Instead of having a nice peaceful weekend with my family not worrying about anything hosting related. I now had this VPS change looming over my head. While it didn’t ruin my holiday, it did lessen it and it will be a negative interaction with the company that I’ll remember for a long time.

Unless something must be changed absolutely right now for life, safety, or security reasons, carefully consider and manage the timing of events especially around major holidays.

Compounding matters, communication was abysmal and this is a separate point I’ll come back to in a bit.

My big take away from this is that if your company offers a service, don’t make changes to that service that correspond with a major holiday unless you can’t avoid it.

Some customers won’t care, or will have staff that can handle it without burdening anyone specifically. But some, like me, will be impacted. For the former, the timing is going to be less important either way. However, for the latter the choice of timing can easily result in a very negative interaction.

On the broader point, there’s also the larger aspect of when this was being done, right in time for the Christmas/winter holiday season.

For a lot of businesses especially retail and service ones, this is one of the busier times of year. For a small business, having to take people off other duties to deal with something like this can be seriously inconvenient. For personal site owners, it potentially is taking time away from them being with their families.

My takeaway, unless something must be changed absolutely right now for life, safety, or security reasons, carefully consider and manage the timing of events especially around major holidays. Moreover, short deadlines should probably be avoided completely, but even more so in late November and December.

Too Short of a Timeline

My second problem was the timeline for this change. According to the email I would have less two weeks to make whatever changes I needed, or get an extension. I received the email informing me of the change on the 17th, with the deadline for the changeover being the 30th.

I understand the need for deadlines… But at the same time, when creating deadlines, I think it’s necessary to understand that the people affected can’t pivot immediately either. There has to be a compromise.

The specifics here need a bit of backstory.

When I moved to a VPS, DreamHost’s lowest tier offered 300 MB. This wasn’t a problem for me, I’d already tested on my dev server to insure that I could work in those constraints.

However, there are two issues here.

First, Nginx (my web server of choice), unlike Apache, requires root permissions to reload the configuration.

Secondly, there was a quirk with the PHP implementation on my VPS where PHP would stop responding to requests, or die, and not be restarted automatically. The workaround was a cronjob that would check that the process was responding, and if not would kill and restart them. This also needed root access to work.

Without root permissions, the best I could do was to reboot the VPS instance (which interrupts my service) if I needed to change the Nginx config or if the PHP process stopped responding. Compounding matters, DreamHost also removed the ability to programmatically reboot VPSes too — now you had to do it manually through the web interface.

Suffice to say, based on their initial email, I had two weeks, design, test, and implants fixes to my satisfaction before I lost my root user and was pretty much out of luck or hope they’d give me an extension.

I understand the need for deadlines; if there weren’t any, people would never change over. But at the same time, when creating deadlines, I think it’s necessary to understand that the people affected can’t pivot immediately either. There has to be a compromise.

Problems with Communication

DreamHost’s short term mitigation was to open a ticket to extend your cutoff date.

I opened a ticket the day after I received the initial email (Nov. 18). From then until well after their November 30th deadline, I received no actual help regarding my problem. I was shuffled around in support queues, told that there was a lot of requests for this and that they’d get to me as soon as possible and so forth.

Communication is so important. I clearly did things that maybe I should have held off on, because I either didn’t know what was happening or was working off outdated information that wasn’t corrected.

When Thanksgiving weekend came around, I was still in the dark about what was happening. I only knew that my ticket was received, in a special queue, and that on the following Monday my admin user would be removed.

Then the deadline passed, and I still hadn’t heard anything about keeping my root user.

At this point, my memory of things gets kind of foggy. DreamHost encourages you to use their support portal for support people not email, so my records of my half of the conversations are lacking.

As best I can recall, while working in the dark I was doing whatever I could to see if I could make things work without an admin user. My admin user was removed, or I removed it, but not really or fully, I’m not entirely sure anymore. The only record of what happened I have, is a communication from a DreamHost support person in early December to the effect that I had removed my admin user, and how could they help me.

Bearing in mind, until that email I had no indication about what was going on at all. And for whatever reason, I still had an admin user, and still had admin access to my VPS.

Actually in retrospect, there are two big takeaways I have from this.

First of all, in retrospect I have a real lack of records of my support communications with DreamHost. I’m sure some of this is my fault, either I told the system not to send me a copy or I deleted my copy for some reason. In either case, my records aren’t complete.

This is a huge my bad. I should have ensured that I was keeping a paper trail on my end — or maybe I did and I deleted it thinking it was no longer important. In any event, in hind sight I recognize that I should have kept better records.

That said, I also think that systems like this should be designed to insure that both parties get complete records that don’t rely on just that system.

Secondly, communication is so important. I clearly did things that maybe I should have held off on, because I either didn’t know what was happening or was working off outdated information that wasn’t corrected. I should have been more patient, but it’s hard to be patient in that situation.

I really appreciate that as an individual or a small business owner, communicating can be a scary at times, especially for bad news. I also appreciate that for a small business owner sometimes communication can slip through the cracks. And of course, email isn’t the most reliable medium — sometimes stuff gets marked as spam that shouldn’t be.

However, DreamHost has none of those excuses. They have a support staff, not just one person. They have software capable of sending out mass mailings. They could have updated us continuously about what was going on and I wouldn’t have been scrambling to do things based on what I though was the case but in hindsight was not so.

Problems with DreamCompute, the Long term Solution

The long term solution DreamHost proposed was switching to their unmanaged virtual computing platform, DreamCompute.

However, when DreamHost announced this admin account change, DreamCompute was still in beta. Moreover, all of the available openings in the beta were long gone before the whole VPS changeover thing was even announced. This was back in early December of 2015. And as I recall I still had no movement on that issue going it to February of this year.

Businesses, if your solution to a problem you’ve created is for your customers to change to another of your services, you absolutely must make sure that new service is fully available before you start telling people to switch to it.

Bad Timing and Down Time

The straw that broke the proverbial camel’s back happened in late February of 2016.

In late February DreamHost moved my VPS to their new datacenter. Moving servers, even VMs, is a great time for things to break. When my VPS moved, it broke.

If you’re going to do work that can affect customers; you cannot remove their lifeline to your operations.

If I had still had admin access, I could have probably jumped in and fixed whatever was the issue and saved some 8+ hours of down time. But my admin user was long gone, so I had to rely on DreamHost’s support.

Only DreamHost’s support people were all at their annual customer support company meeting.

No words adequately express the kind of anger I have for this kind of behavior. They had to have known in advance when they’d be moving servers, and when their customer service meeting was taking place. Surely they could have scheduled the two events to not overlap. Heck, even if they had to have them overlap, surely they could have done something to insure that there were support reps available to handle problem cases if they showed up.

If you’re going to do work that can potentially affect customers; you cannot remove their lifeline for support.

Is DreamHost a bad company or a bad hosting company?

I don’t think so. In nearly a decade with them most of that time was just fine. I know people who are still customers, and as far as I know they’re perfectly happy with the service.

My decision to leave was a combination of a lot of factors, not just one incident. DreamHost’s timing on product launches and changes was poor for me. I also had a significant change in opinion about both continuing to deal with their quirks, and my own confidence in running an internet facing server.

That said, from all of this I’ve taken away some fundamental business points form the customer’s perspective.

• Try to understand how your changes can impact your customers. If your change will potentially create work for your customers, make sure that your plan adequately accommodates them needing to make and test their changes as well. Make sure there’s ample time both them and your own staff to address issues. Sometimes, there are good reasons to have a short timeline, if that’s the case, communicate that too.
• Communication is absolutely critical. If you’re having a problem or there is a huge volume of something you’re dealing with you need to communicate this to your clients what’s going on. Submitting a support ticket then hearing nothing, not even another automated message telling me that they had a huge volume of tickets and would get to mine soon was very disconcerting.