"Please Mr Benioff - can I have my data back?" Slack holds customer data to ransom

01 February 2024
4 minute read
Best practice

"Please Mr Benioff - can I have my data back?" Slack holds customer data to ransom

01 February 2024
4 minute read

Slack didn’t have the best bit of PR this week…

Whoever said vendor lock in wasn’t a thing clearly has never tried to leave Slack.

One CEO was left dumbfounded this week when Slack threatened to delete his data because the tool Slack themselves had provided to migrate it kept failing. Despite paying Slack millions of dollars, the migration tool didn’t work. Slack’s response? Pay us money fool! “Sign a new contract or your data automatically enters deletion queue.” Ouch.

Luckily for Austen, this particular story appears to have a happy ending as Marc Benioff personally got involved and contacted him directly to sort it all out.

ITAM Review analysis

Data Egress – that is, the flow of data OUT of a cloud provider – has long been a potential problem for organisations as they digitally transform their IT systems and environments (and something which has caught the eye of national regulators. See Ofcom refers cloud to the CMA). However, it is rarely considered at the time of selecting a cloud platform, signing contracts, and migrating systems containing and generating sensitive and important data, both internal and external. 

When entering a new relationship, no-one wants to think about what will happen when/if it should all go wrong…but that’s exactly what organisations must do. Ensuring that you can extract your data from the platform in a timely, cost effective manner which requires no more than reasonable effort on your part is key.  

First of all – understanding what is possible during the product selection phase is important, to ensure any problems are noted early. For Salesforce (who own Slack) the data export ability is clearly advertised: 

Source: https://slack.com/intl/en-gb/help/articles/201658943-Export-your-workspace-data

Albeit there are caveats on that page as to what can/can’t be done. 

The next step is to read through the contracts and agreements – with your legal team – and understand the provider’s policy around data ownership and data egress. 

Assuming this all goes well, there is another step that this scenario highlights the importance of. As much as you can, get real world insights into the tool(s) and process(es) used – there can often be a difference between what is possible on paper and what is realistically available, for a variety of reasons. This is easier said than done I admit: 

  • You can’t test it yourself as you have no data to export 
  • The provider is unlikely to point you to other ex-customers to provide a reference 
  • Demos of tools do not always equal using the same tool in the real world 

But, if possible, this can be a critical step to prevent issues such as that above. 

In one of the screenshots, the customer asks Slack if they can “generate a full export” and send it to the customer, due to the self-service tools not working. Slack respond that it would require a “paid Slack service agreement” – which the customer later states was quoted at $78,000

Something to note is that this is a multi-persona/cross-stakeholder endeavour. It will require all, or some combination of, the following: 

  • ITAM 
  • Procurement 
  • Legal 
  • Cloud Centre of Excellence 
  • Architects 
  • Finance 
  • CTO 

And will require 6 months at a minimum. As an ever increasing number of organisations migrate and ever increasing number of systems to the cloud, all generating and storing an ever increasing amount of data – the consideration of how you get that data back in the future is more important than ever. 

Can’t find what you’re looking for?