Moving forward from Plone 4.3

Hi folks,

I run a quite large Plone instance for an organization, including a public facing site and an intranet. We have 50+ internal add-ons plus several community provided ones. I have to figure out an strategy to move us away from Plone 4.3/Python 2.

I would like to hear from you regarding ideas and similar experiences.

My initial plan is as follows:

  1. Make all the code base Python 2+3 compatible, but still keep running on Plone 4.3.
  2. Make all the code base Plone 4.3 + 5.2 compatible, in order to make the following step easier. The goal would be make tests pass in all involved Plone/Python versions.
  3. Migrate to Plone 6 with Volto.

My reasoning is that we don't gain much migrating to Plone 5.2, since Plone 6 is approaching fast and is quite a jump from 5.2.

What do you think? I'd appreciate any feedback.

Some details:

  • We are 100% Dexterity and, no Archetypes.
  • We use Diazo for theming.
  • We use little Javascript, mostly sprinkles of jQuery here and there. Really old school, no modern Javascript whatsoever.
  • We rely on the good old resource registry, no Webpack.
  • We have excellent test coverage.


Rafael Oliveira

With 100% Dexterity there is a good chance that you can migrate your code easily and quickly to Python 3 and use the in-place migration rather than a more custom migration path. I would not invest any time into a Python2-3 compatible codebase if you can move quickly from Plone 4 to Plone depends on the size of your codebase and if you need to maintain/update your code during the migration phase. Any invest in Python 2 is wasted time (and wasted money)...try to move quickly.

Thanks for the advice @zopyx.

What's an inplace migration?

My initial plan is to not migrate to Plone 5.x since it does not add much value and I'll have to deal with all the theming and resource registries issues. I plan to make the add-ons Plone 5.x compatible only to make it easier to migrate to 6.x.

Any thoughts about this?

The standard Plone migration

1 Like

Yes, the one that is not transmogrifier or some hacked up equivalent by cough certain persons like @zopyx cough. :smile: What upgrade paths have you used for upgrading a site to Python 3?

The standard migration is the one described at

Transmogrifier is covered at

Never follow the lemmings :roll_eyes:

In-place is the “official” method. There should always be a relatively easy way to upgrade, and right now I’d say setting up transmogrifier isn’t easy.

And what about skipping 5.2 and aim to move directly to 6? Do you think it is reasonable @tkimnguyen @zopyx

Or should I move to 5.2, wait a couple years and then move to 6?

My main difficulty is that I have a large codebase and a workforce composed of exactly two people.

It’s an interesting problem, but I don’t know if you can entirely skip 5.x in migrating from 4.3 to 6. At the moment, the only thing on the roadmap about 6 is that it will have the Volto default front end. It’s probably 1.5-2 years away (my guess). Usually we want there to be some significant functionality changes and significant user-facing changes to warrant declaring it a major version change, so I would think there will be some backend changes to go with it. I don’t know then if it will be possible for a migration to go directly from 4.x to 6; if you look at our migration docs, they say go to 4.3 then to 5, so I would assume when the time comes you will have to migrate first to the last 5.x version THEN to 6.

However, you might be able to skip dealing with theming in 5.x.

Maybe you could consider migrating to 5.2 and using Volto instead of having to re-theme for 5.2 and (later) go to Volto.

1 Like

Plone 6 featuring whatever (Volto?!) is likely at least two years away (with a usually unusable dot zero release).

The end of lifetime of Python 2 by the end of the year is likely a reason for moving to Plone 5.2.

Volto yes or no ...I have my own opinion on that...I see very few usecases were Volto would give us advantages in the near future compared to the traditional server side rendering. On the other hand it is much easier to get developer building something to top of a headless API...given the speed of frontend development these days I wonder how long a Volto/React frontend can live and survive and being maintained in long-running projects. Volto really gives me a major headache.

1 Like