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/flag

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).