Cfrgtkky

Talk to your team lead/manager about this. State you keep getting these tickets for your old project and you're concerned that no one else is being assigned to them.

If the response is that "it's your project, you're the best person to deal with these", then point out that you can't be the single point of knowledge.

What happens if I go under a bus tomorrow?

In a decent team of developers, there should be the ability to share knowledge and work on each others code/projects as and when the need arises. Sure, if there's something complicated/urgent, then you're the first port of call. For the more mundane tickets, someone else should be able to pick this up.

You need to deal with this situation (or at least try) before moving on - you might well be faced with the same situation at a later date. I wouldn't use this as the only motive for moving on if you're otherwise happy with the work.

would I leave a bad Impression if I leave my job for this reason.

There is absolutely no reason to give this as your reason for leaving. Find another job, resign, say goodbye without pointing fingers at anything, it's just a career move.

First, you have to aknowledge that maintenance is if not the biggest, one of the biggest parts of the software development cycle, see this post for example. This means that in your company or anywhere else you should expect to be doing maintenance of completed projects.
Second I think you should talk to your manager and ask if these tasks could be taken by someone else, but be prepared to hear a no, or no in the near future.
If you can't take anymore it's time for job hunting.

If this is your reason for leaving the job, you may find that you won't be satisfied with most jobs in the industry.

Software development projects are rarely completely "finished", there's almost always bugs to fix, new features to add, etc. NASA has some of the most stringent QA, yet they've had to send patches to space probes that are on their way to their destinations.

And often the best person to assist with that is the original developer. They could assign these tasks to someone else, but then they'll have a learning curve, while you could probably dash off the fixes relatively quickly. Maybe some large organizations have enough programmers that they can have completely separate groups for new development versus ongoing maintenance, but most can't split up these roles.

It's fine to want to work on new projects, but you should realize that as long as you work for the company your old code will probably always follow you. You can change companies, but the same thing will probably happen in the future. If a prospective new employer asks why you're changing jobs, you shouldn't tell them that this is the reason, because they may not want someone who will resist maintaining their code.

I think this is a very bad reason to leave your job. I get questions about older projects all the time, that's just like it is when you stay longer at one company.
A lot of projects are never really finished. It is in the best interest of the company to have the same person deal with issues that worked on the project. If somebody else has to deal with an older project s/he has to invest much more time which costs the company money.

If you actually give this as a reason for leaving it might convey that you are not acting in the best interest in the company, and that you will probably leave the new company again for the same reason.

The majority of software work is maintenance and updating of existing applications and systems. Only rarely will you ever get to work on new green field projects.

However you have been in the same job for 3 years now, and 2 years is about average to stay in the same role/company. Just say you're looking for new challenges, to work with new or different technologies etc. If you stay in the same job, and unless you're working on some mission-critical niche software (here's looking at you, COBOL), then moving on to keep your skills up to date would be considered normal.

Simply put, you are interested in leaving your present job, for a job with different role and responsibilities. That is valid. No need to dwell on two year old maintenance or continuous upgrades.

The issue is that you are looking for a different role. Think through the role(s) you are looking for, so that you are prepared to speak to them, and to increase your odds of landing the right role for you.

When you interview, emphasize what you like about your job. When I hire someone, I want to know what they like, what challenges them, and what they do well at. I don't want to hire someone who is sour on their last job.

A lot of answers here are talking about how important maintenance is in the development and lifecycle. This is pretty true but there are places where it is less important. It's certainly wrong to say that you should just quit because you don't enjoy maintaining legacy products. You aren't alone and there are business models that it can align well to.

Look for places that do contract or project type work for medium-to-large enterprises. These contracts will tend to have fairly fixed deadlines and a set budget of hours you'll be given to work on it. When you're done you'll move on to a new project and probably a different client. You'll still be expected to fix bugs but large updates will go through the whole project management lifecycle again so they don't happen as often.

They are more likely to want multiple people across projects to avoid situation like this. They tend to be more keenly aware of the bus factor for their projects because employee turnover can be a bit higher.

They also can be good at convincing the client to rip it out and build something new in 3-5 years as part of a tech refresh project. This is usually good for everyone since the contracting company makes more money. The client gets some shiny new systems to show off. The devs get to build something new instead of dig into old legacy code.

You'll still need to be able to write decently maintainable code and be able to quickly build the types of software they work with. The main things you'll need to be able to do are hit deadlines and build to requirements.

It isn't for everyone. Personally I sometimes wish I got more time to go back and maintain my old projects. But there is always too much new stuff to build. (It isn't the worst problem to have lol.)

You should not say you can't or won't do it. Saying that you can't or won't can make you look bad.

You should say "Schuuure.. I'd love to do it. My fee is XXXXXXX (maaany Xes)"

Then they have to be the ones saying no.

So don't quit. Instead say that if I am to do these things which are outside scope I want this more pay.

It's a red flag for future employers,
DON'T resign officially for this reason!

It's valid to seek new challenges but it's also everyday occurence to get unwanted assignments and a professional performs their duties regardless.

It's bad for the company to have only one person knowing about a project but it's also your "job guarantee" if you look at it that way.

Instead I suggest to inform management that you'd like to train someone else to ensure they have more than one person familiar with that project.

You can let them know that you'd prefer to work on different ones instead.
Keep in mind, it most likely will come over as unappreciative and you being a DIVA.

If you want to quit, follow other answers here and rephrase your reason.

They also won't take kindly to you leaving them hanging with that project.

It depends. The occasional question or query is considered normal but significantly more than that is a sign that things are not being handed over properly. Are you writing documentation of the projects you've done? Are they being read? Is there officially someone in your old position on the project?

If this is down to bad documentation, that is a bad one to use for leaving the company simply because the onus was on you to make the documentation. If the reason is more down to mismanagement of the old project, you should probably state that old projects were being handed over incorrectly, leaving you to deal with the aftermath.