Old code is rarely the entire problem. The lost knowledge is harder to regain than Indiana Jones swiping that golden idol. AlphaPixel forward-ports, refactors, and revives software that no longer builds. Critical libraries from the 1990s, toolchains whose maintainers are gone, source that survives only as a binary. We recovered a 1987 Amiga raytracer from fragments, and we routinely port legacy OpenSceneGraph and osgEarth codebases onto current OSG or VulkanSceneGraph.
Most of these jobs look the same underneath. The original build environment may be extinct, the dependencies have moved, vanished, or evolved beyond recognition and API compatability. No one left on the team remembers why a particular hack is critical. We rebuild the build (CMake, vcpkg), untangle the dependencies, get it compiling on a modern compiler, built a test harness and only then change behavior. We can make it better than it was. Better, stronger, faster. And it won't cost six million dollars, even in today's dollars.
We've worked on active client projects with code dating back to the 90s and even 80s.
We reverse engineer when there is no source and cross-platform port when the original OS is not an option. We have the patience to read code written by someone who is no longer available to ask. We've all been there. We were there. Not 3000 years ago, but 40+ years ago, on platforms starting in the 8-bit era. We've programmed through the 16-bit, 32-bit and 64-bit migrations, on almost every OS from then and now. We remember how things were done and why, and can grasp what needs to be preserved and what shouldn't. But we don't do COBOL. Maybe a little bit of FORTRAN at parties, sometimes. Please, no punched cards or tape.
If your code is old and looking for love, swipe right on our Legacy Software Modernization capabilities.
Who works on it
Senior developers, 25-plus years each, as fluent in the historical systems as in the current ones. US-owned, since 2004.
Modernize your software
Send us the codebase, or read about consulting and custom software development.
Frequently asked questions
What is legacy software modernization?
It is taking software that no longer builds, runs, or fits current hardware and making it work again on modern systems, without losing what made it valuable. That covers forward-porting, refactoring, reviving dead build environments, and reverse engineering when the source is gone.
Can you revive code that no longer compiles?
Yes, that is a large part of what we do. The original build environment is often extinct and the dependencies have moved or vanished, so we rebuild the build with tools like CMake and vcpkg, untangle the dependencies, and get it compiling on a current compiler before changing anything.
What if we only have a binary and no source?
We reverse engineer when there is no source, and we cross-platform port when the original operating system is no longer an option. We have recovered working code from fragments, including a 1987 Amiga raytracer.
How do you approach a modernization project?
We rebuild the build first, get it compiling, then stand up a test harness so behavior is pinned down, and only then do we change or improve anything. That order is what keeps a revival from quietly breaking the parts you depend on.
Do you modernize OpenSceneGraph or osgEarth codebases?
Yes. We routinely port legacy OpenSceneGraph and osgEarth code onto current OSG or onto VulkanSceneGraph. We have worked on active client projects with code dating back to the 1990s and even the 1980s.
What eras and languages can you handle?
Our senior developers lived through the 8-bit, 16-bit, 32-bit, and 64-bit migrations on nearly every OS since, so we can read and preserve code written by people who are no longer available to ask.
Will modernizing break our existing behavior?
Not if it is done in the right order. Because we lock down behavior with a test harness before touching it, we can make the software better, faster, and buildable while preserving the behavior that matters.