[Dove]

The easiest transition is to learn a new skill applicable to what you're already doing. Tell your employer that your Cobol project is ultimately unmaintainable and they will have difficulty hiring Cobol engineers in the future. This is true and you both know it. Propose rewriting the system in Java (or whatever you want to learn, so long as it's a reasonable choice from an engineering perspective). They'll often go for it. Improve your odds by finding a small piece of the system to replace as a pilot project, where success on that small piece would offer immediate benefits like new automation options or the elimination of legacy equipment. If it's a small risk, they'll usually let you try, and if it works out, they'll often let you keep going. They don't want to be stuck with a project they suddenly can't maintain, and you're the best person to replace it -- not because you're a Java expert, but because you're an existing system expert. Find a low cost, low risk approach and it becomes a very good deal for them. They usually take you up on it (and are delighted by the opportunity), if they can spare the time and expense. Sometimes they really can't, and the answer for that is to be patient. And there's room here for going rogue and doing it without permission - I have done this many times in my career, and finding an opportune moment to say, "by the way, I had a slow week a while back and used it to make this more efficient and modern alternative for us" is almost always received well, especially if it just happens to be helpful with this week's painful problem. Skills used to tackle the same projects you already know how to do are both easy to move into, still take advantage of your experience, and are often easy to weave into your professional life. Boom, Java experience. The real beauty of this is that for your next job, they don't know you only have six months of Java experience. They see you worked at Corp for 5 years, you did Java there, and you can clearly do Java now. They don't usually ask too many questions.

A harder (but still pretty easy) transition is to work on something other people at your company are doing, but which you aren't. Perhaps there's a group doing big data and you want to get into it but you've never done it. Learning the skill on the job can be a hard sell, but it isn't always impossible. It's worth asking. Employers like working with smart people they already know, and can see it as a better bet to teach a known good guy a new skill than hire someone with the skill who turns out to be a terrible engineer. Some places will actually send you to school to get the certificate or whatever. However, this route often doesn't work because they genuinely can't afford to train you. Your odds of success go way up if you're willing to learn it on your own time. They improve even more if you can get pretty good at it. It helps further if the people on the team respect your intelligence and capability. The killer strategy is to make your preferences known, keep doing excellent work on your old system that no one else is willing to do, build up karma that way, get really good at the other thing on your own time and talk shop to the other team about their work, wait for a good time for the company. . . . your odds of eventually getting in are excellent. Boom, data science experience.

For something totally unrelated to what your company does, this is a lot harder. You have to both learn the skill and demonstrate competence on your own time. Your best bet is to build up a portfolio of accomplishments and side projects that you can share. This isn't the same as professional experience, but professional experience demonstrating you're capable, properly socialized, and people will actually trust you with stuff for years on end -- all of this still puts you ahead of total newbies, even if the specific skill is new to you. The truth is that talent is in such desperate demand (especially if you chose your new skill wisely) that interviewers are usually much more interested in whether you can actually do the work than they are in what your resume says. So just make sure you really can do it, and you really can prove that. Some employers really will insist that you have those 15 years of Haskell experience the job req says they want. But most of them will see solid general engineering experience on your resume, see during the coding portion of the interview and by looking at your public work that you really can do the job, and they'll decide you're probably the best bet they're going to get to fill the position anytime this year, and they really do need the help. Don't take "X years of Y experience" too seriously. If you really can Y, your odds are excellent.