EVE Online Prepares for Its Most Dangerous Jump Yet: Migrating 2.4 Million Lines of Python 2 Code to Python 3.12

For over two decades, the sprawling, player-driven universe of EVE Online has operated on a foundational architecture that predates many of its current players. Launched in 2003 by Icelandic developer CCP Games, the massively multiplayer online role-playing game (MMORPG) has relied entirely on Python 2—specifically, a custom-built Stackless Python interpreter comprising roughly 2.4 million lines of code. Now, CCP Games engineers are embarking on the most perilous technical undertaking in the game’s history: a live migration of the entire virtual universe to Python 3.12.

Unlike single-server session-based games that can be taken offline for days for major overhauls, EVE Online operates on a single-shard architecture. This means hundreds of thousands of players across the globe inhabit the exact same continuous universe, where thousands can participate in massive player-versus-player (PvP) space battles simultaneously. In EVE, permanent loss is a core tenet: when a spaceship is destroyed, it is gone for good, along with its cargo and the real-time player economy tied to its creation. Consequently, the game universe must remain online and uninterrupted throughout the migration process, leaving zero room for catastrophic failure.

Two Decades of Stackless Python and the Impending Deadline

When CCP Games began developing EVE Online in the late 1990s and early 2000s, Python was chosen to accelerate software development and enable non-traditional programmers and game designers to write gameplay logic quickly. To handle the immense concurrency required for a single-shard space simulation without choking server CPUs, the developers adopted Stackless Python—a fork of CPython that removes the standard C call stack to enable microthreads (tasklets).

For years, Stackless Python provided CCP Games with the high-performance concurrency model necessary to manage thousands of simultaneous ship movements, economic transactions, and spatial interactions. However, the ecosystem surrounding Stackless Python eventually stalled. Upstream Stackless Python development ceased following version 3.8, and the repository was officially archived by maintainers. As modern operating systems, hardware architectures (such as Apple Silicon), and security standards advanced, maintaining a heavily customized, end-of-life Python 2.7 interpreter became an unsustainable burden for CCP Games’ engineering staff.

Faced with a mounting technical debt mountain and dwindling compatibility with modern development pipelines, the studio realized that standing still was no longer an option. The destination for the new era of EVE is Python 3.12, with future iterations already mapped out for subsequent versions.

The Technical Hurdles: Division Logic, Serialization, and 100 Gigabytes of Memory

Migrating a 20-year-old codebase of 2.4 million lines involves sweeping systemic changes that extend far beyond simply swapping out a binary executable. The engineering team has outlined several critical bottlenecks that must be meticulously addressed to prevent virtual economic collapse:

1. The Math of Combat (Division Logic): One of the most subtle yet dangerous changes between Python 2 and Python 3 is how division operators behave. In Python 2, dividing two integers (x / y) resulted in truncated integer division, whereas Python 3 performs true floating-point division. Across EVE Online’s codebase, approximately 6,500 lines of code rely on division to calculate weapon damage, shields, navigation, and market transactions. Altering these calculations without careful isolation risks shifting the outcome of high-stakes combat encounters and disrupting delicate mathematical models.
2. The Pickle Problem and 100 Gigabytes of Data: EVE Online maintains persistent states for non-player characters (NPCs) such as mission-giving agents who remember past player interactions. Over the past 20 years, approximately 100 gigabytes of these memory structures have been serialized into Redis databases using Python’s pickle module. Because the internal memory layout and pickling protocols differ significantly between Python 2 and Python 3, deserializing decades-old game data natively is impossible. Engineers must develop custom translation pipelines—potentially transitioning data formats toward more durable schemas like Protocol Buffers—to ensure player histories and universe states survive the upgrade intact.
3. Third-Party Dependencies and Native Extensions: Decades of bespoke in-house code mean that the game relies heavily on custom wrappers and C++ extensions. Upgrading the interpreter requires rebuilding or replacing native modules to guarantee full compatibility with Windows server nodes and client platforms across Windows and macOS.

The Testing Ground: Lessons from EVE Frontier

To mitigate the existential risk of upgrading EVE Online, CCP Games utilized a proving ground: EVE Frontier. Operating on a forked version of the same underlying technology stack, EVE Frontier served as an experimental sandbox where the platform engineering team could execute the initial Python 3 transition first.

Led by principal programmers and gameplay engineers such as Kristinn Sigurbergsson, Jamie Bannister, and Thomas Dähling, the team faced severe initial setbacks during the Frontier migration. Early test deployments suffered from mysterious hourly lockups where server processes would inexplicably freeze, requiring agonizing diagnostic phases.

By pushing Frontier through the Python 3 barrier ahead of time, the engineering crew ironed out fundamental build system incompatibilities, refined cross-platform compilation scripts, and established a reliable playbook. This trial-by-fire provided invaluable telemetry and confidence before turning their attention back to the flagship EVE Online client and server cluster.

A Phased Migration Strategy: Mitigating Live-Service Risk

Recognizing that a massive "big-bang" deployment across EVE Online‘s 200-node server cluster and millions of player clients would be dangerously risky, CCP Games has opted for an incremental, phased rollout strategy.

The journey began with an intensive static analysis phase, utilizing automated fixing tools (such as Futurize scripts) to bring 2.4 million lines of legacy code into syntax that is valid under Python 2.7 while maintaining forward compatibility. According to internal metrics, code syntax validity shifted from 94% to nearly 99.8%.

Next, the team established parallel branches: a "Python 3 Unstable" repository for regression testing and test-suite execution, and a transitional 2.7 compatibility layer. Rather than taking the entire virtual world offline for an extended upgrade window, CCP Games plans to employ a mixed-mode deployment architecture. This approach will allow engineers to selectively upgrade individual backend nodes and services to Python 3 while temporarily maintaining compatibility with legacy components.

Broader Implications and Industry Significance

The migration of EVE Online to Python 3.12 stands as one of the most ambitious software modernization projects in the history of the video game industry. Few commercial applications have successfully transitioned a live, single-shard economy spanning two decades across a major language version divide without a system reset.

Beyond the immediate operational necessity of escaping an archived interpreter, the upgrade unlocks profound long-term benefits for CCP Games. Modern language features—such as robust type hinting, improved performance optimizations in CPython, and enhanced profiling tools—will empower engineers to write cleaner, safer, and more maintainable code. Furthermore, standardizing on a supported Python release paves the way for developers to leverage modern package management frameworks and ecosystem libraries.

As Jamie Bannister, Kristinn Sigurbergsson, and Thomas Dähling continue guiding the migration from the trenches of CCP’s offices, the global EVE Online community watches closely. For a universe where actions have permanent consequences and digital empires are bought and sold with real-world economic weight, keeping the lights on during a heart-surgery-level core language upgrade is the ultimate test of engineering resilience.