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.

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.

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.