The Grass isn't really much Greener in Green-field Software Development.

"It is fun to build systems from scratch, but frankly green-field systems have their own set of problems¹." 

The Typical Scenario:

An existing system becomes murky and hard to change over time. People in the organization get frustrated with how long it takes to make changes in it. They move their "best" people and sometimes their trouble-makers onto a new team that is charged with the task of "creating the replacement system with a better architecture". 


In the beginning, everything is fine. They know what the problems were with the old architecture, and spend some time coming up with a new design. In the meantime, the rest of developers are working on the old system. The system is in service, so they receive requests for bug fixes and occasionally new features. The business looks soberly at each new feature and decides whether it needs to be in the old system or whether the client can wait for the new system. In many cases, the client can't wait, so the change goes into both.

The green-field team has to do double duty, trying to replace a system that is constantly changing.  As the months goes by it becomes clearer that they are not going to be able to replace the old system (the system you're maintaining), any time soon . The pressure increases. They work days, nights and weekends. In many cases, the rest of the organization discovers that the work that you are doing is critical and that you are tending the investment that everyone will have to still rely on in the near future².

References:

1,2: Working Effectively with Legacy Code by  Michael Feathers