Saying first what I want you to see the most: please add a throwaway email to your bio profile (and maybe add a new comment with it so more see it). I guarantee people will want to say hi privately - not [just] vendors but random people who have on-the-ground advice.
--
Hopefully you still see this even though it's been a few hours.
Glad I went through the thread: there was quite a bit of extra narrative and detail in your comment replies.
> Our business is an old, traditional business that happens to have lots of data centers for legacy reasons. Even though we spend $BBB on data centers, they're not the core of the business and a very small part of overall revenue. Realistically, even if we didn't move from data centers we would be good as long as the core non-tech business functioned.
> Thousands [of engineers], many close to retirement age. Think a company like UPS/Fedex that isn't at its core a tech company but with tech datacenters for logistics and billions in revenue.
> [T]he cost savings hinge on the massive cost savings from moving to a commercial cloud, laying off workforce would save more, but would prefer to save a bunch by moving to cloud and keep the workforce for other things.
--
Ok, here's my take.
I wonder what your [job] position is, heh. Maybe someone with a CTO's ear, or maybe you're an unusually empathetic CTO.
In any case you're clearly at the point where you've had the internal discussions, the trigger has been assembled and is ready to pull, and you and/or the team (committee?) has probably already been groomed by all the gigantic providers' sales teams, which of course pull out all the stops in your case. If I understand these things correctly, if you haven't yet had an amazing lunch or two on one or more vendors' dimes, you will :) (or at least the high-level people will, would be nice if you get included).
Sales is important. But always remember, particularly for large potential accounts like yours, the sales numbers will always be what the high-level execs want them to be, and the sales teams will be spinning the story the execs want to hear. The on-the-ground experience is always going to be rough. You've probably experienced similar transitions, and that's what's informing your skepticism some of your team won't have jobs. Nice you're giving your people some thought.
On the one hand, it doesn't really matter who you sign up with, as vendor ceases to matter somewhat short of the $B mark.
On the other hand, try to mitigate the risk of discovering that a vendor can't provide a given feature at some eleventh hour, or you may end up in a confused tangle of AWS and GCE deployments (because the other major vendor will of course have the missing feature, and the fragmentation will begin).
How I'd achieve this: every time you go "ok, so this is our implementation blueprint", start the rounds of internal technical enumeration over again. Spend time with the engineers to understand pain points. Talk to as many people on the ground as possible, especially the forgotten people in the corners. One-on-ones, or small groups of people who are known to gel well with each other (no impedance mismatches, work well together), could be good for extricating annoying gotchas. This could look like devs aimlessly paging through source code and saying what they think (this could catch tiny things well), or it might be more structured with general architectural discussion.
Do NOT have the cloud provider vendors do this work (of talking to your existing team); I wouldn't be surprised if they offer to do it, but if they do, all their feedback ultimately goes to the sales guys (via an internal engineer digestion process), and not directly to you.
Well, the analysis team will probably generate a high-level report that contains all the information they've discovered (this is probably legally mandated for full disclosure about what they now know), but all the on-the-ground details about inefficiencies, vendor-specific pain points and so forth will only be derived by vendor-internal engineering debriefs, and you'll naturally never get any of this particularly valuable information - unfortunately this approach is within the vendors' business focus, as inefficiency means more compute resources used ($), and pain points mean more vendor-infrastructure maintenance ($). You could respin this statement to say that the vendor who makes the most attractive offer is the one who knows their system is the worst fit for your system, but I don't know :)
Instead, if you don't have the internal resources (or freshness/objectivity) to put together a bird's-eye view, get an outside consultancy to help, directing them to investigate your current architecture top-to-bottom-and-back-to-top-again, and advise on ways the system can be rearchitected for efficiency and optimization within modern cloud infrastructure. (They'd then be the ones doing the one-on-ones and so forth I mentioned above.)
Another thing that may be extremely useful would be to take the "we're moving to the cloud traction" and carefully smudge out (some of) the dividing line between "we're overhauling everything to migrate it and make it work most efficiently within $vendor" and "we're rearchitecting major components so they work more efficiently overall" so the line between these two sentiments is blurred, and both things wind up happening in lockstep. Obviously the two ideas are intrinsically distinct and this can only be taken so far - "rewrite everything from scratch to get it running in the cloud" wouldn't pass any accounting costing or time-boxing :) - but you can probably push this far enough to extract some usefulness from it (eg, you probably have an idea how long upper level will be willing to wait for this transition to finish - 2 years? 1 year? 6 months? - and you might be able to squeeze some interesting and useful tidy-up operations into that window).
Blurring the lines between these two things will play to your existing devs' strengths, as rewriting/restructuring is easier on the brain than the "replace engine in flight" of picking up all the existing state, punting it into to the cloud ad-hoc, and running after all the resulting fires that get created and scrambling to get it all working perfectly.
It won't be a perfect transition if you're really a $BBB operation, and restructuring will be the easiest way to cohesively get the existing devs into a flexible frame of mind and ready to deal with whatever curveballs get thrown their way.
This is one way you could efficiently achieve keeping a lot of your existing team.
Plus, restructuring means everything can slowly be built up onto the new system; picking everything up at once and expecting it to land on its feet probably won't go very well.
Depending on how things go, if you bring in new techs to assist with understanding modern best practice/hitting the ground running, I cannot recommend enough pitting them against your current team when doing onboarding/interviewing, as they'd be an EXCELLENT catalyst for judging candidates' character.
These are a couple of lateral ways the current workforce could be creatively employed during this time. I reckon careful management would see everyone kept on until retirement.
The current team knows all the systems inside out. Letting them go would make everything a thousand times worse.
Also, another reason I thought it would be cool to put an email is because your post makes for a perhaps-unwitting but nonetheless effective and interesting recruitment drive; I'm aware of very few (okay, zero) high-level people at equally high-level companies who really care about their employees. In my case this is because I don't have any connections, but the same probably applies to many others.
I don't know why https://news.ycombinator.com/item?id=16283252 stood out to me a few months ago, but your post resonates similarly. Probably because it incorporates a similar human response too. (Note that I have no association with the potential companies listed and have never talked to any of the users in that thread, I just thought it was interesting)