By ByteBot
On August 25, 2026, CCP Games deployed Stage 1 of the EVE Online Python 3 migration to the live Tranquility server — ending a 16-year run on Stackless Python 2.7. The game has been running on a runtime that reached end-of-life in January 2020. That’s six years of CVEs, six years of missing interpreter improvements, six years of Python 2.7 carrying one of the most complex simulations in gaming. The migration is finally moving, and the approach CCP is using is worth studying carefully.
The Constraint That Defines Everything
Most migration guides assume you can take the system offline, run your scripts, and validate the results. EVE Online cannot do that. The game operates 23.75 hours per day, taking only a 15-minute maintenance window daily. Every character, every ISK in every wallet, every skill point and asset coordinate accumulated over 20 years of gameplay must read back from Python 3 exactly as it was written in Python 2. There is no staging environment for your economy.
This constraint is why CCP’s strategy is a two-stage compatibility approach rather than a hard cutover. Stage 1 — now live — uses the Python-Future library to make EVE’s 2.4-million-line codebase run on both Python 2.7 and Python 3 simultaneously. The code doesn’t yet run on Python 3 exclusively; it runs on a compatibility shim that bridges both versions. That’s a deliberate engineering choice, not a limitation.
What Stage 1 Actually Fixed
The first stage targeted mechanical syntax incompatibilities — things 2to3 can find and fix automatically. Across roughly 20,000 files, the team found that 95.9% already compiled under both interpreters. The remaining ~3,300 blocking lines broke down predictably: approximately 1,500 old-style print statements, 800 long number literals (the Python 2 123L suffix), 600 deprecated exception clauses, and 50 uses of the <> not-equal operator.
These are safe changes. An old-style print statement means exactly the same thing as print() in this context. The automated tools handle these well, and the risk of regression is low. CCP ran mass player testing on the Singularity test server in July before deploying to Tranquility. This is the easy half.
Stage 2: The Part That Cannot Be Automated
Stage 2 targets roughly 20,000 lines of code that parse correctly under both versions but behave differently at runtime. The most obvious example: integer division. In Python 2, 1 / 2 returns 0. In Python 3, it returns 0.5. That’s a breaking change for any code path where the result is used as a damage value, an ISK calculation, or a coordinate. You cannot auto-migrate that. A machine cannot know whether the Python 2 behavior was intentional or accidental.
This is why CCP explicitly says Stage 2 requires human review. Every instance of potentially divergent behavior needs a developer who understands what the number represents in context. The team already dealt with the Stackless Python dependency separately — their open-source carbonengine/scheduler library replaces the Stackless microthread scheduler. EVE Frontier, CCP’s newer title, already runs on Python 3 with it. The migration path is proven. The manual work is just slow.
Related: Python T-Strings (PEP 750): Stop Using F-Strings for SQL
What Developers Should Take From This
EVE Online’s migration is extreme — most teams won’t face a 23.75-hour uptime constraint on a 20-year-old codebase. However, the underlying strategy maps cleanly to any legacy Python migration. The lessons aren’t theoretical. Simon Willison’s analysis of the approach highlights exactly why the futurize-first strategy matters: you can ship, validate, and iterate rather than betting everything on a flag day.
Use a compatibility layer before you cut over. Separate the runtime concerns from the version concerns — CCP replaced Stackless independently before touching the Python version. Automate only what you can verify automatically; every line where behavior could diverge gets human eyes. And test under realistic load — mass player testing on a public test server is the equivalent of load-testing your staging environment with real traffic patterns.
The payoff is real. According to the Hacker News discussion, Instagram’s Python 3 migration delivered 12% CPU improvement and 30% better memory utilization. Modern Python 3 releases have shown some of the largest performance improvements in the language’s history. EVE Online has been leaving that on the table for six years. Running unsupported runtimes is a slow tax, not a safe choice.
Key Takeaways
- Stage 1 is live on Tranquility: Python-Future compatibility layer deployed August 25, making EVE’s 2.4M-line codebase compatible with both Python 2.7 and Python 3 simultaneously.
- Stage 2 is the real challenge: ~20,000 lines of behavioral divergence (integer division, semantic differences) require human review — no automated tool can determine intent from context.
- The migration playbook works at scale: use a compatibility layer first, separate runtime dependencies from version dependencies, test under realistic production load before flipping the switch.
- Running Python 2.7 past EOL is a debt that compounds: six years of missing security patches, interpreter improvements, and modern tooling is a choice with real costs.
- EVE Frontier already runs on Python 3 with the same Carbon engine — the target state is validated. Stage 2 is execution, not exploration.
