If you are having portions of the project removed because the users don't want to change how they have always done things, that is not a reflection on your technical abilities. It is commonplace and fairly normal.
It is not clear to me if the people who caused the reduction in scope are users who don't like having a new way to do things or devs who don't want to follow a new programming paradigm. So I will address both.
If you want to improve the possibility of getting new ideas into the software, you need to learn how to sell your ideas. First, it is hard to change people and how they have always done things, It is called resistance to change.
The way to get around the resistance is to find out what the new method will make easier for them, what new things they will be able to do that they couldn't and what current problems the current process has that you are fixing. For instance, if the current process frequently gets timeouts causing the data to not be saved, then people are going to be more easily persuaded to try something new.
But if the current method is working just fine, then why would they want to? In this case, you need to have something major to sell them on that will make the change worth it from their perspective. You must always keep their perspective in mind. Nobody who is not a developer cares if the code is more maintainable or uses a more modern programming language unless you can sell them on the idea of what they gain not what you gain from the change.
This is true even if the users you need to persuade are other developers. Maybe they are uncomfortable with the new methods because they don't understand them or they feel intimidated by something they haven't done before. Even devs need to be sold on using new tools especially in an environment like manufacturing where the devs aren't as willing to be on the cutting edge as say a startup.
All users are people first and have the need to feel comfortable with their work. Psychologically very few people embrace change.
So what you do first is find out from them what the problems with the current system are. It is important to ask the people who are resistant to change directly for their opinion on the current process and how they would improve it. More often than not, what others perceive as the problems are not at all what you might see. Understanding the problems they want solved in the new software will help you build a better solution. it will also give you something to sell your new idea with. Further you may find that the solution that looks good to you is actually more time-consuming and harder to use for them. If I have to process X number of widgets per hour, any process that makes me do more clicks and take longer is a problem even if the underlying software is easier to maintain. Remember, users typically spend their whole day using the software, things that look minor to you can really impact their daily productivity in a negative fashion.
Plus a good part of resistance to change is that they were not consulted on the change and had no input into it. The less input they have into a change, the more people will fight it. This is why it is 100% of the time a bad idea to get requirements only from managers (unless only managers use the system) which is an unfortunately common practice. You (or the Business analyst or whoever gathers the requirements) need to talk to users as well.
The next thing that concerns people is that they know how to do what they are doing now and they are afraid they will get thrown into the ocean with no life jacket with a new system.
You counter this fear by specifying how they are going to be trained on the new system and how the new system will be documented and what help in general they can expect during the learning phase. You also take care not to switch to a new method during critical time periods. You don't change the underlying timekeeping system right before payroll is due for instance. Again yo get this information by asking the users about their deadlines and scheduled for the work, so that you can pick a better time to roll out the new system and get them trained and comfortable in it before the critical deadlines. If the devs are resisting instead of the users, again check the time periods, if the deadlines are tight, and they know they will have a long ramp up to new methods, then now is not the moment.
You also want to talk to the resisters about the advantages of the new way to do things. And do not talk about them from your perspective but from theirs. A dev who is resisting might be more interested to learn the new methods are more attractive in a job market than the old methods. A reminder of some particular problems in the past and how hard they were to solve with the old method and how much easier with the new would also help. A user who is resisting might like to know that there will be fewer times when the system goes down or less bad data to fix later. They might like that it will be easier for them to answer their client's questions or resolve problems.