We CANNOT change the stack of the projects and the language used because these are choices of the clients. We work with multinational/worldwide banking and insurance groups the wildly use this languages. For example: a worldwide bank and finance group has all its internal system (not only batch, but also the ones used operator at branches) in Cobol on mainframes. the only part of the system not in Cobol is the home banking site, that in fact is not ours.

@LeopoldT In terms of security that is really bad

I'm a junior myself, and paragraph 3 is key to me. Sure more pay than other companies is nice. But even if it were double, I'm not certain I can even work anywhere else if I want to leave the company in say 5 years.

@EdwinLambregts makes a good point. You're probably better off staffing these roles with mid-career engineers; they're more likely to be looking for stability than a junior and they've already established a skill set in other languages so they won't be hamstringing their prospects at other companies as much as an engineer in their formative newbie years. You'll still have to pay an arm and a leg to entice people down this career cul-de-sac though - double sounds about right.

The name of the game in the modern IT environment is career security. If you get keep sticking with one aging technology stack, eventually you will find it harder and harder to get a new job. This is why junior and mid-level developers dont want to join you - it could be a death sentence for their careers. On the other hand, if companies keep this old stack they will become more and more desperate to find someone and that junior will be in higher demand (and could ask for a huuuge salary). Could not a whole career be made out of that?

@xDaizu sure, my cousin's husband does exactly this for a major bank in the UK. The issue is that there are only ever so many positions available as the pool of companies which are using these antiquated technologies are slowly shrinking. Eventually companies reach a tipping point where they are forced to update and upgrade their systems, and then the services of these niche developers are no longer needed. When that happens, you no longer have a marketable skillset.

@xDaizu: That's gambling. If you win, you retire before the technology is retired. If you lose, you're 45, unemployed, with 20 years of outdated experience. Very few people want to gamble when the stakes are that high.

@MSalters at that point (or before) you can move to management, or do open source/a code camp on the side. It's not "if I don't write in this exact language I'm ruined!"

@RobertGrant but even with "sides" on, the outdated technology experience is rarely useful if there's no connection to the new job... How many companies are willing to hire someone with 0 professional experience in the technology they need asking a higher salary than a junior developer?

@LeopoldT How did the clients react when your company told them that the price for your services will go up by X every year when they stick to their legacy systems because they cost you face for providing that service will increase every year?

@LeopoldT Well, simply ask your clients for tons of money to pay tons of money the few developers that you can find. If they ask why explain them the contents of this answer... initially they will pay you, then they'll either decide to not be your client anymore (and good luck for them finding someone else) or they will decide to pay for the upgrade/rewrite.

@AllTheKingsHorses I do not know details of the contracts because I'm a senior developer/senior team leader/technical project manager. I know that the fame of my company is that it is quite expensive

@Bakuriu As far as I know my company is the biggest in the country for these kind of projects. And the only one so specialized in these old technologies. Another factor is that for clients is very difficult to move to competitors after 20, 25 or more years with us: the amount of knowledge to be transferred is simply tremendous (also for money to spend)

@MSalters: Perhaps candidates will think “if you lose, you’re 45, unemployed, with (etc.). But I retired early and am comfortable, though For most of my career, I made less than average. If these guys are paying as much as stated, their people can afford to retire at 45. I know it would be a challenge to make them realize that, but ....

@WGroleau The big challenge there is pushing yourself to spend much less than you can. (Good job, btw!) But, there may be no intersection between these two groups: Group A, who are willing to work with antiquated technology, and Group B, who have the discipline and foresight to reach financial independence.

@CPHPython Almost every larger company, if you read around. You don't really think that the most valuable skill a professional programmer can have is "knows language X" - or even worse - "knows framework Y for language X" I assume. What I care about is if the guy knows how to work on large projects, has a good idea how to create a viable architecture and so on. Whether they picked that up writing COBOL or Go, who cares. I expect people to be able to pick up a new language that's similar to one they already know on the side in a few weeks.

@Voo those are assumptions that many are not willing to bet on blindly... A 20yo experienced dev in COBOL/assembly may be only comfortable in the same environment (his/her brain may actually refuse the concepts introduced by newer languages). Technical tests screen out candidates that are applying for a new role/dev, these are the determining factor if the experience worked out well for them... or not.

@CPHPython: But then the question becomes whether the concepts in the newer languages actually help to solve the problems your clients want solved. If not (and I've seldom found it so) then they're just so much obfuscation.

“Best thing you can do is to start regularly updating your current applications and core technologies to modern standards. This will mean rewrites of almost everything - potentially completely from scratch.” - This is terrible wasteful. Throwing away years of codified knowledge creates many more problems than it solves.

@BenMz relying on a technology stack that eventually nobody will be able to maintain is also a disaster waiting to happen. It's not "throwing knowledge away" either if programs are being constantly updated.