We did it by removing all non first-party access and turning the only access into a single-owner API service. Then we started partitioning off certain calls in

We did it by removing all non first-party access and turning the only access into a single-owner API service. Then we started partitioning off certain calls in to a cache, i.e. when someone decides they want all possible header combinations over a time period they don't get instant results but instead get a job ID and they can either get an event trigger when the results are in or they can poll for status if that is what they like. Next, we get the cache to write to ElasticSearch and on lookup it would first check if memcache has a pointer to ElasticSearch already and if not it would spawn the job, copy the input set to ES, run the query there and add a pointer in memcache. This meant that in practise you'd retain the same functionality you had before while not having a hard dependency on the backend. Next, we scaled op the API service and the cache service to a very high number and started querying for time ranges that were known to not have pointers in memcache. Depending on the amount of spot instances we could get for the price we wanted and the saturation of the 10GbE DirectConnect we could do up to 400MiB/s, 29TiB took us about 3 days because the DirectConnect was also used to other traffic that had a higher priority and the back pressure system would reduce the API request count accordingly (using Istio). In the end the users had only two changes: 1. No more 'talking to the database', you have to use the API which started out rather restriced 2. Some analysis takes a little longer during migration due to the SQL-ES copy action; after the MSSQL stuff was all gone the queries were much faster than before