How you will handle this situation?

Well, almost my daily life...hehe. Difficult to answer from outside but here comes some things I do. You said 3 month time line is strict. I will assume there is no documentation to consult. Some obvious: put all this clear to people that take the decision. Obvious if you are in my place because the team which take the decision know that.
The key thing is show the team you are there for helping them to make a smooth transition.
1-The former SME must return to work in this application again. At least to help you about the basic to get knowledge to operate the application.
2-3-4 month of KT is unacceptable. You have to work on that.
3-Team fears is "unacceptable". Always teams that will get the responsibility for something new will feel fear. People will not have all the knowledge needed. They will have quit enough only to operate the basic and after that they will get the rest by operating it. You can "use" this fear to motivate people to make extra effort in thinking themselves what components of the application have more priority to be understand to operate the application and go for them. You have to show you are there to facilitate them the transition.
You have to make your own timeline based on the current situation. With that on hand you have to think about different strategies to get knwoledge about the core of the application that will put the team able to operate it. And you have to make it visible and you have to assign risks to people that took this decision to make it responsible for the impacts no matter the position they have inside the company.

Milind -

This is where your judgment as a PM will be tested! Assess the situation through a risk lens and working with key stakeholders determine if the minimum success criteria for the project can be achieved or not with a moderate to high degree of confidence. If not, then be prepared to have a set of options to present to senior management. If scope and time are truly set in stone, then they should be open to pay whatever it takes to get it done. This could include bringing in a qualified, top notch, third party to do the technical work but it will cost a lot.

Kiron

This seems to be a typical case of triple constraints. Here time is the constraint and other, two scope and cost need to be adjusted. My suggestion is to take 2 approaches.
Optimistic with the team. Explain the team on the goal of the project and motivate them on how challenging it is and the benefits if it's done on time with quality. See if you can get some incentives from management.
Be risk averse with the management if you are not confident due to unavailability of the SME. Do a risk quantification and explain it to the management. Also provide a plan to mitigate the risk.
From scope perspective negotiate on MVP (minimum viable product) and plan for same. Have regular connects with management on the progress of the project and status of risk identified.
On execution, identify top 3 or 5 key deliverables. Plan for delivery of at least one or two with your key resources when the SME is available . This would give an opportunity to understand the key challenges and plan for them.
All the best.

One of the most critical things in a situation like this is to give the team the confidence that they can make this successful, rather than believing you are setting them up for failure.

You need a quick, feasible plan for how you are going to have a workable but not polished solution in time for your cut-over. Strip out the nice-to-have aspects and focus on the must-haves. That will also require establishing expectations with your sponsors for what "success" will look like in 3 months vs. long term.

The plan needs to show how you will utilize the new employees to the team to support the exiting SME, while learning on the job and developing greater skills themselves. That requires carefully assigning tasks based on capabilities which will require getting to know your team a lot better. It may take them 3-4 months to be comfortable, but that doesn't mean it takes that long for them to be productive while they learn. They need to learn to accept being uncomfortable for a while.

The early plan will by no means be the final plan. It gets people to stop staring at the problem, and start addressing the problem. Once you lay out the plan, others will pick your solution apart, and show you what is wrong with the plan. That is goodness. Take their input and build it into your plan. It will allow them to make the plan their own.

The more you engage them in the planning, especially the rationale for the plan such as phasing, parallel vs. serial activities, etc., the more capable they will be to adjust the plan so it meets both the technical needs and the programmatic needs.