Ask for time to process their feedback and schedule time days later to go over their feedback so that you can make sure that you absorb all the information provided. This will give a cooling off period and prevent emotional responses.

You may want to write down specific questions to ask as you process their report/feedback. Additionally, practice thoughtful responses that are not defensive but clarifying so that you get the most from the feedback and or clarifications.

Avoid the word "you" when referring to the developer who is doing the critique especially if you are taking issue with something that was reported. Instead, frame statements in a non confrontational manner, such as "I recognize the feedback given to mean that it may be better......". Or "for clarification, I could use some clarification for the statement/belief/finding.......". "I believe that their has been a misunderstanding/misconception when it was reported that....."

Such practiced statements will remove the defensiveness/blaming that can naturally occur when someone is critiquing something that we have worked so hard on. Time and practice can make this a good exercise for all concerned and avoid it becoming nothing more than what appears to be an attack on work that you were involved in creating.

Hope this helps.

Meet with this person before the formal meeting if you can. Giving an informal rundown gives time for processing and formulating well-thought-out questions/flags.

Provide as much material as you can on the new stack proposal. Make it clear that there are sufficient learning resources available and that the stack is well-supported/maintained on all levels.

Clearly define the issues with stack X (and make sure you're right!) AND clearly define how stack Y addresses these issues. If this stack was picked out of a hat, so to speak, then you hve more work to do to sell it. Hopefully there was a trade-off analysis or some other research you can point to that shows that stack Y wasn't picked on a whim.

Make it your goal to know stack Y AND stack X inside and out prior to the meeting. You'll get a lot more buy-in if you propose changes from a knowledgeable perspective rather than appearing to scoff at the current standard without understanding the reasoning behind the choice to use it.

Do not, under any circumstances, over-promise benefits to stack Y or make baseless claims about it. Sometimes changing stacks is more of a lateral move and that's ok as long as you're clear about it. Making claims that turn out to be false or misleading will hurt your credibility.

Don't try to address all concerns at this meeting. Record feedback and note that you'll research each concern and follow up with what you've found, which can either be positive or negative. (For example, one part of your stack could have an annoying pain point that's expected to be resolved eventually but users are living with it for now).

In terms of getting the best information out of the session, come armed with questions about the specific areas of the plan that you're least confident about. Also bring a few vaguer overarching questions - such as about what mistakes people most commonly make when doing such migrations; or about what the consultant sees as the highest risk component of your plan as currently formulated. These will allow you to get information about items that you may not have thought to ask about but that your expert can leverage their expertise to recognize as potential issues.

If you have time (as in hours, not seconds) to review the feedback and process it thoughtfully before responding, that can help a lot in terms of overcoming knee jerk emotional or defensive reactions.

I also find two distinctions important to make.

The first is between critique and criticism. That someone has suggestions to improve your plan doesn't mean that the plan was bad in the first place. It just means it was imperfect - as is everything humans do (yes, even you) - and has room for improvement. I think many of us in the tech community have a perfectionist streak, but when accepting feedback it's very important to forgive yourself for not being perfect.

The second is between critique of your work and critique of you personally. For those of us who take a lot of pride and invest a good deal of ourselves in our work, when someone points out its defects it can feel like a personal attack - even when the critique was in no way intended to be directed at your person. It's very important to remind yourself of that as you read or listen to feedback.

The part of accepting feedback that I personally find hardest is overcoming the sense that it means my initial work wasn't appreciated. Knowing what your own personal pitfalls are for feeling crappy about feedback can help you look out for them and catch yourself when you begin to fall into them, so you can step back and consider the situation more rationally and less emotionally.

Finally, in the bigger picture think of this as a learning experience. Imagine the work you've done so far as a school assignment to practice what you e learned so far. You're turning it in to a teacher who is going to point out areas for improvement so that you can level up the next time and do it better on your own.

The book Thanks for the Feedback, by the authors of Getting to Yes and Difficult Conversations focuses on this question https://www.amazon.com/dp/B00DMCV0XE/