University of Oxford - Plone 4 to Plone 6 - Upgrading the beast

Haiku is a software as a service CMS utilising Plone as the engine. Haiku is aimed at research and higher education institutes. With over 140 websites at Oxford University using Haiku, we will talk about some of its key features and the long anticipated upgrade from Plone 4 to Plone 6, covering the good, the bad, and the epic. We will cover the small fish in the logistical pond, as well as the whales under the water.

The University of Oxford lets you do what you want to do. No one tells you. You can hire your nephew to build a website. Not always good for stability.

After a few pilot projects we are at 140 websites running Haiku. Non technical site owners can theme their site.

Now we want to move this beast to Plone 6. With a small team we had fear of the unknown: what dangers did we not know about? So we asked Philip Bauer and Lukas Zdych as external consultants and programmers.

Requirements for the migration: Keep all features and UX. Usually not a good idea, you would use a relaunch, do new things or theming. But here it looked good already, so it was okay to do it this way.

• Content: everything was already Dexterity, so that is modern.
• A ton on code, 2000 Python files, 500 page templates, good quality. The test coverage was not good though, so it was hard to say if a change was good.
• collective.cover was used a lot. I thought of going to Mosaic, but there was already work getting pretty close to Plone 5.2, so we went for it.

Since it was Dexterity already, we chose in-place migration. Now I am not so sure, exportimport would have been good too. We targeted Plone 6 alpha as soon as possible.

Initial task: update application code for Python 3. Lots is automated, but there is still manual work. After a while we got everything working on Python 3, and we could export and import the content, so we decided to change plans: use exportimport.

With exportimport you do not write upgrade steps when you need something special, but you write migration hooks. The project lead to some code and examples added in exportimport. For details on migration code, see the migration best practices training.

Lessons learned:

• collective.cover is actually great.
• collective.exportimport can solve even the toughest migrations, and is faster by magnitudes. You also get earlier results: you can export and import just one content type, or one part of the site. It makes migrations affordable. About 15 procent of the time Philip billed for this project was for the real migration of data, the rest for improvements in the code.

We have context behaviours to enable features on content items.

Comment from Kim: you can replace Oxford with Leuven and give basically the same presentation.