Hacker News Reader

Comment by meritt | Hacker News Reader

> What are enterprises supposed to use?

We run Mattermost on-prem. We've been quite happy with it. They have well-defined [1] migration plans for Slack, Hipchat, and others.

[1] https://docs.mattermost.com/administration/migrating.html

View on HN

"For teams with large amounts of data, the export function has been reported to fail and it may be difficult to reclaim your team’s data. Consider contacting HipChat support to see if a new solution is available."

They're kidding, right? That's a well-defined migration plan?

I don't think its fair to blame them on the failure of the solution you picked before, and nobody else will be able to handle better.

I'm not blaming Mattermost for Atlassian's choices, I'm saying, you can't really try to recruit dissatisfied HipChat customers with promises of a supported migration if you can't help HipChat customers de-facto migrate from their old product to your product.

I read this as HipChat’s own export function having problems handling large amounts of data.

I’m not sure how this is Mattermost’s fault.

I'm not sure what they mean by "export function". Hipchat isn't "an application", it's a bunch of services running on a network of VMs. At the very least, Hipchat includes Elasticsearch and MySQL. Seems odd that they'd rely on any particular Hipchat API when they can rip that data out of the guts of the machine.

I'm sure there's a fair amount of business logic between what's in the database and what's delivered to the presentation layer. Pulling from a database means that the new company has to reverse engineer Hipchat's API implementation.

HipChat internally uses Postgres and Redis, not some proprietary undocumented blob store. While I'm sure that a working applicative export function would make things easier, I don't see why you can't give Mattermost the relevant read-only credentials to those datastores and let Mattermost read directly from the source.

Reply on news.ycombinator.com