Next year Python 2 is no longer maintained. But you have a monster code base with clever tricks and libraries that don't support Python 2, and your data may be stored in a format that is hard to move Python 3. And that's the easy bit. This talk focuses on the process of moving, not the code changes. Because it's the process that is the hard part. How do you get your code in a state where it's ready to move? How do you get the whole team on the boat to Python 3? All Python 3 talks I have seen, including those I have given, and all the texts on how to port, including the book I wrote, focus on the code changes. With increasing backwards compatibility in Python 3 and forward-compatibility in Python 2, this actually became a lesser problem for big code bases. The extra issues of large, old code bases Can you stop adding features? (1 min) Separate team vs getting everyone on it (2 min) Python 2 compatibility: You need it (1 min) The steps Fix your development process (2 min) Replace old libraries, or take over maintenance and port them (2 min) Make sure your tests are solid (1 min) Run 2to3 but only backwards compatible fixers (2 min) Run tests on Python 3 to stop backsliding (4 min) Run all tests: Expansive or slow Store passed tests Detect tests that change Turning it off adds a lot of extra work Port all your little utilities and tool scripts (1 min) Fix fix fix fix (1 min) Add tests with Python 2 data, to test migration (2 min) You might need migration scripts Extra careful staging tests (1 min) Production: Try, fail, repeat (1 min) Clean the code up (3 min)