Generally most M&A's like this turn into a talent smasher event (think atom smasher,
aka particle accelerator), and the people scatter to the four winds in hundreds/thousands of different landing zones instead of coalescing into another convergent organization. Emergent consensus centered around such a large organization takes a lot of effort and time to build because it operates through social trust pathways (that predominantly operate in the time domain), and once fissioned, the byproducts do not transitively transfer that trust, it has to be built anew.
This adds to my suspicions that the long-term IBM C-suite goal of the Red Hat acquisition is to eventually convert Red Hat to be like their captive mainframe revenue and profit stream. I would not at all be surprised to see a gradual deterioration in Red Hat quality in the coming 10 years.
Watch the general level of support engineering skills in what will eventually be a Blue-washed Red Hat L2 Support. That is your canary. What you are used to today in that tier will be gradually relegated to the tech leads for L2. Don't look for tech leads by title; look for the leads who gates decisions to escalate to L3. Highly-skilled L2 organizations grant most if not all their support engineers autonomy to escalate to L3. Profit-squeezing L2 organizations (what I suspect may be happening with Red Hat in the coming years) will gate those escalations, and staff vacancies with relatively down-skilled engineers.
Note that I also enjoy working with these relatively down-skilled engineers. No complaints about "bedside manners", and they can address common scenarios. Given enough time and exposure to more experienced staff, they would absolutely step up to highly-skilled L2 levels. The challenge is often these situations see those more experienced staff leave too soon. In my experience you need at least 7, ideally 14 years to season new staff to those skill levels, and the attrition rate is high over that time; troubleshooting well under pressure with grace is a very difficult combination of skills and characteristics to find.
Two ways I've seen to effectively deal with this on the customer end is find an alternative solution (not really feasible in this case at this time, though I'm watching several possible developments), or up-skill your staff. You'll know you've reached the right skill level when your engineers can delve into the internals of the product sufficiently that they routinely convince the down-skill L2 support engineers to escalate their lead within a day or two of engaging.
If my suspicions bear fruit (I really hope not, the vast majority of my clients hold massive people and capital investments in the Red Hat ecosystem), then this is extremely bullish for AWS. Their customer-obsession-to-a-fault culture would swiftly exploit IBM's strategy, and there would be no contest. I can see several simultaneous attacks AWS could mount to neutralize Red Hat's position if IBM's strategy at the end of the day really is what I currently suspect.
I'd really like to hear from others that have found other workarounds for this eventuality.