So, first, please stop saying 'leverage'. Say exactly what you want to do with it ("I want to run the bytecode across platforms.", "I want to use my old .cs files in ten years.", "I want to...", etc.). Buzzwords aren't helpful for us here.
First, let me try to see if I understand your underlying questions:
- I wrote a game or engine to do X on Y platform. How do I use this (without modification) on platform Z?
- I wrote a bunch of code in language X. How do I convert it to language Y?
- I want to rerelease my game or engine X for platform Z 10 years later. How does this work?
All of which boils down to a better question; we'll get there in a bit.
I wrote a game or engine to do X on Y platform. How do I use this (without modification) on platform Z?
So, there are two parts to this: "doing X on Z", and "using on Z".
You want to make sure that you are bringing something worthwhile onto the platform ("doing X on Z"): why port a text adventure game onto a PS6? Is there an opportunity to update the technology and game to make better use of available resources (i.e., "I've got pixel shaders now, so I can move away from statically-calculated per-sector lighting in my Doom clone.", "I've got hardware T&L and rasterization now, so no reason to use an engine limited to raycasting wall segments")? If you are porting over code limited by old hardware, might as well ditch those limitations and start anew.
"But," you say,"Zork is still awesome, and would be great on the PS6!".
Okay, no worries, agreed. So, now the problem is how to make Zork run unchanged on a PS6 ("using on Z"). To run old programs, you either need to adapt the code to its new operating environment, or adapt its new operating environment to it. You made a decision writing your code, and this is what is going to be important: did you write your code to be interpreted?
Why yes, all of my game logic is in a custom, well-specified bytecode format running on a custom virtual machine.
Good for you, Mr. Fancypants. You saw this day coming, and you wisely wrote your language to run completely on a virtual machine (emulator). You are following in the footsteps of Carmack, Lucent/Bell Labs, or Berez and Blank. All you have to do to run a port is to rewrite/recompile your interpreting environment, and now you can rest assured that as long as people can write VMs for the new platform, you're tech will persist. Java or C# is a decent way of going about this as well.
Er, that's rather silly... I just wrote everything in portable C/C++, complying to all the standards and abstracting away all of the platform-specific stuff.
Alright, cool! Your diligence in proper systems engineering and abstraction is going to pay off. You just have to rewrite the platform-specific stuff, tweak the build process, and away you'll go! Sure, writing a Direct3D backend to replace your OpenGL renderer might take a month, but hey, at least it isn't the whole stack!
Um... I... uh... well, it was a lot simpler to let objects make Direct3D calls directly. I mean, it wasn't supposed to turn into this big app.
Congratulations! You're screwed!
...more seriously, this is something that can be unavoidable. If you wrote your text game in QBasic, and here we are on Windows 7, you probably can't do anything to salvage it. At this point, you can't possibly adapt your application to run correctly on the new architecture/machine/operating system.
So, you'll need to adapt the environment to your application (if Mohamed won't come to the mountain...). Consider: if you've got the binaries, and the assets, and you know the configuration of the machine they ran on successfully, then all you have to do is use some emulator for that environment. This has been done before. As long as you don't need to communicate with it, or reuse its routines, you'll be fine.
But... but... but what about my A-star implementation in 68000 assembler? I don't want to rewrite that!
Tough luck. That's the cost of not thinking about what you are going to do with your code later in life. This is why we call it software engineering, not software kludging--at least not in public.
I wrote a bunch of code in language X. How do I convert it to language Y?
One character at a time?
sed and regex?
More productively, if you wrote it in C or something similar, you might have it compiled into a library you can link with. It's okay to have something written in Fortran that you can still call from other code whose build environment knows how to digest libraries. COM objects and .dlls and all that let Visual Basic apps interact with C# code.
If you have to rewrite it, and don't care about code quality, sometimes you can find a tool to do the work for you. This might not even work, but hey, you don't have to write the code yourself.
If you don't mind, rewriting it in another language is a great opportunity to learn the new language, remove dead code, and rethink old algorithms that might not be optimal anymore. And because you wrote good unit-tests (right?), testing that the new code is at most as buggy as the old should be easy.
I want to rerelease my game or engine X for platform Z 10 years later. How does this work?
After reading the above, it should be obvious: write modular, well-specified code for a virtual machine, and/or properly abstract away implementation-specific functionality. If that doesn't work, ship it with an emulator.
The real question you want to ask, though, is:
How do I design software that I can keep using throughout my career?
You've got to plan out, ahead of time, what it is going to do, and how it is going to do it. You've got to hide or isolate anything that doesn't directly deal with the logic of the algorithms being implemented (no direct API calls), or decide where you stop caring about portability. You've got to be willing to remove and rewrite deficient code. Mostly, though, it's the same as the way you get to Carnegie Hall:
Practice, man. Practice.