If the goal of the project is to make a decision (or more likely, to hand over a well-researched recommendation), then that decision is the deliverable. No need to overthink this.
And how to you handle a fact-finding project? Pretty much the same way as managing a system-building project actually. Presumably there will be phases of requirements engineering (ask stakeholders which features the new environment should have and how important they are - e.g., is price most important? Longevity? Support? Performance?), planning (i.e. research into which solutions exhibit which of these characteristics and to what degree), testing (either interviewing other users of the systems, or test-deploying something and using it yourself), evaluation and documentation.
So a fact-finding project may have slightly different emphasis on the individual steps; perhaps there is less testing than in a programming project, and more documentation, since the final report is the most important outcome. But the steps themselves are rather similar in intent, and can be handled by conventional project management methods.
