Dividing big Dev team into small Dev teams

In my opinion, I'd say, Feature-based team. As long as the Support team has Experienced Tech's at that point all you need is the appropriate  Knowledgebase, proper documentation skills, and the right Support Manager. You can create a cross-functional support team.

A feature team is a cross-component, cross-functional, and a long-lived team that picks end-to-end customer features one by one from the product backlog and completes them. These teams play a crucial role in scaling up Agile development. An organization without a feature team structure is expected to create plenty of problems that lead to a sequential development cycle like Waterfall. This team structure fixes all these problems and also introduces some changes and challenges.

Why don't you let the developers decide? Raise the team size as an impediment and let them decide.

One approach at a former company of mine was the creation of cross-functional feature teams, but rotating one of those teams into a support role for a couple sprints.

The rotating support team would take a reduced amount of feature work due to their reduced capacity, and being in that support role provided every team member with a crash course in the applications they worked with and associated issues.

Each Development Team and individual Team member came out of the support experience much healthier and more knowledgeable.

Which approach would reduce the dependencies each team would then have to manage?

What do the team members think? They are the ones who’ll do the work.

The Dev team must be divided into Dev small teams,

When I read that I immediately asked "Why?".  What problem is being solved by doing so? And feels the change is needed?

After I read both of your suggestions I still have no clear picture of what you are trying to address or who feels there is a problem. Both options you have are viable but under different conditions. If you can clearly elaborate the problems with the current organization, then you can start to address them. However, I am going to side with @Aditya Vaze and @Ian Mitchell by saying that after you identify the problem, let the people doing the work decide how they feel they can best organize to address it. 

I like the idea to ask the developers themselves. It will give you and your PO other insights.

We have already asked the team how they want to do this, but there are different visions. I would like to know which approach is better. 

The only advice that I can give you is to NEVER create a DEDICATED support team WITH permanent members.

The developers that get stuck in that team will get/have the feeling that they aren't developing and will quit fast by asking their transfer to another department or just plain quitting the company.



I'm going the side of Timothy Baffa, you could suggest this approach to the Team and see what they think.

I agree with @René Gysenbergs and @Timothy Baffa.  The permanent support team is usually the team with the highest turnover rates. Avoid it if you must have a support team of some kind.

We have already asked the team how they want to do this, but there are different visions. I would like to know which approach is better. 

I think what you are missing is that none of us can tell you which is better because every organization, every team, every situation is different.  You have to help the organization for which you work to determine what is best for them.  If you are getting different visions, what would be the harm in letting the team pick one to try with the understanding that if it isn't accomplishing what is needed to solve the problem you are addressing, additional changes will investigated and try.  Approach this problem just as you would a new feature in your products. 

1. Pick something to do
2. Do it
3. Get feedback
4. Inspect
5. Adapt
6. Go to step 1

You may want to try a few "One-Day Sprints" (within the sprint)  for development teams to grasp their own inclinations, cohesions, and frictions. You can design it around a feature and support roles and align with your organization's vision. But still, I will insist that it would be better that they themselves decide how to organize. It will also provide all of you an ample opportunity to find a viable solution that fits your organization's needs.