ProductSphere and the Apollo 11 Code: A Modernisation Case Study

What if your most critical legacy system were as difficult to understand as the software that took humans to the Moon?

Before an enterprise can safely modernise decades-old software, it must understand what the system does, why its components interact, and which behaviours cannot change.

Most large enterprises have learned this the hard way: 79% of IT leaders report a failed modernisation project, at an average cost of about $1.5 million and 16 months. The expensive part is rarely the rewrite. It is changing a system nobody fully understood, and finding out in production which behaviours mattered.

We used Apollo 11’s preserved flight-software repository to explore how ProductSphere approaches that challenge: understand the code, document its behaviour, modernise it incrementally, and test the result against the original.

Apollo 11: the extreme version of the problem

Apollo 11 flew two computers, one in each spacecraft, each running its own program: Comanche055 in the Command Module and Luminary099 in the Lunar Module. Each computer had 2,048 words of erasable memory and 36,864 words of program woven by hand into core rope.

The software has every classic legacy problem, at the extreme. Its authors are long gone, its knowledge lives in scanned printouts, and one comment in the landing guidance, on a call that flew, still reads “TEMPORARY, I HOPE HOPE HOPE”.

What we did, and how you can check it

The code is public: the MIT Museum scanned the original printouts, volunteers at the Virtual AGC project transcribed and proofread them, and the result sits on GitHub. That means every claim below can be checked, so we have sorted them by where they come from.

Each step below has the same four parts: what makes it hard, what was done, the evidence you can inspect, and what a person checked before moving on.

Step 1: Understand the system

For a CIO, this map is the inventory a modernisation business case is built on: what exists, what depends on what, and where work begins. Without it, every estimate is a guess.

Step 2: Document what it does

Documentation is where knowledge stops depending on who is still in the building. Because every answer carries its source line, an engineer can verify it in seconds rather than take it on trust.

Step 3: Modernise one routine

For the rewrite we chose SPSIN and SPCOS, the Lunar Module’s single-precision sine and cosine: 32 lines of assembly, small enough to show in full below, and full of the traps that make real legacy code hard to move.

First, the blast radius. The source says who depends on these two routines, and it is not a short list: the autopilot’s timer interrupt, the navigation and guidance cycle, the landing displays and the rendezvous radar. One of the callers, QUICTRIG, exists because it is, in its own comment, 10 times as fast as the general routine. Speed is why sine was a cheap polynomial in the first place.

Then the traps. The AGC used ones’-complement arithmetic, which has a negative zero. Its multiplies keep the high word of an exact product, so they truncate. And the routine folds angles past 90° using a three-entry table it reaches by stepping one word either side of a constant called LIMITS. The table only works because of where the constants sit in memory; the source warns that one of them “must be two locations in front of BIT14”. It is exactly the kind of dependency a rewrite breaks without anyone noticing.

1SPCOS   AD      HALF+90°1SPSIN   TS      TEMK1        TCF     SPT1        CS      TEMKpast 180°: wrap2SPT     DOUBLEscale to π/22        TS      TEMKoverflow = past 90°2        TCF     POLLEY2        XCH     TEMK2        INDEX   TEMKstep ±1 word…2        AD      LIMITS…either side of LIMITS2        COM2        AD      TEMKmirror at 327682        TS      TEMK2        TCF     POLLEY4        TCF     ARG90exactly 90°3POLLEY  EXTEND3        MP      TEMKt²3        TS      SQ3        EXTEND3        MP      C5/23        AD      C3/23        EXTEND3        MP      SQ3        AD      C1/23        EXTEND3        MP      TEMK× t, exact3        DDOUBLdouble, then keep high word4        TS      TEMKoverflow → ARG903        TC      Q4ARG90   INDEX   A4        CS      LIMITS±full scale4        TC      Q

2function fold(x) {2  const t = 2 * x2  if (Math.abs(t) <= MAX) return t2  const r = t > 0 ? 32768 - t : -32768 - t4  if (Math.abs(r) > MAX) return 'full'2  return r}3function polynomial(t) {3  const t2 = mul(t, t)3  const a = mul(t2, C5) + C33  const inner = mul(a, t2) + C13  const y = Math.trunc((2 * inner * t) / ONE)4  return Math.max(-MAX, Math.min(MAX, y))}function spsin(x) {2  const t = fold(x)4  if (t === 'full') return x > 0 ? MAX : -MAX3  return polynomial(t)}1function spcos(x) {1  const shifted = x + ONE / 21  return spsin(shifted <= MAX ? shifted : ONE / 2 - x)}

Step 4: Test it against the original

Legacy systems rarely come with tests, so we used the original as the test. We assembled the full Luminary099 program (after fixing two file names in the repository) and compared it with Virtual AGC’s proofread core-rope listing: the memory bank holding SPSIN and SPCOS is identical, and 4 words differ elsewhere. We then ran the original routines from the proofread listing on Virtual AGC’s emulator of the Apollo Guidance Computer for every possible input, and compared each rewrite against all 65,536 results.

The obvious rewrite is the instructive failure. Math.sin is more accurate than the 1969 polynomial, and in a code review it looks like an improvement. It also changes two out of every three answers, because the original is approximate on purpose, in a smooth, repeatable way:

Whether a difference of 3/16,384 matters depends on everything downstream of it. That is exactly why the test compares against the original rather than against the textbook.

What this proves, and what it does not

Apollo is a demonstration of specific capabilities, not proof that every enterprise migration is now easy. It shows that ProductSphere can understand and document a system written in a language mainstream code tools don’t support, and that one routine can be modernised and shown to give the same values as the original.

It does not show a whole program migrated. Each routine was tested on its own, with interrupts off, on an emulator rather than flight hardware. Understanding the source code is an important starting point; real modernisation also needs environment-specific validation, integration testing and operational acceptance by the people who run the system.

Start with a Legacy-Code Assessment

If you have a system nobody wants to touch, the first step is the one we took with Apollo: understand it before you change it. We agree the scope with you before anything starts.

Sources

• Apollo 11 flight software, chrislgarry/Apollo-11 on GitHub: Comanche055 and Luminary099, public domain
• Virtual AGC project, ibiblio.org/apollo and virtualagc on GitHub: the yaYUL assembler, the yaAGC emulator and the proofread Luminary099 core-rope listing
• MIT News, Margaret Hamilton, computing pioneer who led software development for the Apollo program, dies at 90, 7 October 2026
• NASA Apollo Lunar Surface Journal, Apollo 11 program alarms
• Wikipedia, Apollo Guidance Computer: memory sizes and weight
• Vanson Bourne for Micro Focus, The size of COBOL, February 2022
• US GAO, GAO-16-468: Federal Agencies Need to Address Aging Legacy Systems, 25 May 2016
• vFunction, Common pitfalls of app modernization projects: vFunction and Wakefield Research survey, 2022
• ProductSphere figures: tiramai internal test on the full Apollo 11 repository, 10 October 2026. Modernisation and equivalence test: tiramai, 22 October 2026. The method, code and results are linked from the test results figure above