Wow, I must admit that my original comment was written from the position of "now how would this kind of thing happen in real life" and involved a rather heavy-handed dose of armchair speculation. The various details I mentioned (CTO-type position; that the decision is made; that the vendors have offered to help) were all "well it would probably happen this way" postulations. Ha. (Did any lunches happen yet?)

Vagueness is fine and important. Oh, and congrats on the newly-minted position :)

TIL what FAANG is ("Facebook, Apple, Amazon, Netflix and Google"). I see. Well, maybe posting in the monthly "Who is hiring?" threads could be helpful. (Reading through previous hiring threads is probably the best way to get an idea of what+how to post: https://hn.algolia.com/?query="ask%20hn:%20who%20is%20hiring...)

Who is hiring? is all semi-anonymously done, of course; what goes into the post is rough location, perks, job focus (an interesting question), benefits, etc. (Heh, I'd just link to this thread in the "benefits" section - then applicants would know they were applying to somewhere that looks like it actually respects what puts the intelligence behind "artificial intelligence" :) there's not enough of that out there IIUC, see eg http://rachelbythebay.com/w/2018/04/17/company/).

> The cloud vendors are in fact already offering to take on a lot of this work of transitioning, which I am avoiding to avoid lock in at all costs.

Well, for what it's worth, it is a necessary step. a) you're switching sysadmin+ops+networking+infra teams, so the replacement team does kind of need to get an idea what they're up against; and b) there's a reasonable chance that your deployment will give $vendor a run for its money and require small bits of build-out (probably edge-case handling) to more smoothly support your use case(s). This was why I mentioned the analysis teams would be taking their insights back to HQ for debriefing (cue internal mad scramble :P), but didn't manage to articulate that in my previous post.

Hmmmm, on that note, that gives me an idea: maybe port one or two of your craziest components - the ones that are the hardest to wield and integrate and _will_ have problems - to both vendors, and see what the customer support response is like. Ah, wait, that won't work, you won't be able to hide which account you're calling with problems about and the sales teams will make sure support pulls out all the stops. Of course once you actually sign up with a $vendor, you're a captive audience and will be subject to all the bureaucratic rainbow tape.

Ah, so this is one motivation to sign up with both vendors: to avoid lockin so they still have to work hard for your business.

So THAT'S why vendors work so hard for exclusivity. Hah! I suddenly understand a new reason why there's such a big reason to get vendor logos onto webpages, it's not just advertising for the vendor but because it almost certainly represents lockin - because it would be politically incorrect for a newly-cloud-ified company to say "we went with GCE and AWS!", wouldn't it? That makes it look like one provider isn't enough - when in reality, one vendor would probably provide all requirements, but once they're "it", they've got the contract and can stop working. (Something something psuedo-strawman argument...)

Hmmm. So that's a bit of the risk balance: go with one vendor and risk lockin and being a captive customer, or go with both, get slightly shunned ("we don't want your logo on our webpage, and we don't want you putting our logo and $competitor's on yours") and have a bit more control because both vendors are competing. (So then the shunning would be mixed with wooing. That would be interesting to watch. Why am I imagining buying popcorn...)

(This stream of consciousness approach was unintentional but I don't think I can express any better by refactoring the presentation)

Hm, another thing I thought of: if your existing workforce is big enough (at least 50-100 people? {EDIT: oh, thousands, this would work amazingly then}) and everyone's fairly isolated/segregated, you could take advantage of the segregation by getting everyone {or maybe many} to explain their systems to everyone else {or many others} - maybe explain to multiple people with decreasing levels of familiarity.

This would mostly be an exercise in "rubber duck debugging", with the decreasing levels of familiarity forcing people to articulate better.

This approach kills two birds with one stone: not only does it mean people have properly articulated their systems (and found lots of little edge cases), at the end of such a venture, everyone would know a lot lot more about everyone else's stacks. This in turn would have two benefits, a) people would better understand what the components they manage are talking to, and b) overall agility would increase as 1) remote teams could take simple steps to fix remote fires and 2) devs would better empathise with what they were interacting with, which will produce a more cohesive system overall.

Now I'll go reply in the thread where you explain current costs.

Wonder if you've gotten any emails from anyone yet :) I'll try and follow up w/ a ping hopefully soonish (might take me longer than I'd prefer but it'll happen).

(Also, the F5 key on my laptop is far too easy to hit... when this happens, I quickly open Chrome's task manager, SIGSTOP the renderer PID for the tab I'm in, gdb -p <pid>, generate-core-file, then grep my post back out. This is the 2nd time I've done this and it works absolutely great because HN uses <textarea>s :D. CTRL+W is harder and either requires a hasty drop into hibernation, or SIGSTOPping all the renderers then generating+grepping core files one at a time. Good luck if the ^W killed the renderer and the memory is now unallocated. Goes and installs form saver extension)