I'm going to echo GrandmasterB's sentiment in saying that if your developers are only staying 4-9 months then the problem isn't the fact that these developers are being put on maintenance. You have a bigger problem, and the people who are leaving your company and telling you it's because of maintenance are just trying to sugar coat the real issue. While I can't speak for others, one reason why I might do something like this would be because I feel like if I raised the real issue then I wouldn't be listened to. Something, perhaps, like a toxic manager who's been at the company for years and management loves him but all his direct reports complain about him, but HR never does anything because they think he's great and he produces results. Do you know anyone who might fit that description within your organization? (hint: if not, it might be you) . You may want to search your company on Glassdoor and see what people are saying about your company; people tend to be more honest when they are anonymous, and you might find the real reason there. It's important, when looking through Glassdoor reviews to understand most people aren't trying to slander you, they are giving their real advice based on their real experiences, and many companies get defensive when told they have a problem, while you should be introspective and try to solve the problem.
Here's another question which might be illuminating to how your business can be run on a macro-level: Let's say I join your company. You put me on a project for the first 6 months, then I finish the project and you put me on maintenance for the rest of my tenure at the company. Then you want to start a new project, so you hire someone else. Then they go on maintenance. Then you start a new project and hire someone else, and so on. Meanwhile, me and the other guy are still at the company, we are capable developers who could do the project, and you're not utilizing us to fulfill your project needs. Aside from the fact that this makes us feel useless because we're not getting the "interesting" project work, it also means your code base is a mess, because every time you do a new project you hire new people who come into the company with their own standards and experiences and styles. This increases the maintenance cost of your service as a whole because in addition to regular maintenance stuff like data quality and bug triage, we (the maintenance people) have to also understand potentially tens or hundreds of different coding styles from all different people, some of whom may have left the company after submitting their code.
Realistically, you should not have a "project team" and a "maintenance team". You should divide your team by responsibilities or domains, and then every developer in each team is responsible both for new development and also maintenance of whatever is in their domain. Then you have team leaders or engineering managers who divide up those tasks among their team members so everyone gets a decent share of both new development and also maintenance tasks.
Another red flag to me about your company is that you feel the need at all to have a "maintenance team", i.e. a set of developers who are on full-time maintenance duty. This speaks volumes about the quality of your application code. Bugs happen, for sure, but if you have so many bugs that you have a team whose core responsibility is flying from one bug to the next to put out fires, it might be worth considering a rewrite of your application, because this is not supposed to happen. This comes from hiring bad developers, and bad developers are also people who might leave within 4-9 months, like "here's my crappy code, now it's your problem, see ya" (not that good developers don't have reasons to leave quickly, but bad developers have more reasons to leave quickly). You should probably also take a look at your compensation package for your employees and compare it to market rates to see if maybe you are not attracting talent. Talent attracts more talent; I would love to work with people who are smarter than me, but if everyone else is less skilled than me then I have no real reason to stay because I'm not learning or doing anything interesting, and I'm constantly having to fix other people's bad code because nobody writes code as good as my own.
1) You probably have a problem within your organization in the form of someone toxic in management. Find out who it is and get rid of them.
2) You probably should divide your teams into project domains rather than maintenance vs. project, and have team leads who divvy up project and maintenance tasks to keep your developers happy.
3) You probably should raise your compensation rates to attract talent who can build better code so you have to do less maintenance. You may also want to scrap your current application and rebuild it completely once you have good talent on board to reduce maintenance cost.