Cross-cutting capabilities that turn an old Fortran codebase into a system you can ship, test, and operate with confidence — independent of which specific product or tool you use.
This is the multi-page printable view of this section. Click here to print.
Expertise
Cross-cutting capabilities we bring to every Fortran engagement.
- 1: 32 → 64-bit migration
- 2: Testing
- 3: Version control
- 4: Packaging
- 5: Backup and recovery
- 6: Legacy data
1 - 32 → 64-bit migration
Lifting production Fortran codebases from 32-bit to modern 64-bit architectures.
Moving a real Fortran ERP from 32-bit to 64-bit is rarely a recompile. Pointer sizes, integer kinds, file formats, third-party libraries, and decades of implicit assumptions all have to be found and fixed without breaking business logic that has been correct for thirty years.
We have done this on a production ERP — see Projects → Profitool — and we know what to look for.
Where we add value
- Auditing the codebase for 32-bit assumptions: integer kinds, pointer arithmetic, record sizes, common blocks, EQUIVALENCE.
- Driving the translation with Promula / gmFortran and hand-tuned changes where the tool can’t decide.
- Locking the result with tests so the 64-bit build provably matches the 32-bit one before you cut over — see Expertise → Testing.
- Operational cutover: data file formats, on-disk layouts, third-party library upgrades, and rollback plans.
Talk to us
2 - Testing
Unit, integration, and regression testing for legacy and modern Fortran codebases.
A lot of long-running Fortran codebases have no automated tests at all. Every release is “compile, run the smoke script, hope”. We change that — without rewriting the code first.
Where we add value
- Native unit tests in Fortran with TAP-style output and
proverunners — see the worked example at Examples → Unit Tests. - Regression testing by capturing the output of the existing system on real inputs and locking it down before any change is allowed.
- Integration tests across SQL, REST, and external libraries that we have added — see Examples → SQL and Examples → REST API.
- CI pipelines that run the test suite on every change, in containers, before any deploy.
- Test coverage specifically targeting the migration boundary so a 32 → 64-bit cutover is provably safe.
Talk to us
3 - Version control
Bringing real version control to Fortran codebases that may never have had any.
Plenty of Fortran codebases pre-date modern version control. We have repeatedly walked into engagements where “the source” is a folder on a fileserver, several zip backups, and tribal knowledge. That doesn’t work for testing, releases, or recovery — so we fix it.
Where we add value
- Capturing the current truth: figuring out which copy is real and getting it cleanly into Git (or whichever VCS you use).
- Branching and release strategies that match how your team actually works, not somebody else’s textbook.
- Hooking version control into builds, tests, and deploys so what’s tagged is what runs.
- Recovering history from old backups when you want to reconstruct a timeline — see Expertise → Legacy data.
Talk to us
4 - Packaging
Reproducible builds and packaging for Fortran systems and their dependency stacks.
A Fortran build that only works on one engineer’s machine is a liability. We package Fortran systems so the same binary you tested is the binary that ships — and so the next person can build it five years from now without you in the room.
Where we add value
- Containerised builds with pinned compilers and dependencies (HDF5, NetCDF, MPI, BLAS / LAPACK, vendor libraries).
- Versioned, reproducible artefacts — same inputs, same output, every time.
- Deploy packages that drop into your existing infrastructure rather than demanding a rewrite of it.
- Build-system rationalisation when the existing Makefiles / scripts have grown organically over decades.
Talk to us
5 - Backup and recovery
Backup strategies and disaster recovery for Fortran-driven business systems.
A Fortran ERP that loses a day’s data is not a software problem — it’s a business problem. We design backup and recovery for systems where the database, the data files, the binaries, and the build artefacts all matter, and all have to come back together.
Where we add value
- Backup strategies that actually get tested, not just scheduled.
- Restore drills — proving recovery works before you need it.
- Point-in-time recovery across SQL databases plus the on-disk Fortran data files that live alongside them.
- Disaster recovery plans that account for the build system and the source tree, not just the data.
- Migration of old backups onto modern storage — tightly related to Legacy data.
Talk to us
6 - Legacy data
Managing and recovering old data — from ancient tapes to file formats nobody documented.
A lot of Fortran systems sit on top of decades of data: binary records in undocumented formats, files copied from machines that no longer exist, tapes nobody has read in years. We are comfortable in that territory — and we know how to bring that data back into a system you can use today.
Where we add value
- Reading old binary formats — record-based, fixed-width, vendor-proprietary, or whatever the previous decade left you with.
- Reverse-engineering schemas from the Fortran code that wrote the files, when documentation is long gone.
- Pulling data off old media and old machines onto modern storage with integrity checks.
- Migrating recovered data into modern stores (SQL, files, APIs) without losing fidelity — see Examples → SQL.
- Long-term archiving plans so this is the last time anyone has to do it.