[RyanZAG]

Reply from miles:

  Actually, it's been a struggle for me. I've gone through two co-founders,
  who, in their own ways, just didn't work out. Who knows, maybe it's me. 
  All I DO know is that my customers were starting to be affected by it, 
  so I had to do something.
  The entire reason for this acquisition was for the customers. 
  They need someone who can take care of them like they deserve.

[aneth4]

> The entire reason for this acquisition was for the customers.

That's just obviously not true.

How does this acquisition in any way help customers?

The resolution offered is to migrate manually to Redis Cloud, something customers could do regardless.

Seems the acquisition resulted in the service being shut down far more abruptly than otherwise, unless the situation was so bad they couldn't afford a few more weeks of hosting.

[miles-myredis]

I posted a more in depth response in this thread, but the short of it is this.

1. I'd tried finding new people to help with the increased workload of new customers. Everyone I found failed, causing me months of setbacks while I did 2x the workload, and then tried to train a new person on the stack.

2. I've been funding this completely out of my own pocket. No VC money, or even buddy money. After the most recent co-founder being arrested, I had to make a decision. Either my customers suffer, or my family suffers. Since I was unwilling to have either of those out comes, the only logical (yet painful) solution was to have a company with the proper resources and expertise take over.

[sgrove]

While I was initially disappointed in what seemed like irresponsible post-acquisition behavior after reading the linkbait title, after knowing what kind of a situation you were in, it makes a ton of sense. Don't worry about the ridiculous critics in the crowd, it's a very different world when you're in the thick of a failing startup with people/family depending on you.

This seems like the most responsible action you could have taken, and is a noble way of handling your customers' trust. The option to migrate anyone who asks but to encourage developers who know what they're doing to do it themselves is similarly appropriate.

The only seemingly missing piece is a longer notification window.

Sorry for the rough ride of a failing company, but well done for handling the transition appropriately.

[miles-myredis]

The really crappy part was, the traction was starting to pick up this last month. :(

[aneth4]

Ok - I guess it was just REALLY inept messaging after the acquisition, maybe mostly acquiring company's fault.

How about:

We've been acquired. Over the next 3 months we will be migrating customers and will notify you of any action required.

Instead of:

We've been acquired. Piss off.

[aytekin]

If the acquisition is for the customers the correct way to do this would be to handle the transfer for the users. Move the data for them and even keep the existing connection hostnames etc working. So, no change would have been needed for the users.

If the parent company has the same service why ask the users to do switch manually? I think with the excitement of the acquisition they have simple not thought through things.

[miles-myredis]

I agree completely! However, in our particular instance, our customers are mostly developers themselves. Most developers are fully capable (and even prefer) to manage migrations themselves. Due to some features (pub/sub) that don't translate well with migrations on Redis, we wanted people to have the option. Which is why we are also migrating anyone who asks.